🟢 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]]