Lo Sharding per la gestione dei Database

Lo sharding è la pratica di ottimizzare i sistemi di gestione dei database separando le righe o le colonne di una grande tabella di database in più tabelle più piccole.

Le nuove tabelle sono chiamate shard (partizioni in inglese) e ogni nuova tabella ha lo stesso schema, ma righe uniche (come nel caso dello “sharding orizzontale”) o ha uno schema che è un sottoinsieme adeguato dello schema della tabella originale (come nel caso dello “sharding verticale”).

Le origini

In un contesto di database, il termine shard deriva molto probabilmente da Computer Corporation of America’s A System for Highly Available Replicated Data che, al contrario del partizionamento orizzontale, utilizzava hardware ridondante per facilitare la replica dei dati o dal videogioco MMORPG Ultima Online del 1997, acclamato dalla critica, che ha stabilito 8 Guinness World Records ed è stato designato dal Time come uno dei 100 più grandi videogiochi prodotti di tutti i tempi.

Richard Garriott, creatore di Ultima Online, ricorda che il termine è stato coniato durante la fase di produzione quando hanno tentato di creare un sistema di ecologia virtuale autoregolante, in cui i giocatori possono sfruttare il nuovo accesso a Internet, una tecnologia rivoluzionaria al tempo, per interagire e raccogliere le risorse del gioco.

Anche se l’ecologia virtuale ha funzionato come previsto durante i test interni, il suo equilibrio naturale è venuto meno quasi istantaneamente a causa dei giocatori che hanno ucciso ogni animale selvatico vivente in tutta l’area giocabile più velocemente di quanto il sistema di riproduzione potesse funzionare. Il team di produzione di Garriott ha cercato di mitigare questo problema separando la base globale dei giocatori in sessioni separate e riscrivendo parte della connessione fittizia di Ultima Online alla fine di Ultima I: The First Age of Darkness, dove la sconfitta del suo antagonista Mondain ha portato anche alla creazione di “frammenti” di multiverso. Questa modifica ha fornito al team di Garriott la base narrativa necessaria per giustificare la creazione di copie dell’ambiente virtuale. Tuttavia, la brusca ascesa del gioco al successo di critica significò anche che il nuovo sistema di ecologia virtuale del multiverso fu rapidamente travolto. Dopo diversi mesi di test, il team di Garriott decise di abbandonare del tutto la caratteristica, e spogliò il gioco della sua funzionalità.

Oggi, il termine shard si riferisce alla distribuzione e all’uso di hardware ridondante nei sistemi di database.

A cosa serve lo sharding

Lo sharding è un concetto comune nelle architetture di database scalabili. Facendo lo sharding di una tabella più grande, è possibile memorizzare i nuovi pezzi di dati, chiamati shard logici, su più nodi per ottenere una

scalabilità orizzontale e migliori prestazioni. Una volta che lo shard logico viene memorizzato su un altro nodo, viene chiamato shard fisico.

Quando si esegue un database su una singola macchina, alla fine si raggiunge il limite della quantità di risorse di calcolo che si possono applicare a qualsiasi query e, ovviamente, si raggiunge una quantità massima di dati con cui si può lavorare in modo efficiente. Scalando orizzontalmente, è possibile abilitare un design di database flessibile che aumenta le prestazioni.

Con l’elaborazione massicciamente parallela è possibile sfruttare tutte le risorse di calcolo del vostro cluster per ogni query;

Poiché i singoli shard sono più piccoli della tabella logica nel suo complesso, ogni macchina deve scansionare meno righe quando risponde a una query.

Lo sharding orizzontale è efficace quando le query tendono a restituire un sottoinsieme di righe che sono spesso raggruppate insieme. Per esempio, le query che filtrano i dati basati su brevi intervalli di date sono ideali per lo sharding orizzontale poiché l’intervallo di date limiterà necessariamente l’interrogazione solo ad un sottoinsieme dei server.

Lo sharding verticale è efficace quando le query tendono a restituire solo un sottoinsieme di colonne dei dati. Per esempio, se alcune query richiedono solo nomi e altre solo indirizzi, allora i nomi e gli indirizzi possono essere suddivisi su server separati.

Inoltre, i database shardati possono offrire livelli più alti di disponibilità. Nel caso di un’interruzione su un database non suddiviso, l’intera applicazione è inutilizzabile. Con un database shardato, solo le porzioni dell’applicazione che si basano sui pezzi di dati mancanti sono inutilizzabili. In pratica, i database shardati spesso mitigano ulteriormente l’impatto di tali interruzioni replicando i frammenti di backup su nodi aggiuntivi.

Differenza tra sharding e partizionamento

Sharding e partizionamento riguardano entrambi la suddivisione di un grande insieme di dati in sottoinsiemi più piccoli.

La differenza è che lo sharding implica che i dati sono distribuiti su più computer, mentre il partizionamento no. Il partizionamento riguarda il raggruppamento di sottoinsiemi di dati all’interno di una singola istanza di database.

In molti casi, i termini sharding e partizionamento sono anche usati come sinonimi, specialmente quando sono preceduti dai termini “orizzontale” e “verticale”. Così, “sharding orizzontale” e “partizionamento orizzontale” possono significare la stessa cosa.

Il partizionamento orizzontale divide una o più tabelle per riga, di solito all’interno di una singola istanza di uno schema e di un server di database. Può offrire un vantaggio riducendo la dimensione dell’indice e quindi lo sforzo di ricerca a condizione che ci sia un modo ovvio, robusto e implicito per identificare in quale partizione si troverà una particolare riga, senza dover prima cercare nell’indice.

