Quando NON usare lo sharding
Le read replica, il partizionamento e macchine più potenti risolvono la maggior parte dei problemi di scalabilità: sappia quando lo sharding è la risposta sbagliata.
Quando NON usare lo sharding è una lezione SQL Academy gratuita su CoddyKit. Questa è la lezione 4 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.
Lo sharding è l'ultima risorsa
Lo sharding moltiplica la complessità operativa. La maggior parte delle applicazioni non ne ha mai bisogno. Esaurisca prima le opzioni più semplici.
Passo 1: scalabilità verticale
Un server più grande. Le moderne istanze cloud gestiscono facilmente:
- 128 core
- 1 TB di RAM
- 50.000 IOPS NVMe
Si tratta di 100k-500k QPS su un singolo nodo Postgres. La maggior parte delle applicazioni rientra comodamente in questi limiti.
Passo 2: repliche di lettura
Se prevalgono le letture, aggiunga repliche. Un primary più 3 repliche può gestire 10× le letture.
Passo 3: caching
Redis o memcached davanti alle query più frequenti. Spesso è il miglior risultato ottenibile al costo più basso.
Passo 4: partizionamento
Il partizionamento dichiarativo nativo di PG risolve il problema delle «tabelle troppo grandi» all'interno di un singolo server. Spesso è 100 volte più semplice dello sharding.
Passo 5: suddivisione dei servizi
Sposti domini diversi in database diversi: database degli ordini, degli utenti e dell'analisi. Ognuno può scalare in modo indipendente.
Passo 6: spostare l'analisi
Query OLTP → Postgres. Query analitiche → ClickHouse / BigQuery / Snowflake. Molti casi in cui «dobbiamo usare lo sharding» sono in realtà casi in cui «l'analisi sta divorando il nostro OLTP».
Poi, forse, lo sharding
Se continua a esaurire le risorse con 50 TB di dati esclusivamente OLTP e il carico di lavoro richiede un volume di scritture che un singolo server non riesce a gestire, inizi a pianificare gli shard.
Costo operativo dello sharding
- Più server da monitorare e aggiornare
- Il coordinamento dei backup tra gli shard è necessario
- Le query tra shard ricadono sul codice dell'applicazione
- Il re-sharding è difficile
- Gli shard sovraccarichi richiedono un ribilanciamento attivo
La strategia «shard in ritardo»
Costruisca il sistema usando pattern compatibili con lo sharding (includa sempre tenant_id, non utilizzi mai contatori con incremento globale) così da poterlo suddividere in shard in seguito. Ma non ricorra allo sharding finché non è indispensabile.
Schema compatibile con lo sharding
Anche se rimane su un singolo nodo, progetti il sistema come se potesse essere suddiviso in shard:
- Tenant_id in ogni riga
- UUID o ID distribuiti (non autoincrementali)
- Nessuna sequenza globalmente univoca
- Chiavi esterne all'interno dell'ambito di un tenant
Riconoscere il compromesso
Lo sharding aumenta la capacità al costo di una riduzione delle funzionalità. JOIN, transazioni e query diventano più difficili. Si assicuri che il vantaggio valga il costo.
Riepilogo
Lo sharding risolve un problema reale, ma è una soluzione complessa.
- Inizi dalla scalabilità verticale
- Repliche di lettura e caching
- Partizionamento prima dello sharding
- Sposti l'analisi fuori dall'OLTP
- Progetti per supportare lo sharding, rimandandone l'adozione effettiva
Verifica rapida
Sta valutando lo sharding perché le query OLTP sono lente. Prima dello sharding, quale passaggio è più probabile che sia utile?
Domande Frequenti
La lezione «Quando NON usare lo sharding» è gratuita?
Sì — il testo completo di «Quando NON usare lo sharding» è 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 «Quando NON usare lo sharding»?
Le read replica, il partizionamento e macchine più potenti risolvono la maggior parte dei problemi di scalabilità: sappia quando lo sharding è la risposta sbagliata. 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 4 di 4.
Quanto tempo richiede la lezione «Quando NON usare lo sharding»?
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
- Strategie di sharding: intervallo, hash, directory
- Query tra shard: il problema più complesso
- Citus e Postgres distribuito
- Quando NON usare lo sharding