PARTITIONING VS SHARDING

Думаю, что сегодня будет последняя история в затянувшейся серии постов про БД. Ставьте 🔥 если было полезно!

Разберём ещё одну загадку из серии «Арктика и Антарктика» — попробуем увидеть разницу между партиционированием и шардированием.

Как всегда, начнём с жизненной истории. Последнее время в канале часто поднимается тема еды, сегодня тоже не будем обходить её стороной. Представьте, что ваши данные — это продукты. Вы приехали из магазина, и теперь нужно разобрать пакеты.

Начнём с партиционирования. Из мест хранения еды у вас на кухне только холодильник. Чтобы проще было искать продукты, вы придерживаетесь некоторых правил при раскладке по полкам: сверху овощи, ниже мясо, в дверце соусы. Холодильник один, внутри есть структура, благодаря которой вы быстро находите нужное. Полка — это партиция.

Шардирование — история уже для людей побогаче, когда мест хранения несколько: скоропортящееся лежит в обычном холодильнике, крупы и печенье — в кладовке, а вино — в отдельном винном шкафу. Это уже не организация внутри одного устройства, а принципиально другая модель хранения. Вы точно никогда не будете искать макароны в морозильном шкафу. Для шардирования нужно больше мебели и техники на кухне, зато и вместить можно гораздо больше. Как понимаем, далеко не всем семьям всё это вообще понадобится.

В базе данных идея похожая. При партиционировании у вас одна логическая таблица, которая физически разбита по какому-то ключу, например по дате. Классический пример — таблица событий с 10+ миллиардами строк, где 95% запросов идут за последние 30 дней. Делаем партиции по месяцам, и планировщик читает только нужный фрагмент, не трогая остальные. Плюс старые данные можно удалять через DROP PARTITION за секунды вместо тяжёлого DELETE по всей таблице.

Шардирование требуется тогда, когда один инстанс становится физическим потолком и вертикально расти дальше уже невозможно или слишком дорого (вспоминаем историю про вертикальное и горизонтальное масштабирование). Представим платформу с сотнями миллионов пользователей и десятками тысяч запросов на запись в секунду. В какой-то момент возможностей одного primary-сервера перестаёт хватать.

Тогда данные начинают делить на шарды. Например, по user_id. Пользователи распределяются между независимыми инстансами, и запись каждого пользователя попадает только в свой шард. Да, архитектура усложняется: появляется роутинг запросов, новые сценарии отказов и дополнительные накладные расходы. Зато нагрузка распределяется между множеством серверов.

Очень важно правильно выбрать ключ шардирования. Если ошибиться, часть шардов будет перегружена, а остальные будут простаивать.

Ещё один хороший пример — геораспределённые системы с требованиями к data residency. Если данные пользователей из ЕС, США и APAC по регуляторным причинам должны храниться в разных регионах, то шарды по регионам становятся практически единственным разумным решением.

На практике зрелые платформы часто используют оба подхода одновременно. Например, шардирование по user_id или географии даёт горизонтальный масштаб, а партиционирование по времени внутри каждого шарда позволяет быстро работать с историческими данными.

Главное правило простое: начинайте с партиционирования. Оно решает большинство проблем роста с минимальными рисками. Шардирование стоит внедрять тогда, когда один инстанс действительно стал вашим потолком, а не просто потому, что таблица выглядит большой.

Вопрос дня: есть ли у вас винный шкаф?

#бабанюра_программирует