Шардування бази даних: підходи та підводні камені

Коли вертикального масштабування недостатньо

Поки дані вміщуються на один сервер, збільшення його потужності — найпростіший шлях. Шардування стає потрібним, коли обсяг даних чи навантаження перевищують можливості однієї машини, і дані доводиться фізично розподіляти між кількома незалежними базами. Детальніше про суміжний підхід можна прочитати в матеріалі «NoSQL vs SQL: як обрати правильно».

Вибір ключа шардування

Найважливіше і найважче оборотне рішення — вибір ключа шардування. Він повинен рівномірно розподіляти навантаження і, що критичніше, покривати більшість запитів, щоб уникнути звернення до всіх шардів одразу (scatter-gather запитів), які зводять нанівець користь від шардування.

Типова помилка — шардувати за автоінкрементним ID, що створює «гарячий» останній шард, куди летять усі нові записи. Краще обирати бізнес-ключ, наприклад customer_id чи tenant_id, якщо основна маса запитів і так фільтрується за цим полем. Окрема складність — операції, які потребують даних одразу з кількох шардів, такі як JOIN між сутностями різних клієнтів або глобальна агрегація: їх доводиться або уникати на рівні моделі даних, або вирішувати на рівні окремого шару аналітики. Ці ідеї перегукуються з темами «Реплікація і відмовостійкість у PostgreSQL» та «Мокування зовнішніх залежностей: підходи та антипатерни».