Una guida per sviluppatori allo sharding di MongoDB

Un'enorme crescita di dati comporta un costo di operazioni di throughput ridotte, soprattutto se servite da un singolo server. Tuttavia, puoi migliorare queste prestazioni aumentando il numero di server e anche distribuendo i tuoi dati su più numeri di questi server. In questo articolo, Replica imposta in MongoDB, abbiamo discusso in dettaglio come le operazioni di throughput possono essere migliorate oltre a garantire un'elevata disponibilità dei dati. Questo processo non può essere raggiunto completamente senza menzionare lo Sharding in MongoDB.

Cos'è lo sharding in MongoDB

MongoDB è progettato in modo flessibile in modo tale che sia scalabile per l'esecuzione in un cluster su una piattaforma distribuita. In questa piattaforma, i dati vengono distribuiti su una serie di server per l'archiviazione. Questo processo è ciò che viene definito sharding. Se un singolo server è soggetto a una grande quantità di dati per l'archiviazione, potresti esaurire lo spazio di archiviazione. Inoltre, le operazioni di throughput molto critiche come la lettura e la scrittura possono risentirne in larga misura. La funzionalità di ridimensionamento orizzontale in MongoDB ci consente di distribuire i dati su più macchine con il risultato finale di migliorare il bilanciamento del carico.

Shard MongoDB

Uno shard può essere considerato un set di repliche che ospita un sottoinsieme di dati utilizzato in un cluster partizionato. Per una determinata istanza mongod con un set di dati, i dati vengono suddivisi e distribuiti su una serie di database, in questo caso frammenti. Fondamentalmente, diversi shard fungono da database indipendenti ma insieme costituiscono un database logico. Gli shard riducono il carico di lavoro che deve essere eseguito dall'intero database riducendo il numero di operazioni che uno shard dovrebbe gestire oltre alla minore quantità di dati che ospiterà questo shard. Questa metrica offre spazio per l'espansione di un cluster in orizzontale. Di seguito viene mostrata una semplice architettura di partizionamento orizzontale.

I dati inviati da un'applicazione client vengono intercettati dai driver del server e quindi inviati al router. Il router consulterà quindi le configurazioni del server per determinare dove applicare l'operazione di lettura o scrittura sui server shard. In poche parole, per un'operazione come la scrittura, ha un indice che detterà a quale shard è il record come host. Supponiamo che un database abbia una capacità di dati di 1 TB distribuita su 4 shard, ogni shard conterrà 256 GB di questi dati. Con una quantità ridotta di dati che uno shard può gestire, le operazioni possono essere eseguite abbastanza velocemente. Dovresti considerare l'utilizzo del cluster partizionato nel tuo database quando:

Prevedi che la quantità di dati supererà in futuro la tua capacità di storage a istanza singola.
Se le operazioni di scrittura non vengono eseguite dalla singola istanza MongodB
Si esaurisce la RAM della memoria ad accesso casuale a scapito della maggiore dimensione del working set attivo.

Lo sharding comporta una maggiore complessità dell'architettura oltre a risorse aggiuntive. Tuttavia, è consigliabile eseguire lo sharding nelle fasi iniziali prima che i tuoi dati diventino troppo grandi, poiché è piuttosto noioso farlo quando i tuoi dati sono oltre la capacità.

Chiave shard MongoDB

Come tutti sappiamo, un documento in MongoDB ha campi per contenere i valori. Quando distribuisci un partizionamento orizzontale, ti verrà richiesto di selezionare un campo da una raccolta che utilizzerai per dividere i dati. Questo campo selezionato è la chiave shard che determina come dividere i documenti nella raccolta su un numero di shard. In un semplice esempio, i tuoi dati potrebbero avere nomi di campo studenti, insegnanti di classe e voti. Puoi decidere un set di frammenti per contenere i documenti con lo studente indice, un altro insegnanti e i voti. Tuttavia, potresti richiedere che i tuoi dati vengano distribuiti in modo casuale, quindi utilizza una chiave shard con hash. Esiste un intervallo di chiavi shard utilizzate nella divisione dei dati oltre alla chiave shard con hash, ma le due categorie principali sono il campo indicizzato e i campi composti indicizzati.

Scelta di una chiave shard

Per una migliore funzionalità, capacità e prestazioni della strategia di partizionamento orizzontale, dovrai selezionare la chiave partizionata appropriata. I criteri di selezione dipendono da 2 fattori:

Struttura schematica dei tuoi dati. Possiamo ad esempio considerare un campo il cui valore potrebbe essere crescente o decrescente (cambiando monotonicamente). Molto probabilmente ciò influenzerà la distribuzione di inserti su un singolo shard all'interno di un cluster.
Come vengono presentate le tue configurazioni di query per eseguire operazioni di scrittura.

Cos'è una chiave shard con hash

Questo utilizza un indice hash di un singolo campo come chiave shard. Un indice hash è un indice che mantiene le voci con hash dei valori di un campo indicizzato, ad esempio

{
    "_id" :"5b85117af532da651cc912cd"
}

Per creare un indice hash puoi usare questo comando nella mongo shell.

db.collection.createIndex( { _id: hashedValue } )

Dove la variabile hasedValue rappresenta una stringa del valore hash specificato. L'hashing sharding promuove una distribuzione uniforme dei dati in un cluster shard, riducendo così le operazioni di destinazione. Tuttavia, è improbabile che documenti con quasi le stesse chiavi shard si trovino sullo stesso shard, quindi richiedono a un'istanza mongo di eseguire un'operazione di trasmissione per soddisfare un determinato criterio di query.

Chiave shard basata sull'intervallo

