Базы данных
Трек баз данных: тест с выбором ответа
Суть MCQ на синтез поперёк трека: связать схему, индексы, планы, MVCC, пулинг, миграции и шардинг в одно дерево решений, ведущее продукт от MVP до шардированного кластера.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего трека. Каждый — момент в жизни одного продукта (от единственной таблицы до кластера на миллиард строк), где сталкиваются два понятия из баз данных и нужно выбрать рычаг, чинящий именно нужный слой.
Цель
Убедись, что собираешь трек в цепочку: смоделировать схему, выбрать индекс, который планировщик реально использует, прочитать, почему план сломался, выбрать уровень изоляции, рассчитать размер пула, выстроить миграцию без даунтайма и решить, нужен ли шардинг вообще.
Викторина
Completed
Запрос фильтрует orders по тенанту и дате, ты добавляешь composite-индекс. Оба плана ниже — по одной таблице, различается лишь порядок колонок индекса. Почему планировщик пропускает индекс в плане A? ```sql -- query SELECT * FROM orders WHERE tenant_id = 42 AND created_at >= '2026-01-01'; -- A: CREATE INDEX ON orders (created_at, tenant_id); -> Seq Scan -- B: CREATE INDEX ON orders (tenant_id, created_at); -> Index Scan ```
Heads-up Оба индекса покрывают одни и те же две колонки и почти одинаковы по размеру. Выбор определяется тем, совпадает ли ведущая колонка с паттерном доступа, а не размером индекса.
Heads-up Использует — именно для этого нужен индекс B. Равенство по ведущей колонке, затем диапазон по следующей — каноничный выигрыш composite-индекса.
Heads-up Порядок текста WHERE не важен. Важно ставить колонки равенства первыми, затем колонку диапазона — leading-column rule, а не порядок в исходнике.
Викторина
Completed
Ночной batch держит одну транзакцию открытой три часа. За это же окно OLTP-таблица под активными UPDATE растёт с 8 ГБ до 40 ГБ на диске, хотя число живых строк почти не меняется. Что связывает долгую транзакцию с bloat?
Heads-up Число живых строк почти не меняется — это не рост от вставок. Это накопление dead tuples: апдейты создают новые версии, а старые нельзя вакуумировать, пока держится долгий снимок.
Heads-up UPDATE создаёт новую версию tuple на каждую изменённую строку, а не полный rewrite таблицы. Bloat — от неосвобождаемых мёртвых версий, а не от переписывания.
Heads-up Более строгая изоляция держит снимки как минимум столько же, если не дольше. Лекарство — не держать одну транзакцию открытой часами, а не ужесточать изоляцию.
Викторина
Completed
Отчётный запрос был быстрым месяцами, потом внезапно выбрал nested-loop join вместо hash join и вырос с 200 мс до 40 с после всплеска импорта данных. EXPLAIN ANALYZE показывает: планировщик ждал 12 строк из одной ветки, получил 2,1 млн. Корневая причина и первый устойчивый фикс?
Heads-up Nested loop оптимален, когда одна сторона действительно крошечная. Дефект — не алгоритм соединения, а оценка строк, скормившая выбор. Чини статистику, а не join.
Heads-up В Postgres нет синтаксиса хинтов, а пиннинг одного плана маскирует проблему. Промах оценки исказит и другие запросы; обновление статистики чинит вход, который читает планировщик.
Heads-up work_mem влияет на то, сольётся ли выбранный hash на диск, но здесь планировщик hash join вообще не выбрал. Триггер — промах кардинальности, проблема статистики.
Викторина
Completed
Ты ставишь приложение за PgBouncer в transaction mode, чтобы пережить storm соединений. Сразу же приложение падает с ошибкой, что prepared statements не существуют, а SET search_path, выполненный при коннекте, больше не держится. Почему?
Heads-up Он ничего не портит. Поведение by design: transaction mode мультиплексирует много клиентов через мало серверных соединений, поэтому всё, что предполагает стабильное соединение сессии, ломается.
Heads-up Размер пула управляет конкурентностью, а не временем жизни statement. Statements исчезают потому, что в transaction mode клиент не держит то же серверное соединение между транзакциями.
Heads-up Session mode сохраняет состояние сессии, но пиннит одно серверное соединение на клиента на всю сессию, убивая мультиплексацию, которая решила storm соединений. Это реальный компромисс, а не бесплатный фикс.
Викторина
Completed
Нужно переименовать горячую колонку `email` в `email_address` на таблице с 500 млн строк без даунтайма, пока старый и новый код приложения работают бок о бок во время rolling-деплоя. Какая последовательность верна?
Heads-up RENAME быстр на каталоге, но это ломающее изменение: в момент коммита старый код по старому имени падает. С двумя живыми версиями при rolling-деплое нужен expand-contract, а не атомарный rename.
Heads-up Требование — ноль даунтайма с сосуществующими версиями. Окно плюс big-bang деплой нарушают оба ограничения; expand-contract — то, что даёт двум версиям кода перекрываться.
Heads-up NOT NULL плюс volatile default форсит полный rewrite таблицы под ACCESS EXCLUSIVE lock, замораживая таблицу и ставя в очередь все ждущие запросы — режим отказа очереди блокировок. Делай backfill батчами.
Викторина
Completed
Multi-tenant SaaS упирается в лимит записи на одном Postgres. Команда предлагает hash-шардинг по колонке `country`. Три тенанта в одной стране дают 70% трафика. Что пойдёт не так и какой ключ шардирования лучше?
Heads-up Равномерный хеш раскладывает ключи ровно, но нагрузка — на ключ, а не на различимое значение. Низкокардинальный перекошенный ключ вроде country концентрирует реальный трафик в один шард независимо от равномерности хеша.
Heads-up Случайный пошардовый шардинг раскладывает запись, но рассыпает строки каждого тенанта по всем шардам, превращая любой запрос и join тенанта в cross-shard fan-out. Ко-локация по tenant_id — в этом весь смысл.
Heads-up Шардинг — последнее средство после исчерпания схемы, индексирования, тюнинга планов, пулинга и read-реплик — он добавляет cross-shard join, ребалансировку и операционную стоимость. Сначала убедись, что потолок одного узла реально достигнут.
Итог
Трек — одно дерево решений для растущего продукта: сначала смоделируй схему ради integrity, добавь индекс, чья ведущая колонка совпадает с паттерном доступа, читай план, чтобы ловить ошибки оценки строк до каскада, держи транзакции короткими, чтобы MVCC мог вакуумить, рассчитай размер и режим пула, чтобы пережить storm соединений, разложи каждое ломающее изменение на фазы expand-contract и берись за шардинг только после выбора высококардинального ко-локирующего ключа и исчерпания всех более дешёвых рычагов. Каждый режим отказа сводится к одному вопросу: какой слой — узкое место и какой самый дешёвый рычаг его чинит?