Базы данных
Sharding: тест с выбором ответа
Суть Синтез всего юнита в формате с выбором ответа — выбор shard key, partitioning против sharding, ко-локация, hot shard, cross-shard транзакции и online resharding.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, проходящих сквозь весь юнит. Каждый отражает решение, которое вы принимаете у доски или в разгар инцидента — это не определение для пересказа, а компромисс, который нужно взвесить, когда одного Postgres уже не хватает.
Цель
Убедитесь, что вы связываете воедино выбор shard key, различие partitioning и sharding, ко-локацию, режим hot shard, cross-shard транзакции и online resharding — синтез, к которому вели семь уроков.
Викторина
Completed
B2B SaaS шардируется по tenant_id. Топ-5 арендаторов дают 60% трафика. Предлагают чистый hash sharding, потому что он 'распределяет равномерно'. В чём изъян и каково senior-решение?
Heads-up Hash маршрутизирует по tenant_id, поэтому все строки одного арендатора попадают на единственный шард. Арендатор с 60% трафика прижимает один шард к насыщению, пока остальные простаивают.
Heads-up Range sharding даёт контроль, но не устраняет перекос: каждый доминирующий арендатор всё равно попадает в шард своего диапазона, который становится горячим. Плюс появляется hot tail для новых регистраций.
Heads-up Time-range sharding создаёт hot tail (все новые записи бьют в последний шард) и проваливает selectivity — запросы несут tenant_id, а не диапазон времени, поэтому они уходят в fan-out по всем шардам.
Викторина
Completed
Команда добавляет `PARTITION BY RANGE (created_at)` к самой большой таблице и заявляет, что 'зашардировала базу'. Через месяц пропускная способность записи не изменилась. Почему?
Heads-up Прогрев кэша не меняет структурный факт: каждая партиция живёт на том же primary. Нет дополнительной ёмкости записи, в которую можно было бы прогреться.
Heads-up Индекс ускоряет поиск, но не добавляет ёмкости записи. Partitioning никогда не умножает пропускную способность, потому что не добавляет машин — это делает sharding.
Heads-up Это разные вещи: partitioning — это single-instance pruning и retention; sharding — это multi-instance масштабирование пропускной способности. Их смешение и есть ошибка этой команды.
Викторина
Completed
В Citus-кластере, шардированном по tenant_id, инженер добавляет `audit_log`, распределённый по `id` вместо `tenant_id`, и выполняет `SELECT … FROM orders o JOIN audit_log a ON a.order_id = o.id WHERE o.tenant_id = 42`. Что происходит?
Heads-up Фильтр сужает orders до одного шарда, но подходящие строки audit_log разбросаны по всем шардам по id. Citus не может протолкнуть join на один worker, поэтому уходит в fan-out.
Heads-up Citus принимает любой объявленный ключ распределения. Цена платится во время запроса как fan-out join, а не отклонением при вставке.
Heads-up Citus никогда не перераспределяет таблицу сам — он использует объявленный ключ. Выравнивание ключей (ко-локация) — это осознанное решение по схеме, которое инженер должен принять.
Викторина
Completed
Срабатывает алерт на перекос: один шард на 94% CPU, остальные 31 в среднем на 18%, и pg_stat_statements относит 62% времени запросов этого шарда к одному арендатору. Каково правильное немедленное действие?
Heads-up Ребалансировщик двигает целые шарды между worker'ами; он не отделяет доминирующего арендатора от общего шарда. Горячий арендатор остаётся в связке и продолжает насыщать свой worker.
Heads-up Больше worker'ов позволяет ребалансировщику двигать шарды, но шард горячего арендатора переезжает как единое целое и всё равно насыщает любой worker. Нужно изолировать арендатора, а не добавлять железо.
Heads-up Это даёт мгновенное облегчение, но не двигает данные; следующий запрос арендатора вернётся на тот же горячий шард. Лечится симптом, а не перекос.
Викторина
Completed
Транзакция возврата обновляет `orders` (tenant-scoped) и глобальную таблицу `ledger`, шардированную по `account_id`, так что две строки лежат на разных шардах. Citus выполняет это через two-phase commit. Какой режим отказа нужно мониторить?
Heads-up Весь смысл 2PC — атомарность между шардами: коммитят оба или ни один. Реальный риск — падение координатора посреди протокола, оставляющее зависшие подготовленные транзакции, а не потерянное обновление.
Heads-up Postgres не разрешает подготовленные транзакции сам. Зависшая держит блокировки (и может блокировать VACUUM), пока оператор не выполнит COMMIT PREPARED или ROLLBACK PREPARED. Нужны мониторинг и runbook.
Heads-up Характерная опасность 2PC здесь — in-doubt подготовленная транзакция после падения координатора. Долговечное проектное решение — ко-локация таблиц, чтобы транзакция была single-shard и вовсе обходила 2PC.
Викторина
Completed
Чтобы добавить ёмкость, команда запускает online rebalancing в Citus 11.1+. Посреди переезда падает координатор, и коллега паникует, что переезжающий шард повреждён. Как это читать и какой механизм делает ответ верным?
Heads-up Logical replication транзакционна; исходный шард нетронут, а на цели лишь частичные данные. Перезапуск ребалансировщика возобновляет процесс безопасно — восстановление не нужно.
Heads-up Online rebalancing держит кластер обслуживающим трафик; приостанавливается лишь один незавершённый переезд, остальные шарды не затронуты. Это не кластерный read-only.
Heads-up Resharding использует logical replication, а не physical — physical copy тянул бы страницы каждого арендатора, а не только переезжающего шарда. Logical replication копирует ровно переезжающие строки и позволяет возобновить переезд чисто.
Итог
Сквозная линия юнита — одна цепочка решений: выберите shard key, который селективен, равномерен, стабилен и присутствует при маршрутизации; партиционируйте ради pruning и retention, но шардируйте ради пропускной способности; ко-локируйте каждую tenant-scoped таблицу, чтобы 99% join оставались single-node; ждите hot shard на степенных арендаторах и отвечайте на них tenant isolation, а не ребалансировкой; держите транзакции single-shard, чтобы обойти in-doubt риск 2PC; и опирайтесь на online resharding на logical replication — помня, что смена shard key — это многомесячное решение, с которым живут годами.