🟢 Junior Level

Обидва розділяють дані, але на різних рівнях:

• Партиціонування — розподіл всередині однієї БД на одному сервері
• Шардування — розподіл між різними серверами

Партиціонування (одна БД):
Table → Partition 1 (2023)
      → Partition 2 (2024)
      → Partition 3 (2025)

Шардування (багато серверів):
DB → Shard 1 (Server 1)
   → Shard 2 (Server 2)
   → Shard 3 (Server 3)

---

🟡 Middle Level

Партиціонування

-- PostgreSQL range partitioning
-- PARTITION BY RANGE — PostgreSQL фізично розділяє таблицю на частини.
-- Кожна партиція зберігає свої дані, але логічно це одна таблиця.
CREATE TABLE orders (
    id BIGINT,
    created_at DATE
) PARTITION BY RANGE (created_at);

CREATE TABLE orders_2024 PARTITION OF orders
    FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');

CREATE TABLE orders_2025 PARTITION OF orders
    FOR VALUES FROM ('2025-01-01') TO ('2026-01-01');

// Запит WHERE created_at = ‘2023-06-15’ не потрапляє жодної партиції! // Потрібна default partition або обробка помилки.

Шардування

MongoDB:
sh.shardCollection("db.orders", { user_id: "hashed" })

Cassandra:
Automatic sharding by partition key

Порівняння

Партиціонування	Шардування
Один сервер	Багато серверів
Одна БД	Багато БД
Простіше	Складніше
Для оптимізації запитів	Для масштабування

---

🔴 Senior Level

Коли що використовувати

Якщо таблиця вміщується в пам’ять і запити швидкі — ні партиціонування, ні шардування не потрібні.

Партиціонування:

✅ Велика таблиця, один сервер
✅ Оптимізація запитів за датою
✅ Архівування старих даних

Шардування:

✅ Один сервер не справляється
✅ Потрібне горизонтальне масштабування
✅ Дані не вміщуються на один сервер

Best Practices

✅ Партиціонування для оптимізації
✅ Шардування для масштабування
✅ Починайте з партиціонування
✅ Шардуйте коли впретеся в ліміти

❌ Шардування без необхідності
❌ Складні cross-shard запити

---

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

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

• Партиціонування — розподіл всередині ОДНІЄЇ БД на одному сервері
• Шардування — розподіл між РІЗНИМИ серверами
• Партиціонування для оптимізації запитів, шардування для масштабування
• Починайте з партиціонування — простіше, менше overhead
• PostgreSQL підтримує PARTITION BY RANGE/LIST/HASH
• MongoDB/Cassandra підтримують автоматичне шардування
• Якщо таблиця вміщується в RAM і запити швидкі — ні те ні інше не потрібне

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

• Коли партиціонування? Велика таблиця, один сервер, оптимізація за датою, архівування.
• Коли шардування? Один сервер не справляється, дані не вміщуються, потрібне горизонтальне масштабування.
• Чи можна комбінувати? Так — партиціонування всередині шарда.
• PostgreSQL партиціонування як працює? PARTITION BY RANGE/LIST — фізичний розподіл, логічно одна таблиця.

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

• “Партиціонування і шардування — одне й те саме” — ні, різні рівні
• “Шардування завжди краще” — ні, складніше і дорожче
• “Партиціонування вирішує проблему масштабування” — ні, тільки одного сервера
• “Потрібно шардувати одразу” — ні, починайте коли впретеся в ліміти

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

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