Πώς θα κάνατε shard μια βάση δεδομένων για 1 δισεκατομμύριο χρήστες;

Question

IT Interview Practice · Accepted Answer

Κάντε shard με ένα key που είναι **παρόν σε σχεδόν κάθε query και απλώνει το load ομοιόμορφα** — συνήθως ένα hashed `user_id` — και μετά σχεδιάστε για resharding και cross-shard queries από την πρώτη μέρα. 1 δισ. χρήστες δεν χωράνε ούτε αποδίδουν σε ένα node· σπάτε τα rows σε πολλές βάσεις και δρομολογείτε κάθε query στο shard που το κατέχει.

```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
```

## Επιλογή shard key — η απόφαση που είναι δύσκολο να αναιρεθεί

Επιλέξτε ένα key με **high cardinality, ομοιόμορφη κατανομή, και παρόν στα περισσότερα queries**. Το `user_id` συνήθως κερδίζει: user-scoped queries ("το προφίλ μου, τα orders μου") χτυπάνε ακριβώς ένα shard. Ένα κακό key (π.χ. `country`) δημιουργεί hotspots — ένα shard κρατά όλη την Ινδία ενώ ένα άλλο κάθεται αδρανές.

## Hash vs range

- **Hash sharding** (`shard = hash(user_id) % N`): κατανέμει ομοιόμορφα, σκοτώνει τα hotspots — αλλά τα range queries ("χρήστες που δημιουργήθηκαν την περασμένη εβδομάδα") πρέπει να κάνουν scatter-gather σε όλα τα shards.
- **Range sharding** (`user_id 0–1M → shard 0`): κρατά τα ranges τοπικά και κάνει το resharding ευκολότερο, αλλά ρισκάρει hotspots (οι νεότεροι χρήστες προσγειώνονται όλοι στο τελευταίο shard).
- Συνήθης απάντηση: **hash για ομοιόμορφο load**, με έναν **lookup/directory table** ώστε να μπορείτε να μετακινείτε ranges χωρίς να ξανα-hash-άρετε τα πάντα.

## Resharding — σχεδιάστε πριν το χρειαστείτε

Το `% N` είναι παγίδα: η προσθήκη ενός shard επαναχαρτογραφεί σχεδόν κάθε key. Χρησιμοποιήστε **consistent hashing** ή **virtual buckets** (map keys → 4096 logical buckets → physical shards). Το σπάσιμο ενός shard τότε μετακινεί buckets, όχι ολόκληρο το keyspace. Εργαλεία όπως το **Vitess** (χρησιμοποιείται από YouTube/Slack) αυτοματοποιούν live resharding με cutover.

## Cross-shard queries

Οτιδήποτε δεν έχει κλειδί το shard key είναι επώδυνο: ένα global "top posts" query κάνει fan out σε κάθε shard και τα ενώνει. Μετριάστε το με **denormalizing** ή κρατώντας ένα ξεχωριστό index/search store (Elasticsearch) για cross-cutting reads.

## Οπτική συνέντευξης

Οι συνεντευκτές διερευνούν αν καταλαβαίνετε ότι η επιλογή shard-key είναι **ημι-μόνιμη** και αν έχετε σκεφτεί το **resharding και τα cross-shard joins** — τα δύο πράγματα που δαγκώνουν στην παραγωγή. Καλό: "shard by user_id." Εξαιρετικό: αναφέρετε consistent hashing, μετριασμό hot-shard, και το γεγονός ότι τα distributed transactions πέρα από shards είναι καλύτερο να αποφεύγονται εντελώς.

**Συνηθισμένη παγίδα:** `hash % N` με σταθερό N — κάνει τη μελλοντική ανάπτυξη ένα πλήρες data migration.

## Trade-offs & τρόποι αποτυχίας

- **Χαμένο cross-shard ACID:** όχι φθηνά joins/transactions πέρα από shards· χρησιμοποιήστε sagas ή denormalize.
- **Hot shard:** ένας viral χρήστης· κάντε sub-shard ή cache αυτή την οντότητα.
- **Ρίσκο rebalancing:** το live migration πρέπει να κάνει double-write και verify πριν το cutover.
- **Λειτουργικό κόστος:** N shards × replicas = πολλές βάσεις για monitor, backup, και failover.

Επιλογή shard key — η απόφαση που είναι δύσκολο να αναιρεθεί

Hash vs range

Resharding — σχεδιάστε πριν το χρειαστείτε

Cross-shard queries

Οπτική συνέντευξης

Trade-offs & τρόποι αποτυχίας

Σχετικές ερωτήσεις