Concetti dello sharding: chunk, bilanciatore e shard key
I partecipanti definiranno i chunk e spiegheranno come il bilanciatore li sposta tra gli shard per mantenere una distribuzione uniforme dei dati.
Concetti dello sharding: chunk, bilanciatore e shard key è una lezione MongoDB 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 MongoDB Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso MongoDB Academy include 4 lezioni in totale.
Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.
What Is Sharding?
Sharding is MongoDB's horizontal scaling strategy. Instead of storing all data on a single replica set, a sharded cluster divides the data across multiple shards, each of which is itself a replica set. This lets you scale storage, throughput, and memory horizontally by adding more shards as your data grows.
Sharded Cluster Components
A sharded cluster has three roles: Shards — replica sets that store the actual data. mongos — a query router that receives client connections and routes operations to the correct shard(s). Config servers — a replica set that stores cluster metadata, including the shard key ranges and chunk locations. Clients always connect to mongos, never directly to shards.
// Connect to the cluster via mongos (same URI format as a standalone)
const client = new MongoClient('mongodb://mongos-host:27017/mydb')The Shard Key: Data Distribution Axis
The shard key is a field (or compound of fields) you choose when sharding a collection. MongoDB uses the shard key value to determine which shard a document belongs to. Every document in a sharded collection must contain the shard key, and the key is immutable — you cannot change it after sharding. Choosing the wrong shard key is the most common MongoDB scaling mistake.
// Enable sharding on a database
sh.enableSharding('mydb')
// Shard a collection by userId
sh.shardCollection('mydb.events', { userId: 1 })What Is a Chunk?
MongoDB divides the shard key range into chunks — contiguous ranges of shard key values. Each chunk lives on exactly one shard. By default, a chunk grows up to 128 MB before MongoDB splits it into two smaller chunks. The shard each chunk lives on is tracked in the config server metadata.
// View the chunks for a collection
use config
db.chunks.find(
{ ns: 'mydb.events' },
{ shard: 1, min: 1, max: 1 }
).limit(10)The Balancer: Evening Out Data
The balancer is a background process that monitors chunk distribution across shards. If one shard has significantly more chunks than others (by default, a difference of 8 or more), the balancer migrates chunks from the busiest shard to less-loaded shards. Migrations happen automatically and try to avoid peak traffic windows.
// Check if the balancer is running
sh.getBalancerState()
// Check balancer status
sh.status()
// Pause the balancer during a maintenance window
sh.stopBalancer()Targeted vs Scatter-Gather Queries
When a query includes the shard key, mongos routes it directly to the one (or few) shards that hold matching documents — a targeted query. When the query does not include the shard key, mongos must send it to all shards and merge results — a scatter-gather query. Targeted queries are dramatically faster. Design your queries around the shard key for best performance.
// Targeted: mongos routes to one shard
db.events.find({ userId: 'u123', date: { $gt: ISODate('2025-01-01') } })
// Scatter-gather: mongos fans out to all shards
db.events.find({ eventType: 'click' })Hot Shards: The Anti-Pattern
A hot shard (or hot spot) occurs when a disproportionate share of reads or writes land on a single shard. Common causes: using a monotonically increasing shard key (like createdAt or ObjectId) so all new inserts always go to the highest chunk, or using a low-cardinality key (like a boolean) that limits parallelism. Hot shards negate the benefits of sharding.
// BAD: ObjectId is monotonically increasing
// All new inserts go to the 'max' chunk on one shard
sh.shardCollection('mydb.events', { _id: 1 }) // AVOID
// BETTER: Use hashed sharding to distribute new inserts
sh.shardCollection('mydb.events', { _id: 'hashed' })Jump Consistent and Jumbo Chunks
A jumbo chunk is a chunk that has grown beyond the maximum size but cannot be split because all of its documents share the same shard key value. Jumbo chunks cannot be migrated by the balancer and create a persistent imbalance. The fix is to choose a shard key with sufficient cardinality so that no single key value maps to more documents than fit in one chunk.
// Identify jumbo chunks (jumbo: true in chunk metadata)
use config
db.chunks.find({ ns: 'mydb.events', jumbo: true }).count()Viewing Shard Distribution With sh.status()
sh.status() gives a complete picture of your sharded cluster: which collections are sharded, how many chunks exist per shard, and the key ranges each shard owns. Use it to quickly spot imbalanced chunk distribution and confirm that the balancer has completed migrations after adding a new shard.
// Full cluster status
sh.status()
// Targeted collection info
db.runCommand({ collStats: 'events' })
// Look at 'sharded', 'count', 'nchunks', 'shards' fieldsAdding a New Shard
Adding a shard to a running cluster is an online operation. The balancer automatically migrates chunks from existing shards to the new one over time. You can pre-split chunks before adding a shard to speed up initial distribution, especially when bulk-loading data. No downtime is required when adding shards.
// Add a new shard (replica set format)
sh.addShard('rs1/new-shard-host:27017')
// Monitor migration progress
sh.status()
db.adminCommand({ balancerCollectionStatus: 'mydb.events' })When to Shard: The Decision Threshold
Sharding adds operational complexity. Before sharding, exhaust vertical scaling and indexing options. Common triggers to shard: data volume > 1–2 TB on a single replica set, write throughput that saturates a single primary, or working set that no longer fits in RAM. Always benchmark with explain() and profiling before deciding to shard.
Quick Check
Test your understanding of MongoDB & NoSQL Databases concepts from this lesson.
Lesson Recap
In this lesson you learned: sharding distributes data across multiple shards (replica sets) using a shard key, chunks are contiguous shard key ranges the balancer migrates to maintain even distribution, and targeted queries (including the shard key) are far more efficient than scatter-gather queries. Next up we explore how to choose the right shard key.
Impara JavaScript con un tutor IA — gratis
Scrivi ed esegui vero codice nel tuo browser, ricevi aiuto istantaneo da un tutor IA disponibile 24/7, e riprendi da dove hai lasciato sul web o nell'app.
- Corsi
- 30
- Lezioni
- 120
Domande Frequenti
La lezione «Concetti dello sharding: chunk, bilanciatore e shard key» è gratuita?
Sì — il testo completo di «Concetti dello sharding: chunk, bilanciatore e shard key» è 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 MongoDB Academy, passa a CoddyKit PRO. Il corso MongoDB Academy include 4 lezioni in totale.
Cosa imparerò in «Concetti dello sharding: chunk, bilanciatore e shard key»?
I partecipanti definiranno i chunk e spiegheranno come il bilanciatore li sposta tra gli shard per mantenere una distribuzione uniforme dei dati. Eserciti MongoDB 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 MongoDB Academy?
Non è richiesta alcuna esperienza precedente. MongoDB 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 «Concetti dello sharding: chunk, bilanciatore e shard key»?
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 MongoDB Academy?
Sì. Ogni lezione MongoDB 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
- Concetti dello sharding: chunk, bilanciatore e shard key
- Scegliere una shard key: cardinalità, frequenza, monotonicità
- Strategie di sharding ranged e hashed
- Sharding per zone: assegnare i dati alle regioni