Le implementazioni cluster sono di grande importanza per garantire l'elevata disponibilità dei dati e proteggerli. MongoDB migliora questo attraverso la replica e lo sharding, per cui la replica garantisce il ridimensionamento verticale attraverso il sollevamento della ridondanza mentre lo sharding gonfia il ridimensionamento orizzontale.
In generale, entrambi gli approcci cercano di distribuire il carico di lavoro tra i membri e quindi di ridurre il carico di lavoro a cui potrebbe essere sottoposto un singolo nodo. Le prestazioni del database possono quindi essere viste come veloci nel servire gli utenti con operazioni di throughput. Tuttavia, senza un'architettura cluster principale, potresti non visualizzare lo stesso livello di risultati, anche se provi partizionamento orizzontale e replica.
Se i membri del set di repliche sono pari, sarà difficile per i membri votare ed eleggere per una nuova primaria se quella esistente fallisce a un certo punto. In questo blog discuteremo dell'architettura di distribuzione standard che è possibile utilizzare, ma può variare in base ai requisiti dell'applicazione.
Strategie di distribuzione MongoDB
L'architettura dei set di repliche è molto determinante per la capacità e la capacità di MongoDB.
Un set di repliche a tre nodi è la distribuzione standard del cluster per MongoDB in qualsiasi ambiente di produzione in quanto fornisce ridondanza dei dati e tolleranza agli errori. La ridondanza è importante soprattutto nel ripristino del database dopo un disastro. Un set di repliche a tre nodi può essere l'architettura di distribuzione di base, ma può variare in base alle specifiche e ai requisiti dell'applicazione. Tuttavia, non renderlo troppo complesso in quanto potrebbe portare a problemi di configurazione più grandi.
Strategie di sharding MongoDB
Il partizionamento orizzontale riduce il carico di lavoro su cui il database deve lavorare per una determinata query, riducendo il numero di documenti su cui è necessario agire. Aumenta quindi il ridimensionamento orizzontale consentendo al database di crescere oltre i limiti hardware di un singolo server. A seconda della richiesta del carico di lavoro, è possibile aggiungere o rimuovere nodi dal cluster e MongoDB riequilibrerà i dati in modo ottimale senza l'intervento dell'operazione.
Alcune delle migliori strategie di distribuzione per un cluster partizionato includono:
Garantire la distribuzione uniforme delle chiavi shard
Il motivo alla base dello sharding è di ridimensionare il database orizzontalmente e ridurre il numero di operazioni di throughput a cui una singola istanza potrebbe essere soggetta. Se non distribuisci le chiavi shard in modo uniforme, potresti ritrovarti con un numero limitato di shard. Con pochi shard, le operazioni possono essere limitate dalla capacità di un singolo shard, rendendo così lente le operazioni di lettura e scrittura.
I pezzi dovrebbero essere pre-divisi e distribuiti per primi
Gli shard hanno blocchi di dati raggruppati in base ad alcuni criteri di chiave shard. Quando si crea una nuova raccolta partizionata, prima di caricarla con i dati, è necessario creare blocchi vuoti e distribuirli uniformemente su tutti gli shard. Quando compilerai MongoDB con i dati, sarà facile bilanciare il carico tra gli shard coinvolti. L'opzione numInitialChunks può essere utilizzata per eseguire queste operazioni automaticamente se si utilizza il partizionamento orizzontale basato su hash. Il valore intero, tuttavia, dovrebbe essere inferiore a 8192 per shard.
Numero di frammenti
Spesso sono richiesti due shard come numero minimo per ottenere il significato di sharding. Un singolo shard è utile solo se vuoi gettare le basi per abilitare lo sharding in futuro e non è necessario durante il tempo di distribuzione.
Preferisci il partizionamento orizzontale basato sull'intervallo rispetto al partizionamento orizzontale basato su hash
Il partizionamento orizzontale basato sull'intervallo è vantaggioso in quanto fornisce più shard, quindi le operazioni possono essere indirizzate al minor numero di shard necessari e più spesso a un singolo shard. In pratica questo può essere difficile a meno che tu non abbia una buona comprensione dei dati e dei modelli di query coinvolti. Il partizionamento orizzontale con hash migliora la distribuzione uniforme delle operazioni di throughput a scapito della fornitura di operazioni basate su intervalli inferiori.
Utilizza query a dispersione per solo query di aggregazione di grandi dimensioni
Le query che non possono essere instradate in base a una chiave shard devono essere trasmesse a tutti gli shard per la valutazione e poiché coinvolgono più shard per ogni richiesta, non si ridimensionano in modo lineare poiché vengono aggiunti più shard, quindi incorrere in un sovraccarico che degrada le prestazioni del database. Questa operazione è nota come raccolta a dispersione e può essere evitata solo se si include la chiave shard nella query.
L'approccio è utile solo quando si tratta di query di aggregazione di grandi dimensioni che ciascuna query può essere eseguita in parallelo su tutti gli shard.
Strategie di replica MongoDB
La replica migliora il ridimensionamento verticale in MongoDB in modo tale che il carico di lavoro sia distribuito tra i membri coinvolti. Nell'ambiente di produzione, queste sono alcune delle considerazioni da fare per un'architettura cluster ottimale.
Numero di nodi
Il numero massimo di nodi che un set di repliche può avere è 50 con 7 membri votanti. Qualsiasi membro dopo il 7° è considerato senza diritto di voto. Un buon cluster dovrebbe quindi avere 7 membri votanti per rendere conveniente il processo elettorale.
Distribuisci un numero dispari di membri votanti e se hai solo meno di 7 ma un numero pari di membri, dovrai schierare un arbitro come un altro membro votante. Gli arbitri non memorizzano una copia dei dati, quindi richiederanno meno risorse da gestire. Inoltre, uno può sottoporli a un ambiente in cui non potresti sottoporre gli altri membri.
Considerazioni sulla tolleranza ai guasti
A volte alcuni membri potrebbero non essere disponibili a causa di fattori quali interruzioni di corrente o transitori e disconnessioni della rete. Il numero di membri che rimangono nel set e in grado di eleggere un primario crea una situazione nota come Tolleranza ai guasti. È quindi la differenza tra il numero totale di membri del set replica e la maggioranza dei membri votanti necessaria per eleggere una primaria. L'assenza di una primaria impone che le operazioni di scrittura non possano essere eseguite.
La tabella seguente mostra un esempio di relazione tra i tre.
| Membri totali del set di repliche | Maggioranza richiesta per eleggere una nuova primaria | Tolleranza ai guasti |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 5 | 2 |
La relazione non è così diretta in quanto se si aggiungono più membri all'insieme non è detto che la tolleranza agli errori aumenterà come si vede dalla tabella. Membri aggiuntivi forniscono supporto per funzioni dedicate come backup e reporting.
Pianificazione della capacità e bilanciamento del carico per letture pesanti
È necessario disporre di una capacità di riserva per la distribuzione aggiungendo nuovi membri prima che la domanda attuale satura la capacità del set esistente.
Per un traffico di lettura molto elevato, distribuisci le letture del throughput ai membri secondari e ogni volta che il cluster cresce, aggiungi o sposta membri in data center alternativi per ottenere la ridondanza e aumentare la disponibilità dei dati.
Puoi anche utilizzare le operazioni di destinazione con i set di tag per indirizzare le operazioni di lettura a membri specifici o modificare il problema di scrittura per richiedere il riconoscimento da membri specifici.
I nodi devono essere distribuiti geograficamente
Anche i data center potrebbero non funzionare a causa di qualche catastrofe. Si consiglia pertanto di mantenere almeno uno o due membri in un data center separato ai fini della protezione dei dati. Se possibile, utilizza un numero dispari di data center e seleziona una distribuzione che massimizzi la probabilità che, anche in caso di perdita di un data center, i membri rimanenti del set di repliche possano formare la maggioranza o almeno fornire una copia dei dati.
Utilizza l'inserimento nel diario per errori imprevisti
Per impostazione predefinita è abilitato in MongoDB. Assicurati che questa opzione sia abilitata in modo da proteggere la perdita di dati in caso di interruzioni del servizio come riavvii improvvisi e interruzioni di corrente.
Modelli di distribuzione
Esistono principalmente due approcci di distribuzione:
- Tre set di repliche membri che forniscono un'architettura minima consigliata per un set di repliche.
- Set di repliche distribuito su due o più data center per la protezione da guasti specifici della struttura come interruzioni di corrente.
I modelli, tuttavia, dipendono dai requisiti dell'applicazione ma, se possibile, puoi combinare le funzionalità di questi due nella tua architettura di distribuzione.
Nomi host e denominazione dei set di repliche
Utilizzare il nome host DNS logico anziché l'indirizzo IP durante la configurazione dei membri del set di repliche o dei membri del cluster partizionato. Questo per evitare il dolore legato alle modifiche alla configurazione che dovrai apportare a seguito della modifica degli indirizzi IP.
Nel caso della denominazione degli insiemi di repliche, utilizzare nomi distinti per gli insiemi poiché alcuni driver raggruppano le connessioni degli insiemi di repliche in base al nome dell'insieme di repliche.
Conclusione
Il layout dell'architettura per un set di repliche determina la capacità e la capacità della distribuzione. La protezione dei dati e le prestazioni del sistema sono le considerazioni principali durante la configurazione dell'architettura. Si dovrebbero considerare fattori vitali come la tolleranza ai guasti, il numero di membri del set di repliche, la chiave di partizionamento orizzontale ottimale e i modelli di distribuzione per l'elevata disponibilità e la protezione dei dati. La distribuzione geografica dei nodi del set di repliche può affrontare gran parte di questi fattori garantendo la ridondanza e fornendo la tolleranza agli errori se uno dei data center è assente.
