Wybór klucza shardingu: kardynalność, częstotliwość, monotoniczność

The shard key is immutable once set and cannot be changed without unsharding and re-sharding the entire collection — an expensive, disruptive operation. Choosing the wrong shard key leads to hot shards, poor query routing, and wasted hardware. You must evaluate candidates against three dimensions: cardinality, frequency, and monotonicity.

Cardinality is the number of distinct values the shard key can take. High cardinality (e.g., userId, email, orderId) is good — it gives MongoDB many possible chunk boundaries and lets the balancer distribute data finely. Low cardinality (e.g., status: 'active' | 'inactive', country with 50 values) creates jumbo chunks that cannot be split or migrated.

Frequency measures how many documents share each shard key value. Even high-cardinality keys can be problematic if a small number of values appear in the vast majority of documents. For example, a countryCode field might have 200 distinct values, but 90% of users are from a single country — creating a massive hot chunk that cannot be split.

Monotonicity refers to whether shard key values always increase (or decrease) over time. Fields like createdAt timestamps and ObjectId (_id) are monotonically increasing. This is problematic because all new inserts land on the same 'max' chunk on one shard, creating a write hot spot even when data is evenly distributed historically.

The ideal shard key has: High cardinality — thousands or millions of distinct values. Low frequency skew — no single value dominates. Non-monotonic distribution — values do not always increase, or you use hashed sharding. Query alignment — matches the filters in your most frequent, latency-sensitive queries for targeted routing.

A compound shard key combines two fields for better distribution. For example, { tenantId: 1, createdAt: 1 } distributes across tenants (high cardinality) and allows ranged queries within each tenant. The first field determines coarse distribution; the second provides fine-grained splitting. Compound keys can satisfy multi-field query predicates as targeted queries.

A hashed shard key applies a hash function to the field value before mapping it to a chunk. This converts monotonic keys (like ObjectId) into randomly distributed hash values, eliminating write hot spots. The trade-off is that range queries on the field become scatter-gather, since hash values are not stored in original order.

MongoDB allows zone sharding where you assign shard key ranges to specific shards using tags (zones). This is useful for data residency requirements: European user data can be pinned to EU-region shards, US data to US shards. Zone sharding requires a compound shard key with a region prefix as the first component.

When evaluating shard key candidates: 1) Run a cardinality check — db.col.distinct('field').length should be in the thousands or more. 2) Check frequency distribution with an aggregation. 3) Determine if the field is monotonic (timestamps, auto-increment). 4) Review your top 5 most frequent queries — does the candidate field appear in their filter?

A common and safe default for many workloads is to use { _id: 'hashed' }. MongoDB ObjectId values, while monotonic, become evenly distributed after hashing. This gives uniform write distribution out of the box. The main limitation is that any range query on _id becomes scatter-gather — but for most document-level lookup workloads this is acceptable.

MongoDB Atlas provides a Shard Key Advisor in the Performance Advisor that analyzes your query patterns and recommends shard keys based on actual usage. It can detect monotonic keys, frequency skew, and missing indexes. Using the advisor before sharding is especially helpful for production workloads where query patterns are already established.

In this lesson you learned: a good shard key has high cardinality, low frequency skew, and avoids monotonic values, compound shard keys combine coverage for distribution and query targeting, and hashed sharding neutralizes monotonic key hot spots at the cost of range query efficiency. Next up we compare ranged vs hashed sharding strategies in detail.