Scalabilità: lo Sharding

MongoDB è noto per la sua capacità di contenere una gran mole di dati. Una delle caratteristiche più appetibili di questo DBMS è rappresentata dalla facilità con cui è possibile "scalare", in particolare per quel che riguarda la scalabilità orizzontale. Esistono infatti due tipi di scalabilità:

• la scalabilità verticale
• la scalabilità orizzontale

Quindi, dal momento che MongoDB è orientato alla scalabilità orizzontale, ci stiamo fondamentalmente riferendo alla possibilità di realizzare un cluster di database MongoDB per permettere, da un lato, di aumentare le capacità di storage, dall'altro di aumentarne le prestazioni in termini di tempi di risposta. Per sharding si intende la tecnica per la creazione di un database distribuito (anche detto sharded cluster) in cui ogni nodo contiene una porzione del database.

Architettura di uno sharded cluster

In MongoDB per realizzare un cluster in sharding sono necessari tre componenti, almeno uno per tipo:

• router mongos mongos
• shard mongod Replica Set lezione precedente
• config Server mongod

Per un’architettura di produzione sicura, le raccomandazioni sono:

• utilizzare almeno un router mongos
• almeno tre config server single point of failure
• almeno due shard

Avvio e configurazione di un cluster in sharding

Ora vediamo come realizzare un cluster. Ovviamente, per un ambiente di produzione si raccomanda l'uso di una sola macchina per ogni nodo del server. Tuttavia, soprattutto in fase di test, è utile e possibile avviarli tutti sulla stessa macchina: è sufficiente prestare attenzione a non usare le medesime porte, evidando errori.

Per prima cosa avviamo i config server:

> mongod --configsvr --dbpath mongoconfig --port 27033

Tramite l’opzione --configsvr mongod

Per realizzare un cluster di test, possiamo avviare anche un solo config server. Se vogliamo avviarne di più, è sufficiente eseguire lo stesso comando sulle altre macchine.

Ora possiamo avviare il nostro primo router. Dobbiamo usare il programma mongos e, nella riga di comando, specificare l’indirizzo o gli indirizzi dei config server che abbiamo avviato, eventualmente separati da una virgola. La limitazione è che possiamo indicarne o tre o uno solo per ogni router:

> mongos --configdb configserver1:27033

Non ci resta che avviare i nostri shard. Andiamo quindi sulle rispettive macchine e avviamo altrettanti Replica Set, come abbiamo visto nella lezione precedente

> mongod --dbpath mongoconfig --port 27022

A questo punto abbiamo avviato tutti i nodi del nostro cluster, dobbiamo semplicemente configurarlo. Utilizzando la shell mongo mongos mongocluster 27017 mongos

> mongo --host mongocluster --port 27017

Nella consueta shell, ora dobbiamo configurare il cluster con gli shard che abbiamo avviato. Infatti, connettendoci a mongos addShard sh

> sh.addShard("shard1:27022")

Dopo qualche secondo il cluster è configurato e pronto per essere usato. Possiamo connetterci tramite la shell mongo

Abilitazione dello sharding delle collezioni

Per prima cosa dobbiamo abilitare lo sharding sui singoli database, con il metodo enableSharding. Ad esempio:

> sh.enableSharding("bookstore")

Ora dobbiamo istruire il cluster sulla strategia di distribuzione delle collezione tra i nodi. La strategia viene definita in base alla shard key utilizzata. Una shard key è un campo indicizzato che deve essere presente in tutti i documenti di una collezione, e che stabilisce come essa debba essere suddivisa in parti (dette chunk). La shard key può essere definita in due modi:

• basata su intervalli (range-based
• basata su hash (hash-based

La scelta di quali campi usare nella shard key è delicata, e va ponderata in base all’uso che faremo dell’applicazione.

Consideriamo ad esempio un e-commerce di libri e una enorme collezione di libri in vendita. Ovviamente ha senso mettere in sharding questa collezione perché è molto grande. Una collezione del genere potrebbe essere impostata in sharding in base al codice ISBN, e per suddividere equamente il carico sul cluster potremmo usare una shard key hash-based.

Innanzitutto creiamo l’indice sul codice ISBN, se non l’abbiamo già fatto. Questo è infatti un requisito imprescindibile:

> db.books.ensureIndex( { isbn: 1})

A questo punto dobbiamo solamente applicare lo sharding alla collezione, specificando la shard key:

> sh.shardCollection("bookstore.books", { isbn: "hashed" })

Indicando il campo come "hashed" abbiamo creato una shard key hash-based. Se avessimo voluto specificare una shard key basata su intervalli avremmo scritto:

> sh.shardCollection("bookstore.books", { isbn: 1 })

Ora la nostra collezione si trova in sharding nel nostro cluster. Ogni volta che inseriremo un elemento nella nostra collezione, il cluster deciderà in base alla shard key a quale chunk appartiene, e lo invierà allo shard del cluster responsabile di quel chunk. Il bello di tutto ciò è che tali meccanismi sono del tutto trasparenti: dal punto di vista dell'utilizzatore finale, infatti, non c'è alcuna differenza nello scambio di dati con un cluster o con una singola istanza di MongoDB.

Infine segnaliamo un metodo utile per conoscere la suddivisione della collezione, nonchè lo stato del cluster, tramite un report abbastanza dettagliato:

> sh.status()