Architetture distribuite

La capacità di accumulare grandi quantità di dati implica che un DBMS NoSQL deve disporre della possibilità di generare architetture multi-nodo come, del resto, fanno anche le soluzioni relazionali. OrientDB permette tutto ciò offrendo così miglioramenti del sistema sotto vari punti di vista: prestazioni, scalabilità, tolleranza ai guasti.

La configurazione

In questa lezione si utilizzerà il termine cluster intendendo un insieme di macchine che, attraverso la rete, collaborano ad un medesimo scopo, come la continuità di funzionamento di un servizio oppure l'aumento della sua efficienza. Questa sottolineatura si rende necessaria poichè abbiamo già incontrato il termine cluster in questa guida, ma come luogo di memorizzazione fisica dei dati. Ovviamente, i due usi del medesimo termine non vanno confusi anche se, come vedremo, hanno effettivamente alcuni punti di contatto.

Tornando a noi, più installazioni OrientDB costituiscono un cluster in cui - a differenza di tanti altri DBMS - i nodi sono tutti Master. Ciò significa che ogni nodo è intercambiabile con un altro. Nella modalità distribuita, il server non andrà avviato con lo script server.sh (o server.bat in Windows), bensì con dserver.sh (rispettivamente, dserver.bat). Quest'ultimo, all'avvio, invierà messaggi in rete per capire se esiste già un cluster OrientDB; qualora non ne trovasse, ne creerebbe automaticamente uno. In una stessa rete possono comunque coesistere più cluster OrientDB, che però non possono comunicare tra loro in quanto isolati e dotati ognuno di un proprio group name.

Per la realizzazione di un cluster viene sfruttato un apposito framework, chiamato Hazelcast Open Source Project e già integrato in OrientDB. I file di configurazione che regolano le architetture distribuite del DBMS sono essenzialmente tre:

• orientdb-server-config.xml, in cui viene abilitato il plugin OHazelcastPlugin. Troveremo infatti un nodo XML di questo tipo:
  

  <handler class="com.orientechnologies.orient.server.hazelcast.OHazelcastPlugin">
              <parameters>
  			...
  			...
  			</parameters>
  </handler>

  
  All'interno del nodo parameters verranno elencati una serie di parametri, ognuno dotato di un nome che lo contraddistingue e di un valore. I due più significativi sono: il parametro enabled, che se impostato a true attiva il plugin e le architetture distribuite; il parametro configuration.hazelcast, che specifica il file di configurazione del plugin. Quest'ultimo, per default, corrisponde a hazelcast.xml nella medesima cartella config;
• default-distributed-db-config.json, file JSON che contiene la configurazione di default per database distribuiti;
• hazelcast.xml, che include name e password di un gruppo che permette l'aggregazione di più server in un cluster, nonchè altre specifiche utili per la fase di discovering di altri cluster nella medesima rete.

L'aggiunta e la rimozione di un nodo del cluster (quest'ultima può essere causata, ad esempio, da uno spegnimento) avvengono in maniera trasparente: le varie installazioni, infatti, riescono a scambiare tra loro la configurazione attuale e aggiornata. Di conseguenza, il sistema di cluster gestito da OrientDB mostra un ottimo livello di tolleranza ai guasti, dal momento che un nodo fuori servizio viene trattato come se fosse stato rimosso dal cluster. In altre parole, l'aggiornamento automatico della configurazione farà sì che tutte le richieste dei client vengano ridistribuite tra i nodi superstiti.

Replication e Sharding

La replication è una delle pratiche più comuni nelle installazioni multi-nodo. Essa permette di mantenere più copie di uno stesso database nello stesso cluster, salvaguardando i dati ed ottimizzando l'elaborazione delle risposte, che possono essere gestite su un maggior numero di macchine. OrientDB implementa la replication con una configurazione Multi-Master, proprio perchè tutti i nodi dei cluster sono Master. Tale approccio permette a qualsiasi nodo di scrivere i record, per poi distribuire le modifiche apportate anche agli altri nodi.

Il passo iniziale del meccanismo di replication consiste nel condividere il database con uno o più nodi del cluster. Ciò può avvenire in due modi:

• quando un server viene avviato, esso invia agli altri nodi una lista dei database che possiede: se un database con lo stesso nome è presente anche negli altri, la replication è impostata in automatico;
• se non vi è un database con lo stesso nome, ma la copia esistente ha la proprietà autodeploy impostata a true, allora la replication partirà ugualmente.

Altra implicazione necessaria in una moderna architettura distribuita è lo sharding, ossia la distribuzione dei dati su più nodi rete. Il meccanismo è gestito a livello di classe grazie alla struttura basata su cluster (intesi questa volta non come rete di nodi, bensì come strutture fisiche di salvataggio dati). Ogni classe vede i suoi dati allocati su cluster diversi, che possono essere collocati su uno o più installazioni di OrientDB. I vari comandi SQL possono essere indirizzati alla classe nel suo complesso, o ad uno specifico set di cluster.

Implementare un'architettura distribuita con OrientDB

Proprio per la automaticità che la contraddistingue, provare ad implementare un'architettura distribuita con OrientDB è piuttosto immediato. Innanzitutto servono due istanze del DBMS in esecuzione sulla stessa rete (per semplicità, si possono usare due macchine virtuali). A questo punto, i server vanno avviati utilizzando lo script dserver.sh, il quale mostrerà sin da subito gli opportuni messaggi di log, che comunicheranno l'aggregazione naturale dei due nel medesimo cluster. Se un'installazione OrientDB viene avviata per la prima volta in modalità distribuita, verrà richiesto quale nome si vuole dare al nodo. Qualora non se ne indicasse nessuno, ne verrà scelto uno di default. Considerando che i server conterranno già il database di default, GrafulDeadConcerts, si potrà usare questo come ambiente di prova.

Per quel che riguarda la replication, sarà sufficiente connettersi ad un server (anche tramite l'interfaccia visuale di Studio) e creare una classe ed alcuni record. Con alcune prove via console, si potrà verificare che i medesimi dati vengono replicati in entrambe le istanze e, ad esempio, spegnendone una i record rimarranno tutti disponibili sulla rimenente. Una volta presa confidenza con la replication, si potrà iniziare a vedere più da vicino l'impiego dello sharding, osservando la dislocazione delle informazioni sui vari cluster.

Transazioni distribuite

Come ultima nota, si consideri che un sistema totalmente transazionale come OrientDB non può trascurare un concetto come le transazioni nella strutturazione di un'architettura distribuita. Essenzialmente, una volta che viene esseguito il commit su una transazione, i dati vengono inviati a tutti i nodi interessati: ognuno sarà responsabile in proprio per il corrispondente commit. Qualora quest'ultimo non dovesse avere successo in ogni installazione, si vedrà se i commit avvenuti correttamente raggiungono il livello minimo imposto da un quorum definito in configurazione. Se tale soglia è stata raggiunta, il commit verrà confermato in tutto il cluster; altrimenti, esso si tramuterà in un ordine di rollback per tutti.