Шардирование БД
Тема дорожной карты · Backend разработчик
Шардинг баз данных — техника горизонтального партиционирования, разделяющая большой набор данных на несколько независимых узлов баз данных (шардов), каждый из которых владеет отдельным подмножеством данных, позволяя бэкенд-системам масштабировать записи и хранилище за пределы возможностей единственного сервера. Каждый шард обрабатывает часть общей нагрузки запросов, а ключ шарда — обычно ID пользователя, ID тенанта или географический регион — определяет, какой шард хранит данную запись, что делает выбор ключа шарда наиболее критическим проектным решением при реализации шардинга. MongoDB предлагает встроенный шардинг через маршрутизаторы mongos и config servers, Cassandra реализует прозрачный шардинг через согласованное хэширование по своему кольцу, а PostgreSQL может шардироваться с расширениями вроде Citus или маршрутизацией на уровне приложения к отдельным экземплярам PostgreSQL. Шардинг баз данных вводит сложность кросс-шардных запросов: операции, охватывающие несколько шардов (join'ы, агрегации, кросс-шардные транзакции), требуют координации на уровне приложения или маршрутизатора запросов — именно поэтому Elasticsearch часто используется для кросс-шардных поисковых нагрузок, тогда как PostgreSQL или Cassandra с шардингом обрабатывают авторитетное хранение. Конфигурация шардинга и миграции управляются через IaC и требуют тщательного планирования мощности — решардинг (ребалансировка данных при добавлении новых шардов) операционно дорогостоящ, поэтому начальное количество шардов и кардинальность ключа должны accommodировать несколько лет роста горизонтального масштабирования.
Как это работает
Шардирование БД бывает вертикальным (более мощная машина) — до лимитов одной, потом горизонтальным (больше машин за балансировщиком). Stateless-сервисы масштабируются горизонтально тривиально; stateful (БД, очереди) — через primary-replica репликацию, шардинг или оба. Read-реплики поглощают read-нагрузку; write-throughput требует либо больший primary, либо шардинг, либо хитрости (CQRS + eventual-consistency reads). Агрессивно кешируйте на границе (CDN), на app-слое (Redis), внутри процесса.
Когда применять
Сначала вертикально — самое дешёвое и наименее болезненное операционно. Read-реплики — когда primary DB тратит > 50% CPU на чтения. Шардируйте только когда ни один primary не справляется с write rate (эта точка дальше, чем думают — Postgres держит 10k+ writes/sec с тюнингом). CDN — для любого публичного статичного или редко-меняющегося контента; выигрыш в latency обычно 5-10×.
Типичные ошибки
Ловушки Шардирование БД: расчёт, что горизонтальное масштабирование решит всё (нет для stateful); преждевременный шардинг (необратимо без огромных миграций); игнор pooling — 1000 app-pod'ов по 10 соединений валят БД; не нагружаете до решений о масштабе (тюните не тот слой). Сначала меряйте, потом масштабируйте, потом документируйте.