Lo sharding va oltre partizionando le tabelle problematiche nello stesso modo, ma lo fa su istanze potenzialmente multiple dello schema. L’ovvio vantaggio risiede nel fatto che il carico di ricerca per la grande tabella partizionata può ora essere diviso su più server, siano essi logici o fisici, non solo su più indici sullo stesso server logico.

Dividere gli shard su più istanze isolate richiede più del semplice partizionamento orizzontale. I guadagni sperati in efficienza andrebbero persi se l’interrogazione del database richiedesse l’interrogazione di più istanze, solo per recuperare una semplice tabella dimensionale. Oltre al partizionamento, lo sharding divide quindi le grandi tabelle partizionabili tra i server, mentre le tabelle più piccole sono replicate come unità complete.

Questo è anche il motivo per cui lo sharding è legato ad un’architettura. Una volta shardato, ogni shard può vivere in un’istanza di schema logico totalmente separata, in un server di database fisico, in un data center, in un diverso continente. Non c’è bisogno di mantenere l’accesso condiviso da uno shard all’altro alle altre tabelle non partizionate in altri shard.

Questo rende facile la replica su più server, mentre il semplice partizionamento orizzontale non lo fa. È anche utile per la distribuzione su scala mondiale delle applicazioni, dove i collegamenti di comunicazione tra i data center sarebbero altrimenti un collo di bottiglia.

C’è anche un requisito per qualche meccanismo di notifica e replica tra le istanze dello schema, in modo che le tabelle non partizionate rimangano strettamente sincronizzate come richiesto dall’applicazione. Questa è una scelta complessa nell’architettura dei sistemi sharded: gli approcci vanno dal rendere queste tabelle effettivamente di sola lettura quando gli aggiornamenti sono rari e in batch, alle tabelle replicate dinamicamente al costo di ridurre alcuni dei benefici di distribuzione dello sharding e molte opzioni miste.

Vantaggi

Il partizionamento orizzontale è un principio di progettazione di database per cui le righe di una tabella di database sono tenute separatamente, piuttosto che essere divise in colonne come la normalizzazione e il partizionamento verticale fanno, in misura diversa. Ogni partizione fa parte di uno shard, che a sua volta può essere situato su un server di database separato o in una posizione fisica.

Ci sono numerosi vantaggi nell’approccio del partizionamento orizzontale.

Poiché le tabelle sono divise e distribuite in più server, il numero totale di righe in ogni tabella in ogni database è ridotto. Questo riduce la dimensione dell’indice, che generalmente migliora le prestazioni di ricerca.

Un frammento di database può essere collocato su un hardware separato, e più frammenti possono essere collocati su più macchine. Questo permette una distribuzione del database su un gran numero di macchine, migliorando notevolmente le prestazioni.

Inoltre, se il frammento di database è basato su qualche segmentazione del mondo reale dei dati (per esempio, clienti nazionali contro clienti stranieri) allora può essere possibile dedurre facilmente e automaticamente l’appropriata appartenenza al frammento e interrogare solo il frammento pertinente.

Svantaggi

Lo sharding dovrebbe essere usato solo quando tutte le altre opzioni di ottimizzazione sono inadeguate. Inoltre, shardare una tabella di database prima che sia stata ottimizzata localmente causa una complessità prematura.

La complessità introdotta dallo sharding del database causa i seguenti potenziali problemi:

• Aumento della complessità SQL che può portare ad un aumento dei bug perché gli sviluppatori devono scrivere SQL più complicato per gestire la logica di sharding;
• Il software aggiuntivo che partiziona, bilancia, coordina e assicura l’integrità può fallire;
• Creazione di singoli punti nevralgici perché la corruzione di uno shard dovuta a problemi di rete/hardware/sistemi causa il fallimento dell’intera tabella;
• Aumento della complessità del server di fail-over che devono avere copie dei parchi di shard del database;
• Aumento della complessità dei backup poiché i backup del database dei singoli shard devono essere coordinati con i backup degli altri shard.
• Aumento della complessità operativa perché aggiungere e/o rimuovere indici, aggiungere e/o eliminare colonne, modificare lo schema diventa molto più difficile.
• Una maggiore dipendenza dall’interconnessione tra i server
• Aumento della latenza nell’interrogazione, specialmente quando si deve cercare in più di uno shard;
• I dati o gli indici sono spesso shardati solo in un modo, così che alcune ricerche sono ottimali e altre sono lente o impossibili;
• Problemi di consistenza e durabilità dovuti alle modalità di guasto più complesse di un insieme di server, che spesso si traducono in sistemi che non danno garanzie sulla consistenza o durabilità cross-shard.

Queste complicazioni storiche dello sharding fai-da-te sono state affrontate da fornitori di software indipendenti che hanno fornito lo sharding automatico.

In pratica, lo sharding è complesso. Anche se è stato fatto per molto tempo con la codifica a mano, questo è spesso poco flessibile. C’è il desiderio di supportare lo sharding automaticamente, sia in termini di aggiunta di supporto al codice per esso, sia per identificare i candidati ad essere shardati separatamente. L’hashing coerente è una tecnica usata nello sharding per distribuire grandi carichi su più servizi e server più piccoli.

Un approccio shard può anche essere utile dove, sia per ragioni di prestazioni che di affidabilità, il calcolo distribuito è usato per separare il carico tra più server.