0Pricing
SQL Academy · Lezione

Query tra shard: il problema più complesso

Comprenda perché join e transazioni tra shard sono il problema più difficile nei database distribuiti e quali schemi ne riducono al minimo l’uso.

Query tra shard: il problema più complesso è una lezione SQL Academy gratuita su CoddyKit. Questa è la lezione 2 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.

Il costo dello sharding

Lo sharding scala le scritture e la capacità, ma rende difficili le query che coinvolgono più shard: ogni query tra shard è un fan-out.

Le query su un singolo shard sono semplici

Se la chiave dello shard compare nella clausola WHERE, il router invia una sola query a un solo shard:

-- shard_id = hash(user_id) % N
SELECT * FROM orders WHERE user_id = 42;
-- Router computes shard, sends one query, gets one result.

Query con fan-out

In assenza della chiave dello shard, il router interroga ogni shard e unisce i risultati:

-- WHERE status = 'paid' — no user_id
SELECT * FROM orders WHERE status = 'paid' ORDER BY created_at DESC LIMIT 100;
-- Must query all N shards, merge results, sort, take top 100.

Aggregazioni con fan-out

Per COUNT/SUM/AVG, ottenga i risultati parziali da ogni shard e li combini nel router o nell'applicazione:

-- On each shard:
SELECT COUNT(*), SUM(total) FROM orders;

-- Aggregator:
final_count = SUM(counts), final_sum = SUM(sums)

-- AVG is trickier — need SUM and COUNT, can't average averages.

JOIN tra shard

Se entrambi i lati sono suddivisi usando la stessa chiave (co-localizzati), la JOIN è locale allo shard. Altrimenti è praticamente impossibile su larga scala.

Tabelle di riferimento (replicate ovunque)

Le piccole tabelle di «lookup» vengono replicate su ogni shard, così le JOIN che le coinvolgono rimangono locali. Citus le chiama «reference tables».

Evitare i pattern tra shard

Strategie di progettazione dello schema:

  • Denormalizzi — duplichi i dati del genitore nello shard che contiene il figlio
  • Utilizzi la chiave dello shard ovunque, anche quando sembra «non necessaria»
  • Precalcoli i report in un database analitico separato

Paginazione tra shard

OFFSET 1000 LIMIT 10 su molti shard è pessimo: ogni shard deve produrre 1010 righe. Utilizzi invece la paginazione keyset.

Transazioni distribuite

Il two-phase commit (2PC) coordina i commit atomici tra gli shard. È lento e fragile in caso di partizionamento della rete. In pratica, conviene progettare il sistema usando pattern «saga»:

// Saga pattern (conceptual):
//   1. Local TX on shard A: mark as pending, log
//   2. RPC to shard B: do its part
//   3. Local TX on shard A: mark as committed
//   4. On failure: compensating transactions

Shard sovraccarichi

Un utente famoso o un prodotto virale possono concentrare il traffico su un singolo shard, compromettendo la scalabilità. Rilevi il problema e suddivida ulteriormente lo shard oppure lo sposti.

Chiavi esterne tra shard

Le FK degli RDBMS non si estendono tra gli shard. Può imporre l'integrità referenziale nell'applicazione oppure accettare la consistenza eventuale per le relazioni tra shard.

Riepilogo

Lo sharding sposta la difficoltà dallo «scalare le scritture» al «progettare query che rimangano locali allo shard».

  • Le query su un singolo shard sono veloci
  • Il fan-out è lento
  • Denormalizzi per mantenere l'elaborazione locale
  • Tabelle di riferimento per le dimensioni condivise
  • Saga al posto di 2PC

Verifica rapida

Perché una SELECT senza la chiave dello shard nella clausola WHERE è costosa in un database partizionato?

Domande Frequenti

La lezione «Query tra shard: il problema più complesso» è gratuita?

Sì — il testo completo di «Query tra shard: il problema più complesso» è 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 «Query tra shard: il problema più complesso»?

Comprenda perché join e transazioni tra shard sono il problema più difficile nei database distribuiti e quali schemi ne riducono al minimo l’uso. 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 2 di 4.

Quanto tempo richiede la lezione «Query tra shard: il problema più complesso»?

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