Dopo aver sviluppato l'applicazione e il modello di database (quando è il momento di spostare l'ambiente in produzione), ci sono un paio di cose che devono essere fatte prima. Spesso gli sviluppatori non prendono in considerazione ulteriori importanti passaggi di MongoDB prima di distribuire il database in produzione. Di conseguenza, è nella modalità di produzione che finiscono per incontrare battute d'arresto sottostanti che non vengono presentate nella modalità di sviluppo. A volte potrebbe essere troppo tardi o piuttosto molti dati andrebbero persi in caso di disastro. Inoltre, alcuni dei passaggi discussi qui consentiranno di misurare lo stato di salute del database e quindi pianificare le misure necessarie prima che si verifichi un disastro.
Utilizza la versione corrente e i driver più recenti
In genere, le versioni più recenti di qualsiasi tecnologia sono dotate di funzionalità migliorate per quanto riguarda la funzionalità sottostante rispetto ai predecessori. Le ultime versioni di MongoDB sono più robuste e migliorate rispetto ai predecessori in termini di prestazioni, scalabilità e capacità di memoria. Lo stesso vale per i relativi driver poiché sono sviluppati dai principali ingegneri del database e vengono aggiornati più frequentemente anche rispetto al database stesso.
Le estensioni native installate per la tua lingua possono facilmente creare una piattaforma per procedure rapide e standard per testare, approvare e aggiornare i nuovi driver. Esistono anche software automobilistici come Ansible, Puppet, SaltStack e Chef che possono essere utilizzati per un facile aggiornamento di MongoDB in tutti i tuoi nodi senza incorrere in spese e tempo professionali.
Considera anche l'utilizzo del motore di archiviazione WiredTiger in quanto è il più sviluppato con funzionalità moderne che soddisfano le moderne aspettative dei database
Iscriviti a una mailing list MongoDB per ottenere le informazioni più recenti in merito alle modifiche alle nuove versioni e ai driver e alle correzioni di bug, quindi mantieniti aggiornato.
Utilizza un sistema a 64 bit per eseguire MongoDB
Nei sistemi a 32 bit, i processi MongoDB sono limitati a circa 2,5 GB di dati perché il database utilizza file mappati in memoria per le prestazioni. Questo diventa un limite per i processi che potrebbero superare il confine che porta a una cotta. L'impatto principale sarà:in caso di errore, non sarai in grado di riavviare il server fino al momento della rimozione dei dati o della migrazione del database a un sistema superiore come quello a 64 bit, quindi un tempo di inattività maggiore per la tua applicazione.
Se devi continuare a utilizzare un sistema a 32 bit, la tua codifica deve essere molto semplice per ridurre il numero di bug e la latenza per le operazioni di throughput.
Tuttavia per le complessità del codice come pipeline di aggregazione e geodati, è consigliabile utilizzare il sistema a 64 bit.
Assicurati che i documenti siano limitati a una dimensione di 16 MB
I documenti MongoDB sono limitati alla dimensione di 16 MB, ma non è necessario avvicinarsi a questo limite poiché comporterà un degrado delle prestazioni. In pratica, i documenti sono per lo più di dimensioni KB o inferiori. La dimensione del documento dipende dalla strategia di modellazione dei dati tra incorporamento e riferimento. L'incorporamento è preferibile laddove non si prevede che le dimensioni del documento aumentino di molto. Ad esempio, se disponi di un'applicazione di social media in cui gli utenti pubblicano e contiene commenti, la migliore pratica sarà quella di avere due raccolte una per contenere le informazioni sui post.
{
_id:1,
post: 'What is in your mind?',
datePosted: '12-06-2019',
postedBy:'xyz',
likes: 10,
comments: 30
}e l'altro per conservare i commenti per quel post.
{
_id: ObjectId('2434k23k4'),
postId: 1,
dateCommented: '12-06-2019',
commentedBy:'ABCD',
comment: 'When will we get better again',
}Avendo tali modelli di dati, i commenti verranno archiviati in una raccolta diversa dal post. Ciò impedisce che il documento nella raccolta dei post cresca fuori limite nel caso in cui ci siano così tanti commenti. Assicurati di evitare modelli di applicazione che consentirebbero ai documenti di crescere senza limiti.
Assicurati che il set di lavoro rientri nella memoria
Il database potrebbe non leggere i dati dalla memoria virtuale (RAM) causando errori di pagina. Gli errori di pagina forzeranno il database a leggere i dati da un disco fisico, portando a una maggiore latenza e di conseguenza a un ritardo nelle prestazioni complessive dell'applicazione. Gli errori di pagina si verificano a causa dell'utilizzo di un set di grandi dimensioni che non si adatta alla memoria. Ciò potrebbe essere dovuto al fatto che alcuni documenti hanno una dimensione illimitata o una strategia di partizionamento orizzontale scadente. I rimedi per gli errori di pagina saranno:
- Garantire che i documenti siano limitati alla dimensione di 16 MB.
- Garantire una buona strategia di partizionamento orizzontale selezionando una chiave di partizionamento orizzontale ottimale che limiterà il numero di documenti a cui sarà sottoposta un'operazione di throughput.
- Aumenta le dimensioni dell'istanza MongoDB per ospitare più working set.
Assicurati di avere i set di repliche a posto
Nel mondo dei database, non è l'ideale fare affidamento su un unico database a causa del fatto che potrebbe verificarsi una catastrofe. Inoltre, ti aspetteresti un aumento del numero di utenti del database, quindi è necessario garantire un'elevata disponibilità dei dati. La replica è un approccio fondamentale per garantire un'elevata disponibilità in caso di failover. MongoDB ha la capacità di servire i dati geograficamente:il che significa che gli utenti di diverse località saranno serviti dall'host cloud più vicino come un modo per ridurre la latenza per le richieste.
Nel caso in cui il nodo primario si guasta, i nodi secondari possono eleggerne uno nuovo per tenere il passo con le operazioni di scrittura piuttosto che l'applicazione ha un tempo di inattività durante il failover. In realtà, alcune piattaforme di hosting cloud che tengono in considerazione la replica non supportano MongoDB non replicato per gli ambienti di produzione.
Abilita inserimento nel journal
Per quanto il journaling implichi un degrado delle prestazioni, è altrettanto importante. Il journaling migliora le operazioni di scrittura in anticipo, il che significa che nel caso in cui il database non riesce nel processo di aggiornamento, l'aggiornamento sarebbe stato salvato da qualche parte e quando riprenderà vita, il processo può essere completato. L'inserimento nel diario può facilmente facilitare il ripristino in caso di arresto anomalo, quindi dovrebbe essere attivato per impostazione predefinita.
Assicurati di impostare una strategia di backup
Molte aziende non riescono a continuare dopo la perdita di dati a causa dell'assenza o della mancanza di sistemi di backup. Prima di distribuire il database in produzione, assicurati di aver utilizzato una di queste strategie di backup:
- Mongodump :ottimale per piccole implementazioni e quando si producono backup filtrati in base a esigenze specifiche.
- Copia del sottostante :ottimale per distribuzioni di grandi dimensioni e approccio efficiente per eseguire backup completi e ripristinarli.
- Servizio di gestione MongoDB (MMS) :fornisce un backup online continuo per MongoDB come servizio completamente gestito. Ottimale per un cluster partizionato e set di repliche.
Anche i file di backup non devono essere archiviati nello stesso provider host del database. Backup Ninja è un servizio che può essere utilizzato per questo.
Preparati per le query lente
Difficilmente si possono realizzare query lente nell'ambiente di sviluppo a causa del fatto che sono coinvolti pochi dati. Tuttavia, questo potrebbe non essere il caso in produzione considerando che avrai molti utenti o saranno coinvolti molti dati. Potrebbero verificarsi query lente se non si utilizzano gli indici o si utilizza una chiave di indicizzazione non ottimale. Tuttavia, dovremmo trovare un modo che ti mostri il motivo delle query lente.
Decidiamo quindi di abilitare MongoDB Query Profiler. Per quanto ciò possa portare a un degrado delle prestazioni, il profiler aiuterà a esporre i problemi di prestazioni. Prima di distribuire il database, devi abilitare il profiler per le raccolte che sospetti possano avere query lente, in particolare quelle che coinvolgono documenti con molta incorporazione.
Collegamento a uno strumento di monitoraggio
La pianificazione della capacità è un'impresa molto essenziale in MongoDB. Dovrai anche conoscere lo stato di salute del tuo db in qualsiasi momento. Per comodità, connettere il tuo database a uno strumento di monitoraggio ti farà risparmiare un po' di tempo nel realizzare ciò di cui hai bisogno per migliorare il tuo database nel tempo. Ad esempio, una rappresentazione grafica che indica prestazioni lente della CPU a causa di un aumento delle query ti indirizzerà ad aggiungere più risorse hardware al tuo sistema.
Gli strumenti di monitoraggio hanno anche un sistema di avviso tramite posta o brevi messaggi che ti aggiornano comodamente su alcuni problemi prima che si trasformino in catastrofe. Pertanto, in produzione, assicurati che il tuo database sia connesso a uno strumento di monitoraggio.
ClusterControl fornisce il monitoraggio MongoDB gratuito nella Community Edition.
Attuare misure di sicurezza
La sicurezza del database è un'altra caratteristica importante che deve essere presa in considerazione rigorosamente. È necessario proteggere l'installazione di MongoDB in produzione assicurandosi che vengano rispettati alcuni elenchi di controllo di sicurezza di pre-produzione. Alcune delle considerazioni sono:
- Configurazione del controllo dell'accesso basato sul ruolo
- Abilitazione del controllo di accesso e applicazione dell'autenticazione
- Crittografia delle connessioni in entrata e in uscita (TLS/SSL)
- Limitazione dell'esposizione alla rete
- Crittografia e protezione dei dati
- Disporre di un piano di monitoraggio dell'accesso e delle modifiche alle configurazioni del database
Evita le iniezioni esterne eseguendo MongoDB con opzioni di configurazione sicure. Ad esempio, disabilitando lo scripting lato server se non si utilizzano operazioni lato server JavaScript come mapReduce e $where. Utilizza il validatore JSON per i dati della tua raccolta tramite alcuni moduli come mongoose per assicurarti che tutti i documenti archiviati siano nel formato BSON valido.
Considerazioni su hardware e software
MongoDB ha pochi prerequisiti hardware, poiché è stato progettato in modo esplicito tenendo in grande considerazione l'hardware di base necessario. Di seguito sono riportate le principali decisioni hardware per MongoDB da considerare prima della distribuzione in produzione.
- Assegna RAM e CPU adeguate
- Utilizza il motore di archiviazione WiredTiger. Progettato per utilizzare la cache del filesystem e la cache interna di WiredTiger, quindi prestazioni migliorate. Ad esempio, quando si opera con un sistema da 4 GB di RAM, la cache WiredTiger utilizza 1,5 GB di RAM (0,5 * (4 GB -1 GB) =1,5 GB) mentre un sistema con 1,2 GB di cache WiredTiger utilizza solo 256 MB.
- NUMA Hardware. Esistono numerosi problemi operativi che includono prestazioni lente e utilizzo elevato dei processi di sistema, quindi, si dovrebbe considerare la configurazione di un criterio di interleave della memoria.
- Disco e sistema di archiviazione:utilizza dischi a stato solido (SSD):MongoDB mostra un migliore rapporto qualità-prezzo con SSD SATA
Conclusione
I database in produzione sono molto cruciali per garantire il regolare svolgimento di un'azienda, quindi dovrebbero essere trattati con molte considerazioni. Si dovrebbero stabilire alcune procedure che possono aiutare a ridurre gli errori o piuttosto fornire un modo semplice per trovare questi errori. Inoltre, è consigliabile impostare un sistema di allerta che mostrerà lo stato di salute del database con il tempo necessario per la pianificazione della capacità e il rilevamento dei problemi prima che si trasformino in una catastrofe.
