Акт 7 в глубину: шардинг, co-location и семиуровневый каскад трейдоффов

Citus развёрнут. Shard key — tenant_id. Большинство tenants быстры. Tenant Acme — 40% всех запросов — насыщает свой шард, пока пять других простаивают. Кластер фактически одношардовый для Acme. Сбой hot shard был не вызван шардингом; он был спроектирован в день выбора shard key.

Акт 7 — Три независимых решения шардинга

Шардинг в год 3 включает три независимых решения:

Решение 1: Shard key. Shard key определяет распределение данных и локальность запросов. Для B2B multi-tenant SaaS tenant_id — естественный выбор: все запросы для одного tenant остаются на одном шарде. Для B2C — user_id. Для time-series — time bucket. Ключ должен иметь высокую кардинальность (для равномерного распределения нагрузки), равномерные паттерны доступа (чтобы ни один шард не был горячим) и быть дешёвым в вычислении (чтобы routing overhead был минимальным).

Решение 2: Метод распределения.

• Hash: строки хешируются на шарды — равномерное распределение, range queries веером расходятся по всем шардам.
• Range: строки в диапазоне ключей идут на конкретный шард — range queries остаются локальными, но горячий диапазон создаёт горячий шард.
• List: ручное назначение — гибко, высокие операционные издержки.
• Directory: lookup table маппит значения ключей на шарды — максимальная гибкость, максимальные операционные издержки.

Решение 3: Co-location. Таблицы, участвующие в join-ах, должны быть размещены на одном shard key, чтобы cross-shard join-ы оставались локальными. В Citus: users, orgs, events, audit_log — все шардированные по tenant_id — co-located. Join между users и events для tenant 42 попадает на один шард и возвращается с локальной латентностью. Без co-location тот же join веером идёт по всем шардам, собирает результаты на coordinator и мёрджит.

Federation tax

После шардирования запросы, охватывающие несколько шардов, должны быть federated: отправить запрос на каждый шард, собрать результаты и смёрджить на стороне приложения или на Citus coordinator.

Наивный outer join через два шарда становится двумя inner queries (по одному на шард) и client-side join. GROUP BY, затрагивающий шарды, становится GROUP BY на каждом шарде, затем второй GROUP BY по агрегатам. Каждый cross-shard запрос имеет latency = max(latency по шарду) + merge time; хвостовая латентность доминирует.

Citus обрабатывает federation с distributed query planning, но только для co-located таблиц (с одинаковым shard key). Reference tables (реплицированные на каждый worker-узел) бесплатны — маленькая dimension table типа countries или currencies может быть реплицирована один раз и join-иться локально везде.

Исправление hot shard

Когда Acme даёт 40% всех запросов на tenant_id-шардированном кластере:

• Вариант A — логическое разбиение: Направить запросы Acme на выделенный набор логических шардов. Tenant-aware router мультиплексирует Acme по shard ID, маппящимся на выделенный физический worker. Остальные tenants делят оставшиеся workers.
• Вариант B — физический кластер: Переместить Acme на свой собственный Postgres кластер. Запросы к Acme маршрутизируются туда; общий кластер обрабатывает все остальные tenants.

Оба варианта требуют онлайн-решардинга (citus_rebalance_table_shards), использующего логическую репликацию для суб-секундных пауз записи на шард. Планируй окно — догоняющая репликация добавляет нагрузку.

Семиуровневый каскад трейдоффов

Каждый акт открывает следующий, но только если предыдущий в порядке:

• Пропусти Акт 1 (схема) → Акты 2–7 воюют с неэффективными join-ами и изменяемыми натуральными ключами.
• Пропусти Акт 2 (индексы) → решения планирования Акта 3 принимаются вслепую; статистика бесполезна, если планировщику нечего выбирать.
• Пропусти Акт 3 (статистика) → vacuum Акта 4 единственный рычаг; таблицы раздуваются пока ты угадываешь мощность.
• Пропусти Акт 4 (bloat) → потоки пула Акта 5 видят table scans, замедленные мёртвыми tuples в heap pages.
• Пропусти Акт 5 (размер пула) → миграции Акта 6 задыхаются от connection storms; backlog handshakes соединений мешает миграции получить блокировки вовремя.
• Пропусти Акт 6 (lock safety) → шардинг Акта 7 невозможен без downtime; каждый shard rebalance требует эксклюзивной блокировки если миграции не были разработаны для онлайн-работы.
• Пропусти Акт 7 (когда нужен) → один tenant доминирует в кластере, и остальные ждут в очереди.

Порядок — ограничение, наложенное физикой и внутренностями Postgres, а не рекомендация.