Vai al contenuto

Rapida introduzione allo sharding

  • di

Prima di parlare di sharding, diamo una rapida overview sul data partitioning:

Data Partitioning

Il data partitioning è una tecnica per suddividere un database/datastore in diverse parti più piccole. Ad esempio può essere il processo di suddivisione di un database o di una tabella su più macchine per migliorarne la gestibilità, le prestazioni e la disponibilità dei dati.

Metodi

Esistono modi diversi per decidere come suddividere un database in più DB più piccoli. Di seguito sono riportati tre dei metodi più maggiormente utilizzati da varie applicazioni su larga scala:

Horizontal Partitioning (o Sharding)

Con questa strategia, i dati della tabella vengono suddivisi orizzontalmente in base all’intervallo di valori definito dalla chiave di partizione. Viene anche definito come database sharding.

Vertical Partitioning

Nel partizionamento verticale, i dati vengono suddivisi verticalmente in base alle colonne. Si dividono le tabelle in tabelle relativamente più piccole (ciascuna con meno colonne) e ogni parte dei dati è presente in una partizione separata.

Cos’è lo sharding?

Lo sharding è un modello architetturale di database correlato al partizionamento orizzontale, ovvero la pratica di separare le righe di una tabella in più tabelle diverse, note come partizioni o shard. Ogni partizione ha lo stesso schema, le stesse colonne, ma anche un sottoinsieme dei dati condivisi. Allo stesso modo, i dati contenuti in ciascuna partizione sono unici e indipendenti da quelli contenuti nelle altre partizioni.

La giustificazione dello sharding dei dati è che, dopo un certo punto, è più economico e fattibile scalare orizzontalmente aggiungendo più nodi/macchine che scalare verticalmente aggiungendo server più performanti. Lo sharding può essere implementato sia a livello di applicazione che di database.

Criteri di partizionamento

Esistono un gran numero di criteri per il partizionamento dei dati. Alcuni dei criteri comunemente utilizzati sono:

Hash-Based

Questa strategia divide le righe in diverse partizioni basate su un algoritmo di hashing piuttosto che raggruppare le righe del database in base a indici continui.

Lo svantaggio di questo metodo è che l’aggiunta/rimozione dinamica di nodi diventa costosa poiché bisogna ricalcolare gli hash e ridistribuire i dati tra i nodi.

List-Based

Nel partizionamento basato su elenchi, ogni partizione viene definita e selezionata in base all’elenco di valori di una colonna piuttosto che a un insieme di intervalli di valori contigui.

Range Based

Il partizionamento per intervallo (range based) mappa i dati in varie partizioni basate su intervalli di valori della chiave di partizione. In altre parole, si partiziona la tabella in modo che ogni partizione contenga righe all’interno di un determinato intervallo definito dalla chiave di partizione.

Gli intervalli devono essere contigui ma non sovrapposti, e ogni intervallo specifica un limite inferiore e superiore non inclusivo per una partizione. Qualsiasi valore della chiave di partizione uguale o superiore al limite superiore dell’intervallo viene aggiunto alla partizione successiva.

Composite

Il partizionamento composito (Composite) suddivide i dati in base a due o più tecniche di partizione. In questo caso, i dati vengono prima suddivisi con una tecnica e poi ogni partizione viene ulteriormente suddivisa in sottopartizioni utilizzando lo stesso metodo o un altro.

Vantaggi

Ma perché dobbiamo aver bisogno dello sharding? Ecco alcuni vantaggi:

  • Disponibilità: Fornisce indipendenza logica al database partizionato, garantendo l’alta disponibilità della nostra applicazione. Le singole partizioni possono essere gestite in modo indipendente.
  • Scalabilità: Aumenta la scalabilità distribuendo i dati su più partizioni, possibilità di aggiungere partizioni all’occorrenza.
  • Sicurezza: Contribuisce a migliorare la sicurezza del sistema memorizzando i dati sensibili e non sensibili in partizioni diverse. Questo potrebbe fornire una migliore gestibilità e sicurezza dei dati sensibili.
  • Prestazioni delle interrogazioni: Migliora le prestazioni del sistema. Invece di interrogare l’intero database, ora il sistema deve interrogare solo una partizione più piccola.
  • Gestibilità dei dati: Divide le tabelle e gli indici in unità più piccole e gestibili.

Svantaggi

  • Complessità: Lo sharding aumenta la complessità del sistema in generale.
  • Join tra shard: Una volta che un database è partizionato e distribuito su più nodi non ci offre la possibilità di eseguire join che coprano più shard del database. Tali join non sono efficienti dal punto di vista delle prestazioni, poiché i dati devono essere recuperati da più server, con possibili tempi di accesso differenti.
  • Rebalancing: Se la distribuzione dei dati non è uniforme o c’è molto carico su un singolo shard questo potrebbe diventare un hotspot e rallentare il sistema generale, in questi casi dobbiamo riequilibrare gli shard in modo che le richieste siano distribuite nel modo più equo possibile tra gli shard.

Quando usare lo sharding?

Ecco alcuni motivi per cui lo sharding potrebbe essere la scelta giusta per il nostro caso d’uso:

  • Sfruttare l’hardware esistente invece di acquistare nuove macchine di fascia alta.
  • Mantenere i dati in regioni geografiche distinte.
  • Scalare rapidamente aggiungendo nodo all’occorrenza.
  • Migliorare le prestazioni poiché ogni macchina viene sottoposta a un carico minore.
  • Quando sono necessarie più connessioni simultanee.Rapida introduzione allo sharding