MongoDB - procedure consigliate per l'architettura
Utilizza le seguenti procedure consigliate per utilizzare MongoDB nelle distribuzioni in IBM Cloud®. Se hai selezionato i server compilati, molte di queste raccomandazioni sono già implementate.
Strategia di distribuzione
Quando pianifichi la distribuzione di MongoDB, è necessario considerare diverse aree chiave. La più importante è la tua dimensione del dataset prevista e corrente. Queste due aree sono il driver primario per la tua scelta della risorsa del nodo fisica individuale necessaria e che guida i tuoi piani di frammentazione. Devi anche considerare l'importanza dei tuoi dati e quanto sei tollerante della possibilità di perdita e ritardo dei dati (specialmente negli scenari replicati).
Dimensionamento della memoria
MongoDB (come molte applicazioni orientate ai dati) funziona meglio quando il set di dati rimane in memoria. Nulla esegue meglio di un'istanza MongoDB che non richiede I/O disco. Ogniqualvolta possibile, seleziona una piattaforma che disponga di RAM più disponibili rispetto alla tua dimensione di serie di dati di lavoro. Se il tuo dataset supera la RAM disponibile per un solo nodo, considera di sfruttare la frammentazione. La frammentazione aumenta la quantità di RAM disponibile in un cluster per ospitare il dataset più grande. Pertanto, ottimizza le prestazioni generali della tua distribuzione. Gli errori pagina possono indicare che potresti stare per superare la RAM disponibile nella tua distribuzione. Devi considerare di incrementare la tua RAM disponibile.
Tipo di disco
Se la velocità non è un problema o se disponi di un dataset più grande rispetto a quello che la tua strategia di memoria può supportare, un tipo di disco appropriato per la tua distribuzione è importante. IOPS è la chiave per selezionare il tuo tipo di disco. Più alto è IOPS, migliori sono le prestazioni di MongoDB. Se possibile devono essere utilizzati i dischi locali poiché l'archivio di rete può causare elevata latenza e prestazioni scarse per la tua distribuzione. Si consiglia di utilizzare RAID 10 per gli array del disco.
CPU
La velocità di clock e il numero di processori disponibili diventa una considerazione se desideri utilizzare un map-reduce. Tuttavia, quando esegui un'istanza MongoDB con la maggior parte dei dati in memoria, la velocità di clock può influire sulle prestazioni. Se il tuo sistema funziona in queste circostanze e desideri massimizzare le operazioni al secondo, considera una strategia di distribuzione che includa una CPU con un'elevata velocità del bus di clock.
Replica
La replica fornisce l'elevata disponibilità dei tuoi dati se un nodo ha un malfunzionamento nel cluster. Per risultati migliori, replicare con almeno tre nodi in qualsiasi distribuzione MongoDB. La configurazione più comune per la replica con tre nodi è una distribuzione 2x1 che ha due nodi primari in un solo datacenter con un server di backup in un datacenter secondario.
Frammentazione
[: #dbt-sharding]
Se prevedi che il dataset sia molto grande, ti consigliamo di distribuire una distribuzione MongoDB frammentata. È possibile utilizzare lo sharding per partizionare i dati impostati su più nodi. MongoDB può distribuire automaticamente i dati attraverso i nodi nel cluster. Oppure puoi definire una chiave di partizione e creare una frammentazione basata sull'intervallo per tale chiave. La frammentazione può essere utile nello scrivere le prestazioni, per cui è possibile che puoi eseguire la frammentazione anche se il tuo dataset è piccolo ma richiede un numero elevato di aggiornamenti o di inserimenti. Quando distribuisci una serie frammentata, MongoDB richiede solo tre istanze del server di configurazione specializzate nei runtime Mongo per tracciare la configurazione di partizione corrente. La perdita di uno di questi nodi fa sì che il cluster entri in modalità di sola lettura solo per la configurazione e richiede che tutti i nodi vengano riportati online prima di poter apportare qualsiasi modifica alla configurazione.
Modalità di protezione di scrittura
Hai più opzioni per scrivere modalità di sicurezza che governano come MongoDB gestisce la persistenza dei dati su disco. È importante considerare quale strategia meglio soddisfi i propri bisogni per le prestazioni e per l'integrità dei dati. Sono disponibili le seguenti modalità di protezione di scrittura:
- Nessuno – Fornisce una strategia di scrittura differita che non blocca e aiuta a ottenere prestazioni elevate. Tuttavia, un malfunzionamento del nodo e la perdita di dati sono una piccola possibilità. È anche possibile che i dati scritti su un nodo in un cluster non siano immediatamente disponibili su tutti i nodi in quel cluster per coerenza di lettura. La modalità None non fornisce alcuna protezione dei dati in caso di errori di rete. Questa modalità è altamente inaffidabile e viene utilizzata solo quando le prestazioni sono una priorità e l'integrità dei dati non è un problema.
- Normal – È il valore predefinito per MongoDB. La modalità normale è anche una strategia di scrittura differita non bloccante.
- Sicuro – Blocca fino al MongoDB riconosce di aver ricevuto la richiesta di scrittura, ma si blocca fino al completamento della scrittura. La modalità Safe fornisce un livello maggiore di integrità dei dati e di consistenza di lettura in un cluster.
- Journal Safe – Fornisce un'opzione di ripristino per MongoDB. La modalità Journal Safe garantisce che i dati vengano riconosciuti e che l'aggiornamento del Journal sia completo prima che venga restituito.
- Fsync – Fornisce il livello di integrità dei dati più elevato e blocca finché non si verifica una scrittura fisica dei dati. L'utilizzo di Fsync crea un calo delle prestazioni e utilizzala solo se l'integrità dei dati è la preoccupazione primaria per la tua applicazione.
Verifica della distribuzione
10gen dispone di diversi strumenti per aiutarti a caricare il test della tua distribuzione. Uno strumento da console, benchRun, può eseguire operazioni dall'interno di a JavaScript collaudare l'imbragatura. benchRun restituisce informazioni
sull'operazione e numeri di latenza per ciascuna operazione. Se sono necessarie informazioni più dettagliate sull'istanza MongoDB, prendi in considerazione di eseguire il comando mongostat
o MMS per monitorare la tua distribuzione
durante la verifica.
Installazione
Hai diverse considerazioni quando installi MongoDB che possono aiutare a creare una soluzione stabile e orientata alle prestazioni. 10gen ti consiglia di utilizzare CentOS (64 bit), se possibile. Evita la distribuzione su sistemi operativi a 32-bit e Windows. Questi sistemi forniscono una piattaforma di distribuzione inadeguata. I sistemi operativi a 32 bit hanno limiti di dimensione dei file che causano problemi e Windows può causare problemi di prestazioni se la memoria virtuale viene utilizzata dal sistema operativo per compensare la mancanza di RAM nella distribuzione. Per impostazione predefinita, IBM Cloud fornisce sistemi operativi a 64-bit CentOS per tutte le distribuzioni del server compilato.
Inoltre, assicurati di effettuare le seguenti modifiche all'installazione del SO di base per ottimizzare le prestazioni:
- Imposta Read-Ahead SSD in modo predefinito su 16 blocchi – Le unità SSD hanno tempi di ricerca eccellenti che consentono la riduzione di Read-Ahead in 16 blocchi. Lo spinning dei dischi può richiedere poco buffer, per cui per questi dischi è impostato su 32 blocchi.
- noatime – noatime elimina il bisogno per il sistema di scrivere nel file system i file che sono in lettura. Ciò significa che avrai un accesso ai file più veloce e una minore usura del disco.
- Disattiva NUMA nel BIOS Linux, NUMA, e MongoDB generalmente non lavorano insieme. Se stai eseguendo MongoDB su hardware NUMA, si consiglia di disattivarlo (eseguendo con una politica di memoria di interfoliazione). In caso contrario, possono manifestarsi problemi come un rallentamento significativo o o un tempo CPU del sistema elevato.
- Imposta ulimit – ulimit è impostato su 64000 per i file aperti e su 32000 per i processi utente. Questi unlimit aiutano a prevenire malfunzionamenti dovuti a una perdita di processi utente e di gestioni file disponibili.
- Utilizza ext4 – Ext3 è lento nell'assegnare i file (o rimuoverli). Inoltre, l'accesso a file grandi non è buono con ext3.
Per impostazione predefinita, queste modifiche sono impostate su tutti IBM Cloud server.
Si consiglia inoltre che i volumi journal e dati siano volumi fisici distinti. Se le directory journal e dati risiedono su un solo volume fisico, lo svuotamento di journal interrompe l'accesso ai dati e fornisce picchi di elevata latenza nella tua distribuzione MongoDB.
Operazioni
Dopo una distribuzione MongoDB viene promossa alla produzione, considerare i seguenti consigli per il monitoraggio e l'ottimizzazione delle prestazioni.
- Assicurarsi che l'agente MMS sia in esecuzione su tutte le istanze di MongoDB, che aiuta a monitorare la salute e le prestazioni della distribuzione. L'agent MMS fornisce dati di debug utili a 10gen durante le interazioni di supporto.
- Il comando
mongostat
fornisce inoltre le informazioni di runtime sulle prestazione di un nodo {{site.data.keyword.mongobd}}.
Se questi strumenti rilevano dei problemi, la frammentazione o l'indicizzazione possono aiutare a correggere questi problemi di prestazione.
- Creare indici per a MongoDB distribuzione se gli strumenti di monitoraggio indicano che le query basate sul campo funzionano in modo inadeguato. Per migliorare le prestazioni, utilizza sempre gli indici quando esegui la query dei dati che si basano su campi distinti.
- Utilizzare lo sharding quando le prestazioni complessive del nodo risentono di un set di dati operativi di grandi dimensioni. Assicurati di eseguire la frammentazione prima che l'indicatore sia rosso. Il sistema suddivide in parti solo per la frammentazione nell'inserimento o aggiornamento. Se attendi troppo a lungo a frammentare, puoi avere una distribuzione irregolare.