0Pricing
SQL Academy · Lezione

Strategie di sharding: intervallo, hash, directory

Confronti lo sharding basato su intervalli, hash e directory e scelga una shard key che bilanci il carico e rimanga stabile.

Strategie di sharding: intervallo, hash, directory è una lezione SQL Academy gratuita su CoddyKit. Questa è la lezione 1 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento SQL Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso SQL Academy include 4 lezioni in totale.

Che cos'è lo sharding?

Lo sharding suddivide un database logico tra più server fisici («shard»), ciascuno dei quali contiene un sottoinsieme dei dati. Lo si fa quando un singolo server non riesce più a gestire il carico di lavoro.

Sharding ≠ replicazione

  • Replicazione — stessi dati su molti server (per alta disponibilità e scalabilità delle letture)
  • Sharding — dati diversi su server diversi (per scalare le scritture e la capacità)

Spesso si combinano entrambi: ogni shard viene replicato per garantire l'alta disponibilità.

Tre strategie di sharding

  • Intervallo — suddivisione in base a un intervallo di valori (ID da 1 a 1M sullo shard A, da 1M a 2M sullo shard B)
  • Hash — si calcola l'hash della chiave dello shard, modulo N
  • Directory — una tabella separata associa la chiave allo shard

Sharding per intervallo

Semplice e adatto ai dati di serie temporali e agli ID ordinati. Rischio: shard sovraccarichi se tutto il traffico riguarda i dati più recenti.

-- Conceptually:
-- Shard A: user_id 1 - 1,000,000
-- Shard B: user_id 1,000,001 - 2,000,000
-- Shard C: user_id 2,000,001 - 3,000,000

Sharding tramite hash

Distribuzione uniforme per impostazione predefinita. Aggiungere shard è difficile, perché il re-sharding sposta tutte le chiavi:

-- shard_id = hash(user_id) % N
-- N=4: any user_id evenly distributed across 4 shards

Sharding tramite directory

Una tabella di ricerca associa ogni chiave al relativo shard:

CREATE TABLE shard_routing (
  user_id BIGINT PRIMARY KEY,
  shard_id INT NOT NULL
);

-- Looking up a user costs a directory query first; cache it.

Consistent hashing

L'hashing tramite modulo è fragile quando si aggiungono shard. Il consistent hashing riduce al minimo le chiavi che devono essere spostate:

-- Each shard owns a ring segment.
-- Adding a new shard moves only ~1/N of the keys.

Scegliere la chiave dello shard

La chiave dello shard determina tutto. Le buone chiavi dello shard:

  • Distribuiscono i dati in modo uniforme
  • Compaiono nella maggior parte delle query (evitando il fan-out tra shard)
  • Sono immutabili o cambiano raramente
<p>Common picks: user_id, tenant_id, customer_id. Avoid: timestamps for write-heavy workloads (creates hot shards).</p>

Un tenant per shard

In un SaaS multi-tenant, ogni tenant risiede su uno shard dedicato. È semplice da gestire concettualmente e facilita l'isolamento dei tenant rumorosi.

Progettazione per il re-sharding

Progetti tenendo conto del futuro re-sharding:

  • Utilizzi shard virtuali (ad esempio, 1024 logici mappati su shard fisici)
  • Renda semplice migrare uno shard logico su un server fisico diverso
  • Eviti codice dell'applicazione che codifica direttamente il numero di shard

Query tra shard

È il problema più difficile. JOIN e report tra shard richiedono logica di fan-out e aggregazione nell'applicazione. Ne parleremo nella prossima lezione.

Transazioni tra shard

Le transazioni atomiche tra shard richiedono il two-phase commit (2PC) oppure le saga. Il consiglio tipico è progettare il sistema in modo che le transazioni rimangano all'interno di un singolo shard.

Riepilogo

Esistono tre strategie: scelga in base alla forma del traffico.

  • Intervallo — semplice, ma con rischio di shard sovraccarichi
  • Hash — uniforme, ma rigido
  • Directory — flessibile, ma aggiunge latenza
  • Consistent hashing per un re-sharding graduale

Verifica rapida

Partiziona la tabella degli utenti tramite hash(user_id). Passa da 4 shard a 5. Quante chiavi devono essere spostate?

Domande Frequenti

La lezione «Strategie di sharding: intervallo, hash, directory» è gratuita?

Sì — il testo completo di «Strategie di sharding: intervallo, hash, directory» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso SQL Academy, passa a CoddyKit PRO. Il corso SQL Academy include 4 lezioni in totale.

Cosa imparerò in «Strategie di sharding: intervallo, hash, directory»?

Confronti lo sharding basato su intervalli, hash e directory e scelga una shard key che bilanci il carico e rimanga stabile. Eserciti SQL Academy con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare SQL Academy?

Non è richiesta alcuna esperienza precedente. SQL Academy su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 1 di 4.

Quanto tempo richiede la lezione «Strategie di sharding: intervallo, hash, directory»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione SQL Academy?

Sì. Ogni lezione SQL Academy include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Strategie di sharding: intervallo, hash, directory
  2. Query tra shard: il problema più complesso
  3. Citus e Postgres distribuito
  4. Quando NON usare lo sharding
← Torna a SQL Academy