Panoramica sullo sharding del database

Questa pagina copre:

Lo sharding dei database è uno strumento potente per ottimizzare le prestazioni e la scalabilità di un database. Consente un accesso più rapido ai dati e permette a un database di gestire carichi di lavoro maggiori distribuendo i dati e la potenza di elaborazione su più server. Poiché i database NoSQL sono stati progettati pensando all'elaborazione distribuita e allo sharding automatico, sono spesso i database più associati allo sharding. Tuttavia, con uno sforzo sufficiente, lo sharding può essere realizzato con qualsiasi tecnologia di database.

Come funziona lo sharding dei database?

Lo sharding dei database divide l'intero set di dati in più gruppi, detti shard. Una volta diviso, ogni shard può essere archiviato in modo indipendente, di solito su più server, spesso definiti cluster. Ogni shard è accessibile in modo indipendente, il che significa che è possibile accedere ai dati più velocemente e che sono disponibili più risorse per l'elaborazione, il calcolo e l'archiviazione.

Dove avviene lo sharding?

Se un database dispone di funzioni di sharding integrate, il team di sviluppo richiede meno lavoro per realizzare lo sharding. Se lo sharding è una funzionalità opzionale o richiede una configurazione, è necessario pianificare con attenzione, ma non dovrebbe richiedere modifiche o aggiunte significative alla base di codice. Se il database sottostante non è in grado di eseguire lo sharding (come nel caso di molti database relazionali), potrebbe essere necessario apportare modifiche importanti alla base di codice e gli sviluppatori dovranno integrare lo sharding nel livello di persistenza dell'applicazione.

È necessario suddividere i dati?

La scelta di utilizzare o meno lo sharding dipende da molti fattori. Questi fattori includono le dimensioni del dataset, il numero di utenti del sistema, il numero di operazioni eseguite e i vincoli dell'infrastruttura.

Se l'applicazione subisce un calo notevole delle prestazioni a causa dell'aumento degli utenti o delle operazioni, lo scaling orizzontale (che spesso utilizza lo sharding) è un modo per aumentare le risorse di calcolo disponibili per il database. Ma le scarse prestazioni possono anche indicare un codice non ottimale, la mancanza di indici adeguati, la necessità di modificare la modellazione dei dati o altri problemi. Lo sharding non dovrebbe essere sempre la prima scelta per migliorare le prestazioni, ma per alcune tecnologie di database può essere un mezzo a basso attrito per raggiungere gli obiettivi di performance.

