La creazione di un sito web è il primo passo per costruire la vostra presenza su Internet. Per prosperare a lungo termine, dovete anche assicurarvi che il vostro sito sia in grado di scalare per adattarsi alla crescita. Uno dei primi passi da compiere è quello di implementare un database in grado di scalare insieme a voi. In caso contrario, rischierete di avere prestazioni lente nelle query e interruzioni del database.
In questo articolo parleremo di come usare lo sharding del database per ottenere un’elevata scalabilità e disponibilità dei dati. Parleremo anche degli svantaggi dello sharding e delle diverse architetture di sharding che potete usare.
Cos’È lo Sharding dei Database?
Lo sharding è una tecnica di ottimizzazione che distribuisce le tabelle su altri server di database. È simile al partizionamento, nel senso che entrambi prevedono la suddivisione dei dati in sottoinsiemi più piccoli. La differenza è che lo sharding distribuisce questi sottoinsiemi su server diversi, mentre il partizionamento li memorizza in un unico database. Questi server usano lo stesso motore di database e lo stesso tipo di hardware per ottenere un livello di prestazioni simile per tutti gli shard.
Lo sharding mira a realizzare un’architettura share-nothing, eliminando i colli di bottiglia dell’elaborazione e i singoli punti di errore.
Lo sharding può essere implementato in due modi: in orizzontale e in verticale. Lo sharding orizzontale divide la tabella in base alle righe, mentre quello verticale in base alle colonne.
In questo senso, lo sharding è come il partizionamento, che divide le tabelle di grandi dimensioni in tabelle più piccole.
Lo sharding orizzontale è efficace per i database in cui la maggior parte delle query restituisce un sottoinsieme di righe, come per esempio un database di clienti che restituisce dati (come nome, indirizzo, email e così via) in una sola volta.
Lo sharding verticale è efficace per i database le cui query restituiscono singole colonne. Per esempio, se il database dei clienti restituisce il nome o l’email del cliente separatamente, potete separare il nome e l’email in cluster diversi.
Vantaggi dello Sharding dei Database
Di seguito vediamo alcuni dei vantaggi dello sharding dei database.
Miglioramento della Scalabilità Orizzontale
Potete scalare il vostro database in senso verticale o orizzontale. La scalabilità verticale si riferisce all’aggiunta di più unità di elaborazione centrale (CPU) e memoria ad accesso casuale (RAM) al server per migliorare le prestazioni. Il vertical scaling è una soluzione utile per i database di piccole e medie dimensioni. Tuttavia, quando i dati crescono, il vertical scaling diventa impraticabile. Non c’è molta potenza che si possa aggiungere a un singolo server.
Il ridimensionamento orizzontale è più flessibile. Vi permette di scalare il vostro database in base alle esigenze aggiungendo altri server al sistema. Ognuno di questi server fornisce risorse a diversi shard del database. Questo distribuisce il carico di lavoro e migliora la capacità del sistema di gestire un numero maggiore di richieste.
Tempi di Risposta alle Query Più Rapidi
Gli shard hanno solo poche righe e colonne. Per questo motivo, l’elaborazione delle query del database richiede meno tempo. Al contrario, un’interrogazione su un database non shardato potrebbe richiedere una ricerca su centinaia o addirittura migliaia di righe.
Maggiore Affidabilità in Caso di Interruzioni di Servizio
Le interruzioni del database si verificano per vari motivi, tra cui la cancellazione accidentale dei dati, gli errori di connessione e gli attacchi di cybersecurity. Lo sharding riduce al minimo gli effetti delle interruzioni. Poiché ogni shard è autonomo, solo lo shard interessato subisce un’interruzione. Per esempio, se avete quattro shard e si verifica un’interruzione in uno di essi, solo il 25% delle operazioni ne risentirà.
Gli Svantaggi dello Sharding
Sebbene lo sharding migliori l’affidabilità e la disponibilità di un database, la sua implementazione è complessa. L’utilizzo di un’architettura di sharding sbagliata può rallentare le prestazioni e causare la perdita di dati.
Verificate di scegliere una tecnica di sharding che permetta una distribuzione equilibrata dei dati su tutti gli shard. Senza questo equilibrio, rischiate di creare degli hotspot del database, che si verificano quando uno shard memorizza la maggior parte dei dati mentre gli altri shard rimangono praticamente vuoti. Questo riduce il throughput di scrittura del singolo shard.
Per risolvere questo problema, potreste partizionare ulteriormente lo shard non bilanciato, ma questo processo è impegnativo e potrebbe causare la chiusura del database durante la migrazione dei dati.
Un altro inconveniente dello sharding è che le unioni SQL che coinvolgono più tabelle in shard diversi possono diventare troppo lente e peggiorare le prestazioni. Tuttavia, con la giusta architettura, potete evitare questo problema.
Architetture di Sharding
Potete implementare lo sharding utilizzando tre architetture:
- Sharding basato su chiavi
- Sharding basato sull’intervallo
- Sharding basato su directory
L’architettura che scegliete dipende dal vostro caso d’uso.
Sharding Basato su Chiavi
In un’architettura di sharding basata su chiavi o hashed, un’applicazione di database usa una chiave di shard per individuare uno shard. Una funzione di hashing esegue l’hashing del valore della chiave di sharding e l’output mappa i dati in un determinato shard. Una semplice funzione di hashing può essere il modulo della chiave e il numero di shard.
La funzione di hash può accettare più di una chiave di sharding. Per questo motivo, lo sharding basato sulle chiavi è adatto ai record di dati che possono avere chiavi condivise. La distribuzione algoritmica dei dati riduce al minimo la possibilità di creare hotspot del database in cui uno shard contiene più dati dell’altro.
Tuttavia, poiché la distribuzione si basa solo sulla funzione di hashing, è impossibile raggruppare logicamente i dati. Di conseguenza, le operazioni di database che richiedono dati da più shard possono essere inefficienti perché richiedono la lettura dei dati da ogni shard.
Sharding Basato sull’Intervallo
Lo sharding basato sull’intervallo prevede lo sharding di un database in base a un intervallo di valori specificato.
Usa una chiave di sharding per determinare a quale shard assegnare un valore. L’applicazione di database controlla lo shard che corrisponde alla chiave di sharding in una tabella di ricerca e memorizza i dati. Per questo motivo, lo sharding basato sul range è facile da progettare e implementare.
Per esempio, potete usare il valore dell’ID utente in un database di utenti come chiave di sharding. Potreste archiviare gli utenti con ID compreso tra 0 e 2.000 in uno shard, quelli tra 2.000 e 4.000 in un altro shard e così via.
Lo sharding basato sull’intervallo può causare hotspot nel database. Considera un database di utenti in cui la maggior parte dei tuoi ID si trova tra 2.001 e 4.000. Il processo li assegna a un unico shard, creando uno squilibrio nel tempo. Lo sharding basato sull’intervallo, quindi, funziona meglio per i dati distribuiti in modo uniforme.
Sharding Basato su Directory
Lo sharding basato su directory raggruppa i dati logicamente correlati nello stesso shard. Usa una tabella di ricerca contenente un elenco di mappature per ogni entità del database. Ogni mappatura corrisponde a uno shard del database.
Lo sharding basato su directory è più flessibile di quello basato su range o chiavi perché potete aggiungere dati agli shard in modo dinamico. Non ci sono funzioni di sharding da seguire o valori di intervallo da rispettare. Questa flessibilità aumenta l’efficienza del database: potete archiviare dati correlati in un unico shard, il che significa che l’esecuzione di query comuni richiede meno tempo.
Per esempio, se usate uno sharding basato su directory e raggruppate gli utenti in base alla loro posizione, recuperando gli utenti da un luogo particolare, interrogherete un solo shard.
Sharding del Database con Kinsta
La maggior parte dei moderni motori di database supporta lo sharding dei database. Uno di questi motori di database è MariaDB, un fork di MySQL supportato commercialmente. È un sistema di database open-source ad alte prestazioni adottato da aziende come IBM, GitHub e Wikimedia. Fa anche parte dello stack di server ad alte prestazioni di Kinsta.
MariaDB offre funzioni di sharding integrate grazie allo spider storage engine. Lo spider storage engine è un motore di formazione di cluster che supporta il partizionamento e le transazioni ad architettura estesa (XA). Vi permette di trattare tabelle remote di istanze diverse come se fossero nella stessa istanza. Una volta creata una tabella nello spider storage engine, la tabella si collega a un’altra tabella nel server MariaDB remoto. Una volta stabilita la connessione, il motore di archiviazione condivide il collegamento con tutte le tabelle che fanno parte della stessa transazione.
Riepilogo
Lo sharding del database è una tecnica di scalabilità che suddivide le tabelle in sottoinsiemi più piccoli e li distribuisce a diversi server chiamati shard. Lo sharding può essere implementato in vari modi, come lo sharding basato su chiavi, lo sharding basato su range e lo sharding basato su directory.
Sebbene lo sharding migliori la scalabilità, l’affidabilità e la disponibilità di un database, è molto complesso da implementare. Inoltre, una volta creato uno shard, non è facile riportare il database allo stato non shardato. Per questo motivo, meglio lo sharding per l’ottimizzazione solo quando avete la sicurezza che le altre opzioni di scalabilità non funzionano.
Che la vostra attività sia una no-profit o un’impresa di livello enterprise, le soluzioni esperte di Kinsta possono eliminare le preoccupazioni legate all’hosting del sito, e vi permettono di concentrarvi su ciò che conta di più.
Lascia un commento