Ta yaya za ka yi shard na database ga masu amfani biliyan 1?

Question

IT Interview Practice · Accepted Answer

Yi shard da key da ke **kusan a kowace query kuma yana baza load daidai** — yawanci hashed `user_id` — sannan ka shirya don resharding da cross-shard queries tun rana ta farko. Masu amfani biliyan 1 ba za su daidaita ko su yi aiki a node ɗaya ba; kana raba rows a kan databases da yawa kuma ka tura kowace query zuwa shard da ke da ita.

```text
                 ┌──────────────┐
Request ─▶ Router/│ shard_of(key)│─▶ Shard 0  (users 0–…)
           Proxy  └──────────────┘   Shard 1
           (Vitess)      │           Shard 2
                         └─────────▶  Shard N   ← each = its own primary+replicas
Directory/lookup table (which key → which shard) ── for range or resharding
```

## Zaɓin shard key — shawarar da ke da wuya a soke

Zaɓi key da **high cardinality, rarraba daidai, kuma yana cikin yawancin queries**. `user_id` yawanci yana nasara: user-scoped queries ("profile ɗina, orders ɗina") suna bugun shard ɗaya daidai. Key mara kyau (misali `country`) yana ƙirƙirar hotspots — shard ɗaya yana riƙe duk Indiya yayin da wani ke zaune babu aiki.

## Hash vs range

- **Hash sharding** (`shard = hash(user_id) % N`): yana rarraba daidai, yana kashe hotspots — amma range queries ("masu amfani da aka ƙirƙira makon da ya gabata") dole su scatter-gather a kan dukan shards.
- **Range sharding** (`user_id 0–1M → shard 0`): yana ajiye ranges local kuma yana sauƙaƙe resharding, amma yana haɗarin hotspots (sabbin masu amfani duk suna sauka a shard na ƙarshe).
- Amsa gama gari: **hash don load daidai**, tare da **lookup/directory table** domin ka iya matsar da ranges ba tare da rehashing komai ba.

## Resharding — shirya kafin ka buƙata

`% N` tarko ne: ƙara shard ɗaya yana sake taswira kusan kowane key. Yi amfani da **consistent hashing** ko **virtual buckets** (map keys → 4096 logical buckets → physical shards). Raba shard sannan yana matsar da buckets, ba dukan keyspace ba. Kayan aiki kamar **Vitess** (YouTube/Slack ke amfani da su) suna sarrafa live resharding da cutover.

## Cross-shard queries

Duk abin da ba a key da shard key ba yana da wahala: global "top posts" query yana fan out zuwa kowane shard kuma yana merge. Rage shi ta hanyar **denormalizing** ko ajiye index/search store daban (Elasticsearch) ga cross-cutting reads.

## Ra'ayin hira

Masu yin hira suna bincike ko ka fahimci zaɓin shard-key **semi-permanent** ne kuma ko ka yi tunanin **resharding da cross-shard joins** — abubuwa biyu da ke ciza a production. Mai kyau: "shard da user_id." Mai kyau sosai: ka ɗaga consistent hashing, hot-shard mitigation, da gaskiyar cewa distributed transactions a kan shards mafi kyau a guje su gaba ɗaya.

**Tarkon gama gari:** `hash % N` da N mai gyara — yana mai da girma na gaba full data migration.

## Sulhu & hanyoyin gazawa

- **Rasasshen cross-shard ACID:** babu joins/transactions masu arha a kan shards; yi amfani da sagas ko denormalize.
- **Hot shard:** viral user; yi sub-shard ko cache wannan entity.
- **Haɗarin rebalancing:** live migration dole ya double-write kuma ya verify kafin cutover.
- **Operational cost:** N shards × replicas = databases da yawa da za a kula, back up, da fail over.

Zaɓin shard key — shawarar da ke da wuya a soke

Hash vs range

Resharding — shirya kafin ka buƙata

Cross-shard queries

Ra'ayin hira

Sulhu & hanyoyin gazawa

Tambayoyi masu alaƙa