Базы данных
Трек баз данных: спроектируй и затюнь production-схему
Трек учил семи моментам отказа базы по отдельности. Этот капстоун заставляет прожить их все на одном продукте: multi-tenant система заказов растёт от MVP-таблицы до решения о шардинге. Ты спроектируешь схему, докажешь индексы, прочитаешь планы, защитишь границу и мигрируешь её — с измерениями на каждом шлюзе.
Преврати весь трек в один воспроизводимый инженерный цикл на одной схеме: смоделируй ради integrity, проиндексируй под реальный паттерн доступа, диагностируй планы по статистике, выбери изоляцию против настоящих аномалий, рассчитай размер пула из математики конкурентности, выстрой ломающее изменение через expand-contract и прими решение «шардить или нет» с доказательствами.
Спроектируй, загрузи и затюнь production-образную multi-tenant схему PostgreSQL для системы заказов/леджера, затем проведи её через одну ломающую миграцию и задокументированное решение о шардинге — доказывая каждый шаг выводом EXPLAIN ANALYZE и числами до/после, а не утверждениями.
- Файл DDL схемы плюс абзац обоснования на каждое неочевидное решение моделирования (тип ключа, каждый constraint, единственный компромисс денормализации/JSONB и его новый владелец).
- Для каждого индекса: парный вывод EXPLAIN ANALYZE (до/после), показывающий смену скана и фактическое время, а не только оценочную стоимость.
- Сфорсированный плохой план, захваченный с разрывом ожидаемых-против-фактических строк, и план после фикса, показывающий переключение join и меньшее время выполнения.
- Воспроизводимая демонстрация на двух сессиях аномалии конкурентности и её фикса, с записанным решением об изоляции/блокировке и его компромиссом.
- Выписанная математика размера пула плюс доказательство (логи или метрики), что transaction mode PgBouncer поглотил storm соединений, который прямые коннекты не выдержали.
- Runbook миграции с каждой фазой expand-contract, подходом к батчевому backfill и доказательством (настройки lock_timeout + наблюдение pg_locks), что ни одна фаза не встала в очередь за долгой блокировкой таблицы.
- Меморандум решения о шардинге: измеренный потолок одного узла, порядок исчерпания рычагов, выбранный ключ шардирования с обоснованием ко-локации и митигация hot shard.
- Добавь triage-runbook, мапящий каждый из семи режимов отказа трека (схема, индекс, статистика, bloat, пулинг, миграция, шардинг) на его первый диагностический запрос и первый фикс — твоя on-call шпаргалка.
- Воспроизведи сценарий bloat от долгой транзакции: держи одну транзакцию открытой, гоняй тяжёлые апдейты, покажи рост таблицы и провал VACUUM, затем докажи фикс, завершив транзакцию и перезапустив VACUUM.
- Добавь CI-шлюз, гоняющий EXPLAIN на топ-запросах против засеянной базы и роняющий сборку, если любой план регрессирует к seq scan или отношение ожидаемых/фактических строк превышает порог.
- Подними версию крупнейшей таблицы на 2-узловом Citus (или партиционированную) и перезапусти нагрузочный тест записи, сравнив пропускную способность и стоимость cross-shard запросов с одним узлом.
Это цикл, который ты гоняешь всю жизнь реальной базы: моделируй ради integrity и гни лишь с названным компромиссом, индексируй под паттерн доступа и доказывай через EXPLAIN, считай оценки строк несущим входом планировщика, выбирай изоляцию против конкретной аномалии, которую можешь продемонстрировать, рассчитывай пул из математики конкурентности и мультиплексируй тяжёлые backends, мигрируй ломающие изменения через expand-contract, чтобы версии сосуществовали, и берись за шардинг последним — на высококардинальном ко-локирующем ключе, лишь после измерения потолка одного узла и исчерпания более дешёвых рычагов. Сделав все семь на одной схеме, ты превращаешь трек из фактов в суждение.