In questa categoria, il set di dati è partizionato in base agli intervalli di valori di una chiave di campo scelta, quindi un intervallo elevato di partizioni. Cioè. se hai una chiave numerica i cui valori vanno da infinito negativo a infinito positivo, ogni chiave shard cadrà in un certo punto all'interno di quella linea. Questa riga è divisa in blocchi con ogni blocco che ha un certo intervallo di valori. Precisamente, quei documenti con una chiave di partizione quasi simile sono ospitati nello stesso blocco. Il vantaggio di questa tecnica è che supporta una serie di query poiché il router selezionerà lo shard con il blocco specifico.

Caratteristiche di una chiave shard ottimale

Una chiave shard ideale dovrebbe essere in grado di indirizzare un singolo shard per migliorare un programma mongos per restituire operazioni di query da una singola istanza mongod. La chiave essendo campo primario caratterizza questo. Cioè. non in un documento incorporato.
Avere un alto grado di casualità. Vale a dire, il campo dovrebbe essere disponibile nella maggior parte dei documenti. Ciò garantirà che le operazioni di scrittura siano distribuite all'interno di uno shard.
Sii facilmente divisibile. Con una chiave shard facilmente divisibile, aumenta la distribuzione dei dati, quindi più shard.

Multiplenines Diventa un DBA MongoDB - Portare MongoDB in produzioneScopri cosa devi sapere per distribuire, monitorare, gestire e ridimensionare MongoDBScarica gratuitamente

Componenti di una distribuzione in cluster di produzione

Per quanto riguarda l'architettura mostrata sopra, il cluster di shard di produzione dovrebbe avere:

Mongos/Router di query. Si tratta di istanze mongo che fungono da server tra i driver dell'applicazione e il database stesso. Nella distribuzione, il sistema di bilanciamento del carico è configurato in modo da consentire la connessione da un singolo client per raggiungere gli stessi mongo.
Frammenti. Queste sono le partizioni all'interno delle quali sono ospitati i documenti che condividono la stessa definizione di chiave shard. Dovresti averne almeno 2 per aumentare la disponibilità dei dati.
Server di configurazione:puoi avere 3 server di configurazione separati su macchine diverse o un gruppo di essi se avrai più cluster partizionati.

Distribuzione di un cluster frammentato

I passaggi seguenti ti daranno una chiara direzione verso la distribuzione del tuo cluster partizionato.

Creazione dell'host per i server di configurazione. Per impostazione predefinita, i file del server sono disponibili nella directory /data/configdb ma puoi sempre impostarla sulla tua directory preferita. Il comando per creare la directory dei dati è:
```
$ mkdir /data/configdb
```
Avvia i server di configurazione definendo la porta e il percorso del file per ciascuno utilizzando il comando
```
$ mongod --configsvr --dbpath /data/config --port 27018
```
Questo comando avvierà il file di configurazione nella directory dei dati con il nome config sulla porta 27018. Per impostazione predefinita, tutti i server MongoDB funzionano sulla porta 27017.
Avvia un'istanza mongos utilizzando la sintassi:
```
$ mongo --host hostAddress --port 27018.
```
La variabile hostAddress avrà il valore per il nome host o l'indirizzo IP del tuo host.
Avvia mongod sul server shard e avvialo utilizzando il comando:
```
mongod --shardsvr --replSet
rs.initiate()
```
Avvia i tuoi mongo sul router con il comando:
```
mongos --configdb rs/mongoconfig:27018
```
Aggiunta di shard al tuo cluster. Diciamo che abbiamo la porta predefinita 27017 come nostro cluster, possiamo aggiungere uno shard sulla porta 27018 in questo modo:
```
mongo --host mongomaster --port 27017
sh.addShard( "rs/mongoshard:27018")
{ "shardAdded" : "rs", "ok" : 1 }
```

Abilita lo sharding per il database utilizzando il nome shard con il comando:

sh.enableSharding(shardname)
{ "ok" : 1 }

Puoi controllare lo stato dello shard con il comando:

sh.status()

Ti verranno presentate queste informazioni

sharding version: {
"_id" : 1,
"minCompatibleVersion" : 5,
"currentVersion" : 6,
"clusterId" : ObjectId("59f425f12fdbabb0daflfa82")
}
shards:
{ "_id" : "rs", "host" : "rs/mongoshard:27018", "state" : 1 }
active mongoses:
"3.4.10" : 1
autosplit:
Currently enabled: yes
balancer:
Currently enabled: yes
Currently running: no
NaN
Failed balancer rounds in last 5 attempts: 0
Migration Results for the last 24 hours:
No recent migrations
databases:
{ "_id" : shardname, "primary" : "rs", "partitioned" : true }

Bilanciamento dei frammenti

Dopo aver aggiunto uno shard a un cluster, potresti osservare che alcuni shard potrebbero ancora ospitare più dati di altri e per essere più secanti, il nuovo shard non avrà dati. È quindi necessario eseguire alcuni controlli in background per garantire il bilanciamento del carico. Il bilanciamento è la base per la quale i dati vengono ridistribuiti in un cluster. Il bilanciatore rileverà una distribuzione non uniforme, quindi migrerà i blocchi da uno shard all'altro fino al raggiungimento del quorum di bilanciamento.

Il processo di bilanciamento consuma molta larghezza di banda oltre alle spese generali del carico di lavoro e ciò influirà sul funzionamento del database. Un migliore processo di bilanciamento prevede:

Spostare un singolo blocco alla volta.
Esegui il bilanciamento quando viene raggiunta la soglia di migrazione, ovvero quando viene rilevata la differenza tra il numero più basso di blocchi per una data raccolta e il numero più alto di blocchi nella raccolta partizionata.