MongoDB Sharding: tutorial passo passo con esempio

In cosa consiste lo Sharding MongoDB?

Lo sharding è un concetto in MongoDB, che suddivide set di dati di grandi dimensioni in set di dati piccoli su più file MongoDB le istanze.

A volte i dati all'interno MongoDB saranno così enormi che le query su set di dati così grandi possono causare un elevato utilizzo della CPU sul server. Per affrontare questa situazione, MongoDB ha un concetto di Sharding, che è fondamentalmente la suddivisione di set di dati su più set MongoDB le istanze.

La collezione, che può essere di grandi dimensioni, è in realtà suddivisa in più collezioni, o Frammenti come vengono chiamati. Logicamente, tutti i frammenti funzionano come un'unica collezione.

Vantaggi dello sharding in MongoDB

Prima di implementare un cluster sharded, è utile capire perché i team adottano lo sharding. I principali vantaggi sono:

• Scalabilità orizzontale: I dati vengono distribuiti su numerosi server standard anziché costringere una singola macchina a diventare sempre più grande.
• Maggiore produttività: Le operazioni di lettura e scrittura vengono eseguite in parallelo tra gli shard, consentendo al cluster di gestire un maggior numero di richieste al secondo.
• Maggiore capacità di stoccaggio: Il disco combinato di tutti gli shard può contenere set di dati di dimensioni di gran lunga superiori a quelle che un singolo server potrebbe archiviare.
• Alta disponibilità: Quando ogni shard viene distribuito come set di repliche, il guasto di un singolo nodo non provoca l'arresto dell'intero cluster.
• Carico bilanciato: Migliori MongoDB Il bilanciatore ridistribuisce automaticamente i blocchi di dati per impedire che un singolo shard diventi un hotspot.

Insieme, questi vantaggi rendono lo sharding l'approccio standard per la scalabilità MongoDB oltre i limiti di un singolo server.

Come implementare lo sharding

Gli shard vengono implementati utilizzando i cluster, che non sono altro che un gruppo di MongoDB le istanze.

I componenti di uno Shard includono:

1. Un frammento – Questa è la cosa fondamentale, e questo non è altro che a MongoDB istanza che contiene il sottoinsieme dei dati. Negli ambienti di produzione, tutti i frammenti devono far parte di set di repliche.
2. Server di configurazione - Questo è un MongoDB istanza che contiene metadati sul cluster, in pratica informazioni sui vari MongoDB istanze che conterranno i dati dello shard.
3. Un router - Questo è un MongoDB istanza che è fondamentalmente responsabile del reindirizzamento dei comandi inviati dal client ai server corretti.

Sharding passo dopo passo Cluster Esempio

Passo 1) Crea un database separato per il server di configurazione.

mkdir /data/configdb

Passo 2) Avvia la MongoDB Esempio in modalità di configurazione. Supponiamo di avere un server chiamato Server D, che fungerà da server di configurazione. Dovremo eseguire il comando seguente per configurare il server come server di configurazione.

mongod --configdb ServerD:27019

Passo 3) Avvia l'istanza di mongos specificando il server di configurazione.

mongos --configdb ServerD:27019

Passo 4) Dalla shell di mongo, connettiti all'istanza di mongos.

mongo --host ServerD --port 27017

Passo 5) Se si dispone di Server A e Server B che devono essere aggiunti al cluster, eseguire i comandi seguenti.

sh.addShard("ServerA:27017")
sh.addShard("ServerB:27017")

Passo 6) Abilita lo sharding per il database. Quindi, se è necessario suddividere in shard il database Employeedb, eseguire il comando seguente.

sh.enableSharding("Employeedb")

Passo 7) Abilita lo sharding per la raccolta. Quindi, se devi suddividere la raccolta Employee, esegui il comando seguente.

sh.shardCollection("Employeedb.Employee", { "Employeeid": 1, "EmployeeName": 1 })

Come scegliere una chiave Shard in MongoDB

La chiave di partizione è il campo indicizzato, o insieme di campi, che MongoDB La chiave viene utilizzata per decidere in quale shard memorizzare ciascun documento. Poiché la chiave determina la distribuzione dei dati, sceglierla correttamente è la decisione più importante in un'implementazione con sharding. Una chiave inadeguata concentra dati e traffico su un unico shard, vanificando i vantaggi dello sharding.

Una chiave di shard robusta generalmente presenta le seguenti caratteristiche:

• Cardinalità elevata: Il campo dovrebbe avere molti valori possibili in modo che i dati possano essere suddivisi in molti blocchi più dettagliati.
• Bassa frequenza: Nessun singolo valore dovrebbe prevalere, altrimenti i documenti che condividono quel valore si accumuleranno su un unico frammento.
• Variazione non monotona: Le chiavi che aumentano sempre, come i timestamp, inviano ogni nuova scrittura allo stesso shard, creando un hotspot.

MongoDB Supporta due strategie di sharding basate sulla chiave. Lo sharding per intervalli divide i dati in intervalli contigui ed è adatto alle query di intervallo, mentre lo sharding con hash applica una funzione hash per distribuire uniformemente le scritture tra gli shard. I team spesso iniziano con lo sharding con hash quando le scritture sono intense e passano allo sharding per intervalli quando predominano le letture basate su intervalli. Indipendentemente dalla strategia scelta, testa la chiave con modelli di query realistici prima di confermarla, perché la chiave di sharding non può essere modificata facilmente una volta caricati i dati.

Sharding vs Replicazione in MongoDB

Sharding e replica sono funzionalità complementari ma distinte. La tabella seguente evidenzia le differenze, in modo da poterle applicare correttamente; in pratica, i cluster di produzione le utilizzano entrambe.

In sintesi, lo sharding risponde all'esigenza di scalabilità, mentre la replica risponde all'esigenza di disponibilità, e un'implementazione robusta combina entrambe.

DOMANDE FREQUENTI