Шардинг - розподіл даних однієї логічної бази між кількома фізичними серверами за ключем шардингу. Кожен сервер (шард) зберігає частину рядків і обслуговує частину навантаження - зокрема записів, які реплікація не масштабує.
Стратегії вибору шарду:
- за діапазоном (користувачі 1-1 млн на шарді A) - просто, але нерівномірно: нові активні користувачі всі на останньому шарді;
- за хешем ключа - рівномірно, але діапазонні запити йдуть на всі шарди; додавання шарду переміщує багато даних (зменшує це консистентне хешування);
- за довідником - таблиця відповідності «ключ → шард»: гнучко, але довідник стає ще одним критичним компонентом;
- за орендарем (tenant) - кожен клієнт SaaS на своєму шарді: природна межа, дані клієнта разом.
Чому шардинг - останній засіб:
- запити між шардами:
JOIN, агрегати, сортування по всіх даних стають розподіленими - їх збирає застосунок; - транзакції між шардами - без звичних гарантій ACID; потрібні саги чи двофазний коміт;
- унікальність і ідентифікатори - автоінкремент на кожному шарді дасть дублікати; потрібні UUID/Snowflake;
- перебалансування - додати шард означає перенести частину даних під навантаженням;
- гарячі шарди - великий клієнт чи популярний ключ перевантажує один сервер;
- операційна складність - бекапи, міграції схеми, моніторинг на N серверах;
- вибір ключа майже незворотний - помилка дорого коштує через роки.
Що спробувати раніше:
- індекси, оптимізація запитів, усунення N+1;
- вертикальне масштабування бази (сучасні сервери - сотні ядер і терабайти пам'яті);
- кеш і репліки для читання;
- секціонування (partitioning) великих таблиць усередині однієї бази;
- винесення окремих доменів у власні бази (функціональне розділення) - лог подій, аналітика, пошук;
- архівація старих даних.
Коли шардинг виправданий: записи чи обсяг даних справді перевищують можливості найпотужнішого сервера, або вимоги до ізоляції клієнтів (SaaS з великими орендарями). Альтернатива - розподілені бази з вбудованим шардингом (Vitess, Citus, CockroachDB), що беруть частину складності на себе.