Questo metodo utilizza una formula matematica (una funzione hash) sulla chiave di shard per assegnare i dati. Ad esempio, il sistema potrebbe calcolare l'ID utente (mod 4) per assegnare un utente a uno dei 4 server.

Sebbene le funzioni hash aiutino a distribuire i dati in modo coerente, garantiscono una distribuzione uniforme solo se la chiave di shard ha una cardinalità elevata e una bassa asimmetria di frequenza. Se scegli una chiave di shard con un valore comune, ad esempio "Cognome" in cui "Rossi" compare 1000 volte più di "Bianchi", la funzione hash invierà ogni record "Rossi" allo stesso shard. In questo modo viene creato un "hot shard" nonostante l'uso di una formula matematica.

L'aggiunta di nuovi server è difficile con questo metodo perché la formula cambia, il che spesso richiede di "ricondividere" o spostare i dati nel nuovo cluster di server.

I dati vengono assegnati in base a intervalli di valori. Ad esempio, potresti inserire gli ID utente 1-1000 sul server A e 1001-2000 sul server B. È molto intuitivo e ottimo per le query che devono leggere una sequenza di dati (query di intervallo). Lo svantaggio è la creazione di "hotspot": se tutti i nuovi utenti vengono assegnati al server B, questo server svolgerà tutto il lavoro mentre il server A rimarrà inattivo.

Questa strategia utilizza una tabella di ricerca (una directory) che tiene traccia di quale shard contiene quali dati. Offre la massima flessibilità perché puoi spostare i dati tra gli shard senza modificare una formula. Tuttavia, questa tabella di ricerca diventa un collo di bottiglia: ogni query deve controllare prima la directory, aggiungendo latenza. Se la directory non funziona, l'intero database diventa inaccessibile.

Lo sharding geografico assegna i dati a server specifici in base alla posizione fisica di un utente. Ad esempio, i dati degli utenti in Francia vengono archiviati su server nell'UE, mentre gli utenti statunitensi si trovano su server in Nord America. Ciò riduce significativamente la latenza (velocità) per gli utenti e aiuta le aziende a rispettare le leggi sulla residenza dei dati come il GDPR.

A volte chiamata partizionamento funzionale, questa tecnica prevede la suddivisione dei dati per funzionalità anziché per riga. Ad esempio, potresti posizionare tutte le tabelle "Profilo utente" sul server A e tutte le tabelle "Caricamento foto" sul server B. Sebbene ciò organizzi i dati in modo logico, è funzionalmente simile a un'architettura di dati per microservizi e non risolve il problema se una funzionalità specifica (come Foto) diventa troppo grande per un singolo server.

Lo sharding è un tipo specifico di partizionamento orizzontale in cui le parti di dati vengono distribuite su server completamente diversi. In questo modo si risolvono sia i limiti di capacità hardware (archiviazione) sia i colli di bottiglia della velocità effettiva di scrittura, poiché server diversi possono elaborare le scritture contemporaneamente.

• Sharding manuale: in un ambiente di sharding manuale, lo sviluppatore o l'amministratore del database è responsabile della definizione delle chiavi di sharding, della creazione dell'infrastruttura per ogni shard e della scrittura della logica per il routing delle query. In questo modo, puoi controllare in modo granulare dove risiedono esattamente i dati. Tuttavia, richiede una manutenzione significativa. Se uno shard diventa troppo grande, devi eseguire manualmente il "resharding" dei dati, che comporta lo spostamento di milioni di righe su nuovi server cercando di ridurre al minimo i tempi di inattività dell'applicazione.
• Sharding automatico: lo sharding automatico, spesso presente nei database NoSQL come Bigtable o nei database SQL distribuiti come Spanner, gestisce la distribuzione di dati e traffico in modo automatico. Il sistema monitora le dimensioni dei dati e il carico su ciascun server. Se uno shard specifico diventa un "hot spot" o cresce troppo, il motore del database lo suddivide automaticamente e sposta i dati su un server meno congestionato. Ciò riduce il carico operativo sul tuo team e contribuisce a garantire prestazioni coerenti man mano che l'applicazione viene scalata.

Il partizionamento prevede la suddivisione di una tabella di grandi dimensioni in parti più piccole e gestibili (come la suddivisione di una tabella di log per mese), mantenendole però sulla stessa istanza del server. Questo risolve i problemi di archiviazione semplificando l'archiviazione o l'eliminazione di dati obsoleti senza influire sul resto della tabella. Tuttavia, non risolve i problemi del server. Poiché tutte le partizioni risiedono ancora su una singola macchina, continuano a condividere la stessa CPU e la stessa RAM, il che significa che il partizionamento non può essere d'aiuto se il server raggiunge i suoi limiti di prestazioni.

La replica è il processo di copia dell'intero database su più server. Può essere una buona scelta per la disponibilità di lettura: se un server non funziona, un altro può subentrare. Tuttavia, non aiuta con la scalabilità della scrittura perché ogni dato scritto deve essere copiato in ogni replica, limitando la velocità di scrittura alla capacità di una singola macchina.

Altrettanto importante è il fatto che la maggior parte dei modelli di replica consente un solo "writer" (scrittore, ovvero il nodo primario) alla volta. Se tenti di consentire a più server di accettare scritture contemporaneamente, rischi conflitti di scrittura, in cui due server tentano di aggiornare lo stesso record con informazioni diverse. La risoluzione di questi conflitti è tecnicamente difficile e può portare alla perdita o all'incoerenza dei dati se non viene gestita da un sistema distribuito sofisticato.

Un database distribuito, come Spanner, offre i vantaggi dello sharding senza il sovraccarico manuale. Questi sistemi sono progettati per essere distribuiti su un cluster di macchine fin dall'inizio. Gestiscono automaticamente la distribuzione, il ribilanciamento e la replica dei dati in modo trasparente. Alcuni di questi sistemi hanno più writer e gestiscono automaticamente i conflitti di scrittura. Ciò consente di scalare orizzontalmente mantenendo la coerenza di un database relazionale tradizionale.