Базы данных

Для чего модуль

Научиться принимать решения по данным так, чтобы система была быстрой, корректной и эволюционировала без аварийных миграций.

Результат после прохождения

1. Вы выбираете SQL/NoSQL под конкретный продуктовый сценарий.
2. Вы проектируете схемы и индексы через реальные паттерны чтения/записи.
3. Вы понимаете транзакции, согласованность и компромиссы под нагрузкой.
4. Вы умеете планировать безопасные миграции и производственную поддержку БД.

Термины и аббревиатуры

Термин	Коротко
ACID	Свойства надежной транзакции
Index	Ускорение поиска
Isolation	Степень изоляции транзакций
N+1	Лишние последовательные запросы
Replication	Копирование данных между узлами

Фокус по грейдам

1. Junior: понимать базовые механики и объяснять их простыми примерами.
2. Middle: применять тему в продуктовых сценариях с учетом рисков и ограничений.
3. Senior: управлять архитектурными trade-offs, метриками и эволюцией решения.

Как работать с модулем

1. Для каждого урока используйте один домен (orders, payments, users).
2. Любое решение связывайте с workload: read/write ratio, latency, consistency.
3. После урока фиксируйте артефакт: схема, explain-анализ, миграционный план.

Программа модуля

Урок 1. Моделирование данных

Цель: проектировать схему, которая отражает доменные инварианты и рабочие сценарии.

От домена к схеме

1. Определите сущности и их жизненный цикл.
2. Выделите инварианты (уникальность, обязательность, связи).
3. Отразите инварианты на уровне constraints, а не только кода.

SQL vs NoSQL (практично)

1. SQL — когда критичны связи, транзакции, отчетность.
2. NoSQL — когда нужны гибкие документы, горизонтальный масштаб, event-heavy сценарии.
3. Часто оптимален polyglot подход, если есть дисциплина границ.

Где ломается в проде

1. Схема проектируется «под текущий экран», а не под эволюцию домена.
2. Инварианты живут только в приложении и теряются при обходных путях.
3. Выбор типа БД делается по моде, а не по workload.

Мини-задача (обязательная)

Смоделируйте схему для одного домена: сущности, связи, ограничения, ожидаемые read/write patterns.

Что спросит интервьюер: почему вы выбрали эту модель данных и какие альтернативы отвергли.

Критерий готовности по уроку: вы можете защитить схему через доменные инварианты и рабочие сценарии.

Урок 2. Запросы и индексы

Цель: ускорять запросы системно, а не «добавляя индекс на всё подряд».

Оптимизация через планы выполнения

1. Читайте EXPLAIN/EXPLAIN ANALYZE.
2. Ищите full scan, неэффективные join, сортировки и фильтры.
3. Оптимизируйте в порядке наибольшего влияния на p95/p99.

Индексная стратегия

1. Индексы создаются под реальные query patterns.
2. Композитный индекс зависит от порядка фильтрации/сортировки.
3. Каждый индекс ускоряет чтение, но повышает цену записи.

Где ломается в проде

1. Много лишних индексов замедляют writes.
2. Нет регулярного аудита «мертвых» индексов.
3. Запросы растут по сложности без пересмотра схемы.

Мини-задача (обязательная)

Оптимизируйте 3 медленных запроса: зафиксируйте план до/после и влияние на latency.

Что спросит интервьюер: как вы понимаете, что именно этот индекс даст эффект.

Критерий готовности по уроку: вы можете обосновать оптимизацию запроса через план выполнения и измеримый результат.

Урок 3. Транзакции и согласованность

Цель: управлять корректностью данных под конкурентной нагрузкой.

ACID и уровни изоляции

1. Read phenomena (dirty/non-repeatable/phantom reads).
2. Выбор isolation level по критичности операции.
3. Trade-off между строгой согласованностью и throughput.

Idempotency и конкурентные сценарии

1. Idempotency key для повторяемых операций.
2. Защита от double-submit и race conditions.
3. Явные правила retry для транзакционных операций.

Где ломается в проде

1. Транзакции слишком широкие и блокируют систему.
2. Отсутствие idempotency в платежных/заказных сценариях.
3. Неверные assumptions о последовательности событий.

Мини-задача (обязательная)

Опишите стратегию для операции «подтвердить заказ»: транзакция, idempotency, обработка ретраев, ожидания по консистентности.

Что спросит интервьюер: как вы предотвращаете двойную запись в конкурентном сценарии.

Критерий готовности по уроку: вы можете описать надежный сценарий записи под конкуренцией без потери корректности.

Урок 4. Production-поддержка

Цель: сопровождать БД как критичную инфраструктуру.

Миграции без простоя

1. Expand/contract подход.
2. Backfill с контролем нагрузки.
3. Совместимость старой и новой схемы на переходном этапе.

Мониторинг и операционка

1. Метрики: latency, lock wait, connection saturation, replication lag.
2. Alerting и runbook на типовые деградации.
3. Backup/restore проверяется регулярно, а не «на словах».

Где ломается в проде

1. Деструктивные миграции без phased rollout.
2. Нет проверенного процесса восстановления.
3. Инциденты решаются вручную без постмортема.

Мини-задача (обязательная)

Соберите migration plan для изменения схемы в живом сервисе: этапы, риски, проверки, rollback.

Что спросит интервьюер: как вы проводите миграцию схемы без downtime.

Критерий готовности по уроку: вы можете провести изменение схемы и показать, как контролируете риск инцидента.

Практика

1. Сформируйте модель данных с явными инвариантами.
2. Оптимизируйте 3 запроса через explain-анализ.
3. Подготовьте дизайн транзакции для критичной операции.
4. Сделайте migration runbook с expand/contract.
5. Закрепите в Базы данных вопросах, Node.js, NestJS.
6. Смоделируйте slow-query кейс в Песочнице, проверьте гипотезу индексом и сравните метрики.

Связь с треками и вопросами

1. Треки: Middle трек, Senior трек.
2. Вопросы: Базы данных, Node.js.
3. Повторение: 3-5 вопросов без подсказок -> сверка с модулем -> повтор через 24 часа.

Критерий готовности

Вы объясняете модель данных, индексы и транзакционные решения через workload, корректность и эксплуатационные риски.

Артефакты после модуля

1. Data model с комментариями по trade-offs.
2. Отчет по оптимизации 3 запросов (до/после).
3. Migration plan + rollback strategy.
4. Набор из 6 сильных interview-ответов по базам данных.

Куда дальше

1. Node.js
2. NestJS
3. Базы данных