La distribuzione di un database in cluster è una cosa, ma il modo in cui mantieni il tuo DBM mentre sei nel cluster può essere una grande impresa per un servizio coerente delle tue applicazioni. Si dovrebbe avere un aggiornamento spesso sullo stato del database, in particolare sulle metriche più cruciali, al fine di avere un'idea di cosa aggiornare o piuttosto modificare per prevenire eventuali colli di bottiglia che potrebbero emergere.
Ci sono molte considerazioni su MongoDB da tenere in considerazione, in particolare il fatto che l'installazione e l'esecuzione sono abbastanza facili, le possibilità di trascurare le pratiche di gestione del database di base sono elevate.
Molte volte, gli sviluppatori non tengono conto della crescita futura e del maggiore utilizzo del database, il che di conseguenza si traduce in un arresto anomalo dell'applicazione o dei dati con alcuni problemi di integrità oltre ad essere incoerente.
In questo articolo discuteremo alcune delle migliori pratiche da utilizzare per il cluster MongoDB per prestazioni efficienti delle tue applicazioni. Alcuni dei fattori da considerare includono...
- Aggiornamento all'ultima versione
- Motore di archiviazione appropriato
- Assegnazione delle risorse hardware
- Replica e partizionamento orizzontale
- Non modificare mai il file di configurazione del server
- Buona strategia di sicurezza
Aggiornamento all'ultima versione
Ho lavorato con MongoDB dalle versioni precedenti alla 3.2 e, ad essere onesti, le cose non erano facili in quel momento. Con grandi sviluppi, bug corretti e funzionalità appena introdotte, ti consiglierò di aggiornare sempre il tuo database all'ultima versione. Ad esempio, l'introduzione del framework di aggregazione ha avuto un migliore impatto sulle prestazioni piuttosto che fare affidamento sul concetto Map-Reduce già esistente. Con l'ultima versione 4.0, ora si ha la capacità di utilizzare la funzione di transazioni multi-documento che generalmente migliora le operazioni di throughput. L'ultima versione ha anche alcuni nuovi operatori di conversione di tipo aggiuntivi come $toInt, $toString, $trim e $toBool. Questi operatori saranno di grande aiuto nella convalida dei dati, quindi creeranno un senso di coerenza dei dati. Durante l'aggiornamento, fare riferimento alla documentazione in modo da evitare di commettere piccoli errori che potrebbero degenerare in errori.
Scegli un motore di archiviazione appropriato
MongoDB supporta 3 motori di archiviazione come per ora:WiredTiger, In-Memory e motori di archiviazione MMAPv1. Ciascuno di questi motori di archiviazione ha pregi e limitazioni rispetto all'altro, ma la tua scelta dipenderà dalle specifiche dell'applicazione e dalle funzionalità principali del motore. Tuttavia, personalmente preferisco il motore di archiviazione WiredTiger e lo consiglierei a chi non è sicuro di quale utilizzare. Il motore di archiviazione WiredTiger è adatto per la maggior parte dei carichi di lavoro, fornisce un modello di concorrenza a livello di documento, checkpoint e compressione.
Alcune delle considerazioni relative alla selezione del motore di archiviazione dipendono da questi aspetti:
- Transazioni e atomicità: conferimento dei dati durante un inserimento o un aggiornamento che si impegna solo quando tutte le condizioni e le fasi applicative si sono concluse con successo. Le operazioni sono quindi raggruppate insieme in un'unità immutabile. Con questo in atto, la transazione multi-documento può essere supportata come visto nell'ultima versione di MongoDB per il motore di archiviazione WiredTiger.
- Tipo di blocco: è una strategia di controllo sull'accesso o sull'aggiornamento delle informazioni. Durante la durata del blocco nessun'altra operazione può modificare i dati dell'oggetto selezionato finché non è stata eseguita l'operazione in corso. Di conseguenza, le query vengono influenzate in questo momento, quindi è importante monitorarle e ridurre la maggior parte del meccanismo di blocco assicurandoti di selezionare il motore di archiviazione più appropriato per i tuoi dati.
- Indicizzazione: I motori di archiviazione in MongoDB forniscono diverse strategie di indicizzazione a seconda dei tipi di dati che stai archiviando. L'efficienza di tale struttura di dati dovrebbe essere abbastanza amichevole con il carico di lavoro e si può determinarlo considerando ogni indice aggiuntivo come se avesse un sovraccarico delle prestazioni. Le strutture dati ottimizzate in scrittura hanno un sovraccarico inferiore per ogni indice in un ambiente applicativo con inserimento elevato rispetto alle strutture dati non ottimizzate in scrittura. Questa sarà una grave battuta d'arresto, soprattutto quando è coinvolto un gran numero di indici e la selezione di un motore di archiviazione inappropriato. Pertanto, la scelta di un motore di archiviazione appropriato può avere un impatto drammatico.
Assegnazione delle risorse hardware
Man mano che nuovi utenti accedono alla tua applicazione, il database cresce con il tempo e verranno introdotti nuovi shard. Tuttavia, non puoi fare affidamento sulle risorse hardware stabilite durante la fase di distribuzione. Ci sarà un corrispondente aumento del carico di lavoro e quindi sarà necessaria una maggiore fornitura di risorse di elaborazione come CPU e RAM per supportare i tuoi cluster di dati di grandi dimensioni. Questo è spesso riferito alla pianificazione della capacità in MongoDB. Le migliori pratiche relative alla pianificazione della capacità includono:
- Controlla costantemente il tuo database e adattalo in base alle aspettative. Come accennato in precedenza, un aumento del numero di utenti attiverà più query d'ora in poi con un maggiore carico di lavoro impostato, soprattutto se si utilizzano indici. Potresti iniziare a riscontrare questo impatto sull'estremità dell'applicazione quando inizia a registrare una variazione nella percentuale di scritture rispetto alle letture nel tempo. Sarà quindi necessario riconfigurare le configurazioni hardware per risolvere questo problema. Utilizza lo strumento mongoperf e MMS per rilevare le modifiche ai parametri delle prestazioni del sistema.
- Documenta in anticipo tutti i tuoi requisiti di prestazione. Quando incontri lo stesso problema avrai almeno un punto di riferimento che ti farà risparmiare tempo. La tua registrazione dovrebbe comprendere la dimensione dei dati che desideri archiviare, l'analisi delle query in termini di latenza e la quantità di dati a cui desideri accedere in un determinato momento. Nell'ambiente di produzione devi determinare quante richieste gestirai al secondo e, infine, quanta latenza tollererai.
- Metti in scena una dimostrazione di concetto. Esegui la progettazione di schemi/indici e comprendi i modelli di query, quindi perfeziona la stima della dimensione del working set. Registra questa configurazione come punto di riferimento per il test con successive revisioni dell'applicazione.
- Fai i tuoi test con un carico di lavoro reale. Dopo aver eseguito la fase del concetto di prova, distribuire solo dopo aver eseguito un test sostanziale con dati del mondo reale e requisiti di prestazioni.
Replica e partizionamento orizzontale
Questi sono i due concetti principali per garantire un'elevata disponibilità dei dati e una maggiore scalabilità orizzontale rispettivamente nel cluster MongoDB.
Lo sharding fondamentalmente partiziona i dati tra i server in piccole porzioni note come shard. Il bilanciamento dei dati tra gli shard è automatico, gli shard possono essere aggiunti o rimossi senza necessariamente portare il database offline.
La replica dall'altra parte mantiene più copie ridondanti dei dati per un'elevata disponibilità. È una funzionalità integrata in MongoDB e funziona su reti WAN senza la necessità di reti specializzate. Per una configurazione del cluster, ti consiglio di avere almeno 2+ mongo, 3 server di configurazione, 1 shard e garantire la connettività tra le macchine coinvolte nel cluster frammentato. Utilizza un nome DNS anziché IP nella configurazione.
Per gli ambienti di produzione usa un set di repliche con almeno 3 membri e ricorda di popolare più variabili di configurazione come la dimensione oplog.
Quando avvii le tue istanze mongod per i tuoi membri, usa lo stesso file di chiavi.
Alcune delle considerazioni sulla tua shardkey dovrebbero includere:
- Chiave e valore sono immutabili
- Considera sempre l'utilizzo di indici in una raccolta partizionata
- Il comando di aggiornamento del driver dovrebbe contenere una chiave shard
- Limiti univoci che devono essere mantenuti dalla chiave shard.
- Una chiave shard non può contenere tipi di indice speciali e non deve superare i 512 byte.
Non modificare mai il file di configurazione del server
Dopo aver eseguito la prima distribuzione, è consigliabile non modificare molti parametri nel file di configurazione, altrimenti potresti avere problemi soprattutto con gli shard. L'anello più debole con lo sharding sono i server di configurazione. Ciò significa che tutte le istanze mongod devono essere in esecuzione affinché lo sharding funzioni.
Buona strategia di sicurezza
MongoDB è stato vulnerabile agli attacchi esterni negli ultimi anni, quindi un'impresa importante per il tuo database per avere alcuni protocolli di sicurezza. Oltre a eseguire i processi su porte diverse, si dovrebbe almeno utilizzare uno dei 5 diversi modi per proteggere i database MongoDB. Puoi prendere in considerazione piattaforme come MongoDB Atlas che proteggono i database per impostazione predefinita attraverso la crittografia dei dati sia in transito che a riposo. Puoi utilizzare strategie come TLS/SSL per tutte le connessioni in entrata e in uscita.
Conclusione
Il controllo del cluster MongoDB non è un compito facile e comporta molte soluzioni alternative. I database crescono come risultato di un numero maggiore di utenti, quindi di un maggiore set di carichi di lavoro. On ha quindi il mandato di garantire che le prestazioni del DBM siano in linea con questo aumento del numero di utenti. Le migliori pratiche vanno oltre l'aumento delle risorse hardware e l'applicazione di alcuni concetti MongoDB come lo sharding, la replica e l'indicizzazione. Tuttavia, molti degli inconvenienti che possono sorgere sono ben risolti aggiornando la versione di MongoDB. Più spesso le ultime versioni hanno bug corretti, nuove richieste di funzionalità integrate e quasi nessun impatto negativo sull'aggiornamento anche con numeri di revisione importanti.
