Как выбирается ключ шардирования?

Question

Ключ шардирования выбирают так, чтобы данные распределялись равномерно и запросы чаще попадали в один шард. Обычно берут поле с высокой уникальностью (например, user_id) и стабильной семантикой. Важно избегать ключей, которые создают “горячие” шарды, например дату или монотонно растущий идентификатор без хеширования. Также учитывают, как будут выполняться JOIN и выборки по основным фильтрам.

YeaHub · Accepted Answer

Шардирование — это разбиение данных на несколько независимых частей (shards), чтобы масштабировать хранение и нагрузку. Ключ шардирования определяет, в какой шард попадет запись и куда пойдет запрос.Что важно от ключа шардированияСначала формулируют требования к ключу, иначе шардирование быстро превращается в постоянную “борьбу с перекосами”.1) Равномерное распределение данныхКлюч должен давать близкий к равномерному распределению:высокая кардинальность (много разных значений)отсутствие сильной корреляции с временем/нагрузкойотсутствие “топовых” значений, на которые приходится большинство операцийПример плохого ключа:created_at (все новые записи идут в один “хвост”)country (несколько больших стран перегружают отдельные шарды)2) Локальность запросовИдеально, когда большинство запросов можно обслужить одним шардом:запросы по user_id → шардирование по user_idзапросы по tenant_id (multi-tenant) → шардирование по tenant_idЕсли запросы регулярно требуют данных “со всех шардов”, вы получите fan-out:растет латентностьрастут расходы на сетьусложняется отказоустойчивость3) Отсутствие hotspotHotspot — это шард, который постоянно “горячий” из-за перекоса в данных или трафике.Типовые причины:монотонно растущий ключ без хешированиянебольшое множество популярных значений“топовые” пользователи/тенанты, генерирующие основной трафикЧастая техника для борьбы:использовать hash(user_id) вместо “сырого” user_idили консистентное хеширование на уровне роутинга4) Стабильность ключаКлюч должен редко меняться. Если значение ключа меняется — запись нужно “перевезти” в другой шард, а это:дорогая операциятребует согласованностиусложняет транзакции и ссылкиПоэтому, например, email как ключ часто плох, а user_id — хорош.5) Влияние на связи и транзакцииШардирование меняет жизнь JOIN и транзакций.Если у вас есть частые связи:orders ↔ userspayments ↔ ordersто разумно выбирать ключ так, чтобы связанные сущности попадали в один шард. Например:orders шардинг по user_idpayments шардинг по тому же user_id или по order_id, если order_id однозначно привязан к user_id и роутинг это знаетТиповые стратегии выбораШардирование по ID (user-centric)Подходит, если:большинство запросов “вокруг пользователя”нужен хороший балансудобна локальностьПример роутинга:shard = hash(user_id) % N
Шардирование по tenant_id (multi-tenant)Подходит, если:система multi-tenantважна изоляция крупных клиентоввозможны отдельные политики на тенантаМинус: “крупный тенант” может перегреть один шард, тогда приходится делать “тенант внутри тенанта” или отдельные шарды для крупных.Шардирование по времени (time-series)Подходит для логов/метрик, но почти всегда требует:партиционирования внутри шардааккуратной стратегии на “горячий хвост”возможного split горячих диапазоновПрактический мини-примерДопустим, основной паттерн: “показать профиль и последние заказы пользователя”.Тогда логично:users шардировать по user_idorders шардировать по user_idчитать данные без fan-outПример (упрощенно):GET /users/42
GET /users/42/orders?limit=20
Оба запроса идут в один и тот же шард.ВыводКлюч шардирования выбирают так, чтобы обеспечить баланс (без hotspot), локальность большинства запросов (минимум fan-out), стабильность (редко меняется) и разумную модель для связей/транзакций. На практике чаще всего выигрывает user_id или tenant_id с хешированием.