Benvenuti al nostro primo post multilingue, che viene da voi in italiano, inglese, spagnolo, e "digitale". Oggi discutiamo su come eseguire upload, aggiornamenti ed eliminazioni di massa di oltre 300.000 record in FileMaker Cloud / FileMaker Server in 35 minuti circa, in modo sicuro e senza incorrere in tempi di inattività. Resisti ai tuoi cappelli, questo è sicuramente per i "pioli quadrati nei fori rotondi".
Il problema
Sia in locale o nel cloud, la maggior parte dei database multiutente spesso richiedono l'aggiornamento o lo scaricamento di routine dei dati di grandi dimensioni. Spesso i feed dati hanno origine in altri sistemi ed esistono come un file flat, sia .csv oppure ASCII a lunghezza fissa. Il metodo di scelta per tali aggiornamenti è portare il database offline ed eseguire tutte le importazioni di massa in modalità utente singolo, ma cosa succede se questa non è un'opzione?
Alcune applicazioni sono "Sempre attive", 24 ore al giorno. In sittuazini in cui ci sono tre turni di lavoro che accedono all'applicazione 24 ore su 24, il tempo di inattività massimo disponibile può essere inferiore a una (1) ora, a volte anche a meno di 30 minuti. In alcuni scenari estremi, i tempi di fermo potrebbero non essere un'opzione.
Invece di eseguire un'importazione massiva, abbiamo deciso di CREARE i record (uno per uno) utilizzando l'istruzione di "Esegui script su server" (PSoS). Il risultato è stato di grande successo, poiché siamo stati in grado di popolare in modo rapido e sicuro il nostro tavolo da 34 campi con 300.000 record circa in poco più di 33 minuti (anche da un iPad!).
Quali sono le sfide poste dai tipici processi di importazione? Ci sono diversi fattori da considerare:
1. Un'importazione blocca la tabella
Operazioni come l'importazione di record o l'esecuzione di valori "sostituisci tutto" in un campo posizionano un blocco esclusivo sull'intera tabella. Su un'importazione di 300.000 record, ciò può significare che la tabella rimarrà bloccata per un periodo di tempo prolungato fino al completamento dell'importazione.
2. Le importazioni simultanee verranno effettivamente rallentate
Se ci sono più importazioni così grandi da eseguire in diverse tabelle in un periodo di tempo limitato, non è consigliabile eseguire due o più importazioni simultanee per risparmiare tempo, poiché le prestazioni per ogni singola importazione potrebbero effettivamente risentirne. Potrebbero esserci anche conseguenze non intenzionali causate da dipendenze sconosciute come unioni tra le tabelle (come campi inseriti automaticamente / di calcolati che verrano popolati con informazioni errate a causa di calcoli incompleti).
3. Un'importazione può danneggiare i registri di ripristino all'avvio
Ad aggravare il problema è il tema dei registri delle transazioni utilizzati dal server di database per il ripristino dell'avvio. Quando si esegue un'importazione di grandi dimensioni, Claris consiglia di disabilitare la registrazione delle transazioni per evitare il potenziale danneggiamento del database. Sfortunatamente questa disabilitazione richiede un riavvio graduale del motore di database, che vanifica lo scopo di evitare i tempi di inattività del server.
4. Uno script di importazione sul lato server impiega troppo tempo
Sebbene sia una pratica più sicura, nei nostri test un'importazione pianificata lato server di oltre 300.000 record può richiedere fino a 48 ore per il completamento, anche per una tabella ristretta di meno di 40 campi. Se hai tre di queste tabelle da popolare (circa 1 milione di record da caricare) e una finestra di tempo limitata in cui farlo, quella matematica semplicemente non si somma.
5. Il tempo potrebbe essere essenziale
Mentre risultati simili possono essere ottenuti usando alcune tecniche come la commutazione della tabella "finestra scorrevole" (ottenibile tramite la manipolazione del grafico della tabella e il modello di separazione), per qualsiasi sistema OLTP sotto vincoli della finestra di manutenzione, il collo di bottiglia continua ad essere il tempo necessario per caricare i dati nel server. Per situazioni in cui i dati devono essere online "adesso", è necessario un certo sollevamento di carichi pesanti.
La soluzzione
Implementa una coda di script PSoS sul lato client usando batch e pause
Usando questo approccio, siamo in grado di eseguire l'equivalente di un "import" massivo di record dal vivo e senza interruzioni (nessun blocco della tabella, nessun file offline, ecc.). Il processo è anche ad alte prestazioni, con numerosi test su diversi server FileMaker producendo una media costante di 145-150 record al secondo.
Per funzionalità di manutenzione più complete, abbiamo esteso gli script di loop della nostra coda RPC per includere AGGIORNAMENTO selettivo, CANCELLAZIONI selettive e, facoltativamente, TRUNCA tabella. Sulla base dei nostri test, gli aggiornamenti totali e le eliminazioni totali di ogni riga nell'intera tabella hanno richiesto appena un po 'più tempo rispetto alle operazioni originali di inserimento di tutte le righe.
Ecco una panoramica delle tecniche che utilizziamo
Leggi da file dati: abbiamo utilizzato il passaggio Leggi da file dati per leggere l'intero file dati e salvarlo in un campo di testo globale in una tabella di lavoro.
Chunking/Batching: abbiamo scritto calcoli e istruzioni di script per tagliare il file dati in più batch più piccoli che possono essere inviati al server come parametro dello script.
Loop: per accelerare l'elaborazione dei record, un Loop si ripete da 1 al numero massimo di blocchi di dati, attivando in sequenza rapida uno script PSoS per blocco.
Esegui script su server: sul server, un pedice scorre il batch di dati ricevuto tramite il parametro script, elaborando un record alla volta. Il server può eseguire contemporaneamente più di queste sessioni Esegui script su server.
Limitazione: per evitare arresti anomali del motore di script del server o sovraccaricare le risorse del server, abbiamo sviluppato un meccanismo di autoregolazione sul lato client per mettere in pausa e riprendere la coda.
Vuotare tabella: per situazioni in cui è necessario cancellare la tabella e ricaricare tutti i record da zero, lo script può facoltativamente vuotare la tabella.
Interrompibilità: se necessario, sul lato client la coda degli script può essere messa in pausa permanente, ripresa o interrotta.
Automazione robotizzata di processi: oltre all'esecuzione di attività su richiesta, usando "Installa script SuTimer" abilitiamo anche l'esecuzione di attività basate su intervalli di tempo. Ciò trasforma il tuo dispositivo FileMaker in un "robot" di base per l'esecuzione di attività automatizzate (RPA).
Ora per i dettagli:
Leggi da file dati
Se il file dati di origine è stato recapitato come documento in un campo Contenitore, il file viene prima esportato nella cartella Documenti sul computer, da cui può quindi essere riletto in un campo di testo (come testo normale) utilizzando l'istruzioni di script File. La lettura effettiva del file dati e l'inserimento in un campo globale di testo richiede meno di 30 secondi.
Chunking/Batching
Quando si tratta di eseguire script sul server per insiemi di dati di grandi dimensioni, è necessario "alimentarlo con cucchiaio", in morsi più piccoli o il server si strozzerà nel tentativo di elaborare l'intera cosa in un solo colpo. La suddivisione dei dati è una soluzione di batch comunemente usata per sincronizzazione dei dati.
La lunghezza massima del parametro per il comando FileMaker 'Esegui script su server' è di 1 milione di caratteri. Per sicurezza e gestibilità, le dimensioni batch / chunk create dalla nostra sceneggiatura sono limitate a 560.000 caratteri, appena al di sopra del 50% di max.
Esegui script su server
Conosciute anche come stored procedure, la maggior parte delle piattaforme di database supporta l'esecuzione di script su server. FileMaker Server Script Engine (FMSE), implementa questa funzionalità nell'intera linea di prodotti del server e può essere richiamato tramite Esegui script su server.
Fare la coda
Il pezzo mancante del puzzle sulla piattaforma FileMaker (almeno per ora) è stato l'accodamento RPC. Sia sul lato client che sul lato server, attualmente non esiste supporto nativo sulla piattaforma FileMaker per la creazione su richiesta e la gestione di un elenco di sessioni "Esegui script su server". La programmazione delle operazioni di administrazine è disponibile, ma non è la stessa cosa di una coda PSoS.
La coda di script che noi progettiamo è autocontrollata e interrompibile. Poiché è più semplice impostare, monitorare, gestire e annullare (se necessario), questa soluzione implementa la coda lato client. Ciò significa che per eseguire questi processi di aggiornamento delle tabelle bisogna una workstation FileMaker dedicata (uno Bot FileMaker).
Monitoraggio del carico e auto-limitazione Regolando automaticamente la pausa dello script per periodi più o meno lunghi, la nostra coda di script gestisce il carico posizionato sul server nel miglior modo possibile. Sui server che supportano versione 2 dello FileMaker Admin API, la durata della pausa viene determinata monitorando l'elenco di script PSoS in sospeso. Sugli host che non supportano o non sono configurati per accettare chiamate API di amministrazione (ovvero non dispongono di certificato SSL), la durata della pausa dello script viene calcolata in base alla dimensione dei blocchi di dati.
Istruzioni per il nostro demo
Per guidarti attraverso il processo di configurazione, abbiamo fornito un file demo che imita la finestra di dialogo di importazione FileMaker, incluse le opzioni per la scelta dei campi da escludere e dei campi da abbinare.
Tutto inizia con l'importazione dell'ultima versione del download rilasciabile dal FAA database degli aeromobili.
Nella schermata successiva, scegli la destinazione per popolare un portale con un elenco di campi che ti permetteranno di abbinare le colonne del tuo file dati (a sinistra) con i campi della tabella selezionata (a destra).
Sopra la colonna centrale, un menu popover ti permetterà di selezionare tra "INSERT" (crea nuovi record), "UPDATE" (aggiorna i record corrispondenti esistenti) e "DELETE" (elimina solo i record corrispondenti). La colonna centrale in quanto tale consente di selezionare i campi da abbinare (solo per aggiornamenti / eliminazioni) e anche quali escludere.
Nella schermata successiva, avrai la possibilità di pianificare l'attività su base ricorrente o eseguirla immediatamente e una volta. Una terza opzione avrebbe potuto essere aggiunta per pianificare l'esecuzione dell'attività una sola volta in un momento futuro, ma a scopo dimostrativo abbiamo pensato che non fosse necessario.
Tutte le funzionalità principali sono open source. Fai clic sul pulsante "Get Source Code" per esportare una versione minima della nostra demo che potrai esaminare in dettaglio.
Scarica il nostro file demo qui.
Utente: Developer, password: filemaker (minuscole)
(Nota Bene: Richiede FileMaker Pro 18, FileMaker Go 18 e FileMaker Server 18, Cloud 1.18+)
Avvertenze - ovvero "cosa potrebbe andare storto?"
Mentre abbiamo sperimentato un sovraccarico FMSE solo durante il nostro sviluppo (ma nessun arresto anomalo o danno permanente), dovremmo sempre raccomandare cautela, specialmente quando si lavora con set di dati di grandi dimensioni. Ecco un breve (ma non esaustivo) elenco di possibili sfide.
1. Sovraccarico FMSE
Se il numero di script PSoS in esecuzione in parallelo supera l'impostazione della capacità massima del server, l'FMSE del server può essere superato, portando a script infiniti che devono essere terminati manualmente. Ciò può portare non solo a caricamenti incompleti di dati, ma anche a potenziali blocchi / blocchi, o persino danni permanenti, ai database.
2. Sovraccarico delle risorse del database
Se il numero di script PSoS in esecuzione in parallelo supera la capacità di elaborazione del server, l'intero server potrebbe bloccarsi. Ciò può portare a file database danneggiati che potrebbero dover essere recuperati.
Raccomandazioni
1. Test su una copia del database
Non eseguirlo sul tuo database live fino a quando non l'hai testato con i tuoi file e tabelle di dati di importazione. Idealmente, avresti un server di prova completamente separato per provare questo tipo di modifiche prima di metterle in produzione.
2. Crea backup (plurale)
Backup, backup, backup. Anche dopo aver testato tutto questo a fondo offline, assicurati di avere in mano diversi backup completi dei database FileMaker prima di eseguirlo in produzione.
3. Aggiorna le risorse del tuo server
Se stai gestendo alta quantità di record e l'elaborazione veloce è importante per te, potrebbe valer' la pena considerare l'aggiornamento della potenza del tuo server. In un ambiente cloud o virtuale, questo può essere semplice come allocare più CPU, RAM e spazio di archiviazione nella tua istanza. Se stai utilizzando una macchina física, n questi giorni anche installare più RAM ed uno SSD più veloce è un processo relativamente economico e indolore.
4. Aumenta la soglia PSoS del tuo server
Sebbene non sia supportato in FileMaker Cloud, il FileMaker Server Script Engine (FMSE) locale è configurabile. A seconda della configurazione dell'host (numero di core della CPU, capacità di memoria e velocità effettiva), potrebbe essere possibile per il tuo server di database gestire più di 100 sessioni di script simultanee.
Per l'edizione locale di FileMaker Server, la soglia predefinite degli script su server simultanee è di 100 sessioni. Se il tuo server ha le risorse, potrebbe essere vantaggioso modificare la soglia FMSE in modo tale che il tuo host possa elaborare parallelamente più payload utilizzando un numero maggiore di sessioni simultanee. La modifica di questa impostazione non richiede alcun tipo di riavvio e può essere facilmente ripristinata al completamento.
Su FileMaker Cloud, la soglia della procedura remota non è configurabile e dipende dalla licenza del tuo software.
Come aumentare la soglia FMSE di FileMaker Server
Dalla riga di comando, scrivi:
From FileMaker client (via Admin REST API):
Informazioni sui risultati dei test:
- Abbiamo testato con il download rilasciabile dal FAA database degli aeromobili.
- Test effettuati su FileMaker Server 18 e FileMaker Cloud 1.18.
- I server virtuali eseguivano Windows Server 2012/2016 su istanze AWS t2.large.
- Il server effettivo era un Mac mini di fine 2012 con quattro core i7 e 16 GB RAM.
- Tutti i server hanno utilizzato la cache e gli intervalli di statistiche predefinite.
- Prestazioni di rete: latenza tra 5 ms e 40 ms.
- La ricerca dei record fu sempre per ID univoco.
- I test sono stati eseguiti utilizzando tabelle strette (~ 35 colonne circa).
- I campi sono tutti alfanumerici (testo, data, ora, ecc.), nessun contenitore / dati binari.
- Il contenuto di ogni campo di prova è relativamente ristretto (non romanzi letterari).
- I robot FileMaker Pro / Go hanno utilizzato le impostazioni di cache predefinite.
- I robot FileMaker Pro / Go utilizzavano Gigabit Ethernet o WiFi 802.11ac.
Finalmente, in binario
Se all'inizio non ci riesci ...
Comentários