Базы данных

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

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

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

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.

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

Практика

SQL-песочница: быстрый исполняемый маршрут

1. База запроса: Активные клиенты, Сотрудники без ментора, Три последних заказа.
2. Join и cardinality: Клиенты без потери нулевых заказов, Оплаченные заказы без дублей, Сотрудники и руководители.
3. Aggregation: Города с выручкой выше порога, Средний оплаченный чек по городам, Первый заказ пользователя.
4. Senior SQL: Следующая страница заказов, Второй заказ пользователя, Накопительная выручка.

Готовность: решите по одной задаче из каждого ряда, затем проговорите, какую ошибку проверял раннер и как бы вы объяснили решение интервьюеру.

1. Data model, relationships и invariants

Связка: Databases q-1..q-5, Databases q-11..q-12, Nest q-11.

Что сделать:

1. Смоделируйте orders, customers, order_items, payments.
2. Заполните relationship map: entity -> relation -> cardinality -> FK/unique -> delete rule -> invariant.
3. Для каждого спорного поля решите: normal column, separate table, denormalized read model, cache или JSONB.

Артефакт: data model invariant map + normalization/denormalization decision table.

Критерий готовности: вы объясняете схему через инварианты и workload, а не просто рисуете таблицы.

2. Query performance и index evidence

Связка: Databases q-3..q-5, Databases q-8..q-10, Databases q-19.

Что сделать:

1. Возьмите 3 slow-query сценария: list with filter/sort, detail with relations, report/aggregate.
2. Для каждого заполните EXPLAIN checklist: scan, filter, estimated/actual rows, loops, sort, join, buffers, execution time.
3. Предложите индекс или query rewrite и зафиксируйте before/after: план, p95/p99, write-cost risk.

Артефакт: slow-query investigation report for 3 queries.

Критерий готовности: вы доказываете эффект индексом/планом/метрикой, а не говорите "добавлю индекс".

3. Transactions, idempotency и consistency

Связка: Databases q-6..q-7, Databases q-13, Databases q-15, Senior q-7.

Что сделать:

1. Спроектируйте операцию confirm order: transaction boundary, isolation assumption, unique constraints, idempotency key, retry behavior.
2. Заполните idempotency/unique-constraint retry matrix: first request, same retry, changed payload, concurrent retry, expired key, processing state.
3. Опишите optimistic locking case: где нужен version, что возвращать при conflict, как клиент должен сделать rollback/refetch.

Артефакт: transaction design note + idempotency retry matrix.

Критерий готовности: вы предотвращаете двойную запись и race condition через constraints/transaction/idempotency, а не через "проверим перед insert".

4. Migration, cache, replica и operational risk

Связка: Databases q-14, Databases q-16..q-18, Node q-10.

Что сделать:

1. Соберите expand/contract migration checklist для rename column или добавления non-null поля на большой таблице.
2. Добавьте cache invalidation timeline: read miss, fill, update DB, invalidate, concurrent read, retry, stampede protection.
3. Добавьте replica lag routing matrix: profile, catalog, permissions, admin report, read-after-write.
4. Добавьте DB monitoring signal map: latency, lock wait, pool saturation, replication lag, top SQL, cache hit ratio, dead tuples/vacuum pressure.

Артефакт: migration runbook + cache/replica/monitoring matrices.

Критерий готовности: вы показываете, как изменение данных живет в production: phased rollout, rollback, monitoring, alert и degraded mode.

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

1. Modeling and query basics: Databases q-1..q-5, Databases q-11..q-12.
2. Transactions and consistency: Databases q-6..q-7, Databases q-13, Databases q-15.
3. Operations and reliability: Databases q-14, Databases q-16..q-20.
4. Backend integration: Node q-10, Node q-20, Nest q-11.
5. Повторение: через 24 часа заново объясните один slow-query case и один transactional race без подсказок.

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

Ready: вы объясняете модель данных, индексы, транзакции, миграции и operational controls через workload, correctness и production risk.

Partial: вы знаете SQL/индексы/ACID определения, но не показываете plan evidence, idempotency matrix или migration rollback.

Not ready: вы предлагаете "добавить индекс", "обернуть в транзакцию" или "закэшировать" без проверки workload, consistency и failure mode.

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

1. Data model invariant map.
2. Normalization/denormalization decision table.
3. Slow-query investigation report for 3 queries.
4. Transaction design note + idempotency retry matrix.
5. Expand/contract migration runbook.
6. Cache invalidation timeline.
7. Replica lag routing matrix.
8. DB monitoring signal map.

Куда дальше

1. SQL-песочница: начните с Клиенты без потери нулевых заказов, затем Города с выручкой выше порога и Следующая страница заказов.
2. База вопросов: Базы данных: проговорить q-1..q-20 после практики.
3. Node.js: связать DB-решения с API, observability и graceful degradation.
4. NestJS: отработать слой service/repository, транзакции и тесты.