🟢 Junior Level

Шардування — це розподіл великої бази даних на кілька менших частин (шардів), кожна на своєму сервері.

На відміну від read replicas (копія даних для читання), шарди містять РІЗНІ дані. Кожен шард — незалежна частина dataset.

Велика БД (100 млн записів) → повільно

Шардування:
Шард 1: users A-F (сервер 1)
Шард 2: users G-M (сервер 2)
Шард 3: users N-Z (сервер 3)

Навіщо:

• Масштабування — кожен шард на своєму сервері
• Продуктивність — індекси стають меншими, повністю вміщуються в RAM, глибина B-tree зменшується. Запит сканує менше сторінок — швидше.
• Надійність — один шард впав, інші працюють

---

🟡 Middle Level

Коли НЕ шардувати

Не шардуйте, поки не впретеся в storage або write limits одного сервера. Для dataset до ~100GB шардування зазвичай надмірне — його операційна складність переважує вигоду.

Стратегії шардування

1. Range-based:

Шард 1: ID 1-1000
Шард 2: ID 1001-2000
Шард 3: ID 2001-3000

2. Hash-based:

shard = hash(key) % num_shards
user_123 → hash("user_123") % 3 = шард 2

3. Directory-based:

Lookup table: key → shard
user_123 → шард 2
user_456 → шард 1

Типові помилки

1. Hot shard:

   Усі нові користувачі йдуть в один шард
   → нерівномірне навантаження
   Рішення: hash-based замість range-based
   

   (Hot spot — один шард отримує непропорційно більше трафіку. Cross-shard joins — запити, що об’єднують дані з різних шардів (дорогі).)

---

🔴 Senior Level

Архітектурні Trade-offs

Range	Hash	Directory
Проще	Рівномірніше	Гнучкіше
Hot spots	Складно rebalance	Single point of failure

Production Experience

Resharding:

При додаванні нового шарда:
1. Перерахувати hash distribution
2. Перемістити дані
3. Оновити routing

MongoDB, Cassandra підтримують auto-resharding

Best Practices

✅ Hash-based для рівномірного розподілу
✅ Моніторьте розмір кожного шарда
✅ Плануйте resharding заздалегідь
✅ Cross-shard joins — уникайте

❌ Без моніторингу hot spots
❌ Занадто багато cross-shard запитів

---

🎯 Шпаргалка для співбесіди

Обов’язково знати:

• Шардування — розподіл БД на частини (шарди), кожна на своєму сервері
• Кожен шард містить РІЗНІ дані (на відміну від read replicas)
• Стратегії: range-based, hash-based, directory-based
• Hash-based рівномірніше розподіляє, range-based простіший але має hot spots
• Resharding — переміщення даних при додаванні шардів
• Cross-shard JOINs дорогі — уникайте їх
• НЕ шардуйте поки не впретеся в storage/write limits (~100GB+)

Часті уточнюючі питання:

• Що таке hot shard? Один шард отримує непропорційно більше трафіку — рішення: hash-based замість range-based.
• Як робити resharding? Перерахувати distribution → перемістити дані → оновити routing. MongoDB/Cassandra підтримують auto-resharding.
• Range vs hash vs directory? Range простіший, hash рівномірніший, directory гнучкіший (але SPOF).
• Коли шардування надмірне? Dataset до ~100GB — операційна складність переважує.

Червоні прапорці (НЕ говорити):

• “Шардування = read replicas” — ні, replicas = копії, шарди = різні дані
• “Range-based завжди кращий” — ні, hot spots при нерівномірному розподілі
• “Cross-shard JOINs нормальна практика” — ні, це дорого, уникайте
• “Шардування потрібне одразу” — ні, починайте коли впретеся в ліміти

Пов’язані теми:

• [[11. У чому різниця між шардуванням та партиціонуванням]]
• [[12. Як реалізувати горизонтальне масштабування мікросервісів]]
• [[13. Що таке патерн Database per Service]]
• [[14. Які проблеми виникають при використанні спільної бази даних]]
• [[10. Що таке шардування sharding]]