Выбор ключа шарда: стратегии hash, range, list и directory

Две команды шардируют свой Postgres по customer_id. Одна использует хеш-шардирование; через шесть месяцев у них нет горячих шардов. Другая использует range-шардирование с тем же ключом; у них постоянный горячий хвост на шарде с самыми большими ID клиентов, потому что все новые регистрации попадают туда. Одна колонка, разные стратегии, противоположный результат.

Четыре свойства хорошего ключа шарда

Ключ шарда должен одновременно удовлетворять всем четырём условиям:

1. Селективность: 95%+ ваших запросов фильтруют по нему. Запросы без ключа шарда должны обходить все шарды — это дорого и медленно.
2. Равномерное распределение: каждый шард получает примерно равное количество данных и трафика. Неравномерные ключи порождают горячие шарды.
3. Стабильность: значение никогда не меняется для данной строки. Изменение ключа шарда потребовало бы перемещения строки на другой шард — проблема, которую нельзя решить во время обновления.
4. Доступность во время маршрутизации: каждый API-запрос, касающийся этих данных, должен содержать ключ шарда. Если запросы приходят без него, нельзя маршрутизировать без кросс-шард сканирования.

Для мультиарендного B2B SaaS tenant_id почти всегда удовлетворяет всем четырём. Для B2C — user_id. Для геораспределённых систем — region. Схемы данных, в которых нет колонки, отвечающей всем четырём свойствам — красные флаги; разбейте модель данных до тех пор, пока такая колонка не появится.

Четыре стратегии

Хеш-шардирование — это дефолт для большинства OLTP-систем, потому что при равномерном распределении ключей оно распределяет равномерно. Проблема в том, что реальные клиенты распределены по степенному закону: один клиент в 100–1000 раз превышает медианный. Хеш по-прежнему маршрутизирует этого клиента на один шард — горячий шард.

Range-шардирование естественно для time-series данных (шард по месяцу), но по умолчанию создаёт горячий хвост: все новые записи идут на последний шард, пока старые шарды простаивают. Продакшн-системы time-series обычно сочетают range (по временному бакету) с hash (внутри бакета) для распределения нагрузки записи.

Directory-based шардирование — наиболее гибкое: lookup-таблица маппит tenant_id → connection_string. Перемещение клиента означает обновление одной строки. Это основа примитива изоляции клиентов Citus и маршрутизации на уровне приложения в мультиарендном SaaS. Цена — lookup-таблица становится инфраструктурой первого уровня критичности: она должна быть высокодоступной, малолатентной и агрессивно кешироваться.

Consistent hashing — вариант хеша, используемый в основном в кешах (Memcached, Redis Cluster), где добавление или удаление шарда перемещает только K/N ключей вместо большинства. Некоторые конфигурации шардирования Postgres используют directory-based consistent hashing для онлайн-ребалансировки шардов.

Контракт ключа шарда на практике

Ключ должен входить в первичный ключ каждой шардированной таблицы. Если orders шардирована по tenant_id, то (tenant_id, order_id) — это первичный ключ, а не просто order_id. Это гарантирует уникальность по шардам и заставляет каждый путь запроса нести tenant_id.