Vantaggi dello sharding

  • Prestazioni più veloci: Ci sono più server disponibili per gestire l'input e l'output.
  • Scalabilità orizzontale: È possibile aggiungere rapidamente altri server a un cluster.
  • Costi: Lo scaling orizzontale può spesso essere meno costoso dello scaling verticale (cioè l'aggiornamento di un server a un altro più potente).
  • Distribuzione/tempo di attività: Un database distribuito scalato orizzontalmente può ottenere un uptime migliore rispetto a un tradizionale server singolo

Svantaggi dello sharding

  • Complessità: A seconda del sistema di database, la complessità dello sharding può variare. Alcuni database sono progettati con distribuzione, scala orizzontale e sharding inclusi. Altri richiedono un approccio più pratico e fai-da-te.
  • Riequilibrio: Quando si aggiungono altre macchine a un cluster, è probabile che gli shard debbano essere riequilibrati per distribuire i dati in modo uniforme (ad esempio, se si hanno 1.000 documenti distribuiti in modo uniforme su tre shard, sono circa 333 documenti per shard. Se si aggiunge un quarto shard, la distribuzione sarebbe pari a 250 documenti per shard). Se un database non dispone di funzioni di sharding integrate, il ribilanciamento sarà sicuramente un processo manuale e complesso.

Tipi di sharding

Esistono diversi approcci allo sharding. Alcuni sistemi di database dispongono di funzionalità di sharding integrate, mentre altri non supportano direttamente lo sharding (e richiedono molti processi di codifica personalizzati o fai-da-te). L'obiettivo di ogni approccio è quello di dividere i dati in shard in modo coerente, in modo che i dati possano essere consultati o scritti ogni volta sullo stesso shard.

Sharding basato sull'intervallo

Lo sharding basato sugli intervalli prevede la selezione dei valori dei dati e la loro assegnazione a uno shard in base al fatto che rientrino o meno in un intervallo specifico. Ad esempio, se i dati degli utenti contengono l'età, uno shard può memorizzare gli utenti di età compresa tra 0 e 10 anni, un altro shard può memorizzare gli utenti di età compresa tra 11 e 20 anni e così via.

Questo approccio può essere problematico perché uno shard potrebbe finire per memorizzare molti più utenti dell'altro. Inoltre, gli shard che memorizzano una quantità sproporzionata di dati possono diventare punti caldi che incidono sulle prestazioni.

Sharding basato su chiavi

Lo sharding basato su chiavi ha un approccio più indipendente. Un valore nei dati (di solito l'ID del documento in un database documentale NoSQL) viene passato attraverso un hash, che determina in quale shard devono essere archiviati i dati.

Questo approccio può essere problematico se non è supportato direttamente dal database, perché qualsiasi applicazione che acceda al database deve essere in grado di costruire l'hash. Inoltre, questo approccio richiede che il valore dei dati utilizzato per l'hash sia immutabile. Di solito non è un problema, ma può esserlo per rari casi limite.

Couchbase utilizza sharding automatico basato su chiavi per distribuire i dati in modo uniforme in un cluster, oltre a fornire il ribilanciamento automatico e la replica automatica. Queste automazioni possono semplificare i processi critici e liberare tempo prezioso per il team di sviluppo.

Sharding basato su directory

Lo sharding basato su directory è un approccio in cui alcuni valori dei dati sono mappati su un particolare shard in base al loro valore in una tabella di ricerca o in una configurazione di ricerca. È simile all'approccio a range, ma può comportare una semplice ricerca. Ad esempio, un utente con un indirizzo in Ohio verrebbe memorizzato nello shard "Ohio", un utente in California andrebbe nello shard "California" e così via.

Questo approccio può essere problematico perché una tabella di ricerca o una configurazione può diventare non disponibile, andare in tilt o essere danneggiata. In questi casi, l'applicazione non può più eseguire letture o scritture.

Geo sharding

Un geo shard può essere combinato o utilizzato al posto delle altre opzioni di sharding. L'idea alla base del geo sharding è quella di memorizzare i dati fisicamente più vicini al luogo in cui si accede più spesso. Ad esempio, un utente con un indirizzo dell'Ohio verrebbe memorizzato su un server dell'Ohio, mentre un utente con un indirizzo della California verrebbe memorizzato su un server della California.

Questo approccio può fornire un accesso più rapido, ma può anche portare a hotspot e server sottoutilizzati. Il geo sharding può anche non soddisfare i requisiti legali per applicazioni o giurisdizioni specifiche.

Oltre a fornire lo sharding automatico, Couchbase può supportare il geo sharding attraverso replica trasversale dei centri dati (XDCR).

Sharding basato su entità

Lo sharding basato sulle entità significa che dati separati, ma strettamente correlati, vengono archiviati insieme nello stesso shard. Ad esempio, un utente può essere considerato un'entità all'interno della logica di un'applicazione, ma la sua cronologia degli acquisti può essere archiviata separatamente in uno shard diverso. Archiviando i dati correlati nello stesso shard, è possibile ridurre la quantità di lavoro di calcolo necessario per recuperarli insieme nello stesso momento.

Lo svantaggio di questo approccio è la complessità. Configurare quali dati vanno dove può essere un processo complesso, soprattutto se alcuni dati sono utilizzati da più entità.

Alternative allo sharding del database

Il ridimensionamento orizzontale comporterà sempre lo sharding a un certo livello, ma esistono molte opzioni per come di sharding. Un modo è lo sharding architetturale, come un'architettura a microservizi o uno sharding su disco fisico che è opaco per l'utente. Lo sharding può anche essere nascosto e astratto dietro un database cloud.

Quando si prende in considerazione un sistema di database, è fondamentale capire come verrà realizzato lo sharding. Può essere completamente astratto e nascosto, può essere automatico, può essere supportato con opzioni di configurazione potenzialmente complesse o può non essere supportato e richiedere un approccio fai-da-te.

Come Couchbase Capella aiuta con lo sharding del database

Couchbase Capella è la piattaforma di database cloud per le imprese digitali.

Capella utilizza lo stesso sistema di sharding di Couchbase Server, ovvero lo sharding automatico basato su chiavi. Dal punto di vista dell'utente o dello sviluppatore, lo sharding con Couchbase non richiede alcuna configurazione o manutenzione aggiuntiva. Utilizzando un algoritmo CRC32 insieme a vBucket, Capella garantisce che il sistema non presenti hotspot.

Capella automatizza la replica. È sufficiente selezionare il numero di repliche desiderate e Capella si occuperà del resto.

Capella automatizza anche il ribilanciamento. Quando si aggiungono server o li si rimuove da un cluster, Capella li riequilibra automaticamente senza causare alcun tempo di inattività.

Infine, Capella può realizzare il geo sharding tramite la funzione XDCR. XDCR replica i dati tra i data center in tempo reale. Le repliche XDCR possono includere o escludere i dati in base a filtri definiti dall'utente per migliorare la latenza locale o per soddisfare i requisiti di localizzazione dei dati.

Conclusione

Lo sharding è un concetto importante da comprendere se si vuole scalare un database per gestire più operazioni. I database NoSQL sono particolarmente adatti allo sharding perché eliminano molti dei vincoli imposti dai database relazionali. Detto questo, Couchbase Capella offre alcune delle migliori caratteristiche di un database relazionale (sintassi SQL e un'implementazione completa di SQL che include JOIN e Transazioni ACID) a un database distribuito con sharding automatico.

Per saperne di più sullo sharding in Couchbase, consultare il sito:

Altre risorse importanti per valutare come scalare un database:

Iniziare a costruire

Consultate il nostro portale per sviluppatori per esplorare NoSQL, sfogliare le risorse e iniziare con le esercitazioni.

Sviluppare ora
Prova Capella gratuitamente

Per iniziare a lavorare con Couchbase bastano pochi clic. Capella DBaaS è il modo più semplice e veloce per iniziare.

Utilizzare gratuitamente
Couchbase per gli ISV

Creare applicazioni potenti con meno complessità e costi.

Per saperne di più