МДК.04.01 · 4 КУРС7–8 СЕМЕСТРЫ

Технология разработки
и защиты баз данных

Формат
задача → механизм → лаборатория → поломка и восстановление
Объём
114 часов · 57 занятий по 90 минут
Практика
44 занятия из 57
Результат
DATA PLATFORM v1.0 в вашем репозитории

нажмите любую клавишу, чтобы начать ▸

01/18

МДК.04.01 · 4 курс · 2026 / 2027

Технология разработки
и защиты баз данных

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

114 часов57 занятийдва семестрадифференцированный зачёт
00

Итоговый артефакт · DATA PLATFORM v1.0

Платформа данных, которую вы соберёте за два семестра

кэш · TTL · idempotency в той же транзакции publisher read model поток событий СЕРВИС Приложение API и фоновые задачи ИСТОЧНИК ИСТИНЫ PostgreSQL транзакции, права, восстановление ТАБЛИЦА OUTBOX выход событий БРОКЕР RabbitMQ ВРЕМЕННОЕ СОСТОЯНИЕ Redis потерять можно ДОКУМЕНТЫ MongoDB копия для чтения АНАЛИТИКА ClickHouse витрина событий

Точка на схеме — одно изменение данных: у заказа сменился статус. Приложение записывает изменение в PostgreSQL и в той же транзакции добавляет строку в таблицу outbox — очередь событий на публикацию. Publisher читает outbox и отправляет событие в RabbitMQ, откуда его независимо забирают два потребителя: первый обновляет документ в MongoDB, второй дописывает строку в ClickHouse. Redis в этой цепочке не участвует: в нём хранится только то, что можно потерять без последствий. Каждый раздел курса отвечает за свой участок схемы.

КАРТА

Зачем это на четвёртом курсе

Чем дисциплина отличается от курса баз данных

← С чем вы приходите

Вы уже владеете SQL, проектированием реляционных баз, транзакциями, миграциями, слоем доступа к данным, HTTP-API, Git, Docker и тестированием. Эти навыки мы считаем входными и заново их не проходим.

вход
→ Что добавляется

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

выход
Задача года у нас одна: данные распределены по пяти системам и частично продублированы — как удержать копии согласованными, доступ ограниченным, а систему восстановимой.
ГР

Планируемые результаты

Чему вы научитесь за год

Пять групп умений — их мы и проверяем на приёмке и на зачёте. Разделы курса, которые идут дальше, раскрывают каждую из них.

01 Выбирать хранилище под данные

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

Пять технологий без разграничения ответственности

карта размещения + ADR
02 Доводить изменение до всех копий

Доставляете изменение в производные хранилища без потерь и дублей

Двойная запись, дубли и потерянные события

сквозной поток данных
03 Ограничивать доступ и доказывать действия

Выдаёте минимальные права и подтверждаете отказ негативным тестом

Общие учётные записи, избыточные права, неучтённые копии

матрица доступа
04 Восстанавливать систему и держать нагрузку

Поднимаете систему после сбоя, называете остаточную потерю и знаете предел нагрузки

Резервная копия, которую ни разу не разворачивали

измеренные RPO и RTO
05 Делать проверки повторяемыми

Оформляете проверки так, что они переживают изменения кода и конфигурации

Ручная настройка, которую невозможно повторить

DATA PLATFORM v1.0

Строка со знаком «!» — типичная ошибка, которую мы воспроизводим на занятиях намеренно: повреждаем резервную копию, выдаём избыточные права, теряем событие. Задача студента — обнаружить неисправность, устранить её и предъявить фактический вывод системы. Нижняя строка карточки — то, что сдаётся по этой группе умений.

РЕЗ

Маршрут курса · 57 занятий · 11 разделов

Структура курса: 11 разделов, 57 занятий

Штриховкой отмечены четыре самостоятельные работы (занятия 24, 27, 30 и 32) — 8 часов из 114. Оставшиеся 106 часов аудиторные, это 53 пары. Седьмой семестр мы закрываем рубежной технической приёмкой платформы версии 0.5, восьмой — дифференцированным зачётом.

ГОД

Разделы 1–2 · занятия 1–7 · 14 часов

Выбор хранилища и документная модель

7 пар
01 Аудит текущего контура

Вы разворачиваете учебный стенд из чистого состояния, прогоняете первый smoke-тест и строите карту информационных потоков: где база, где кэш, где документное хранилище и аналитика, куда уходят выгрузки и в скольких местах лежит одна и та же запись.

карта потоков + реестр рисков
02 Выбор системы под нагрузку

Для пяти сценариев вы выбираете хранилище: реляционная база, документное хранилище, аналитическая витрина, кэш или брокер. Решение оформляете как ADR — короткую запись «выбрали это, потому что; отказались от того, потому что».

ADR-001 · границы систем
03–07 Документная модель MongoDB

Разбираем документ и коллекцию, вложение против ссылки, схемную валидацию, индексы с замером плана explain до и после, конвейер агрегации и повторяемую миграцию документов из версии 1 в версию 2.

документный модуль
Р1·Р2

Раздел 3 · занятия 8–12 · 10 часов

ClickHouse: аналитика на потоке событий

5 пар
08 Событийная модель

Сравниваем колоночное хранение со строковым и разбираем, почему аналитическая витрина не может быть источником истины. Дальше группа согласует набор продуктовых событий.

контракт событий v1
09 Физическая модель

Разбираем семейство MergeTree, ключ сортировки и разбиение на партиции. Одну и ту же таблицу вы создаёте в двух вариантах — а разницу между ними видно на замере типовых запросов.

ADR-003 · DDL и замеры
10–11 Загрузка и метрики

Вы настраиваете пакетную вставку событий с контролем качества входных данных — вместе с заранее подготовленными некорректными записями. Затем строите три продуктовые метрики, материализованное представление и политику TTL.

витрина + отчёт качества
12 Пересоздание витрины

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

скрипт rebuild + сверка
Р3

Разделы 4–5 · занятия 13–22 · 20 часов

Как изменение доходит до всех копий

10 пар · ядро курса
13–14 Владение данными и кэш

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

матрица владения · политика кэша
15–16 Двойная запись и outbox

Сначала мы воспроизводим рассогласование: в PostgreSQL изменение записано, а в производной копии его нет. Затем вы пишете скрипт сверки и переносите публикацию события в таблицу outbox — она заполняется в той же транзакции, что и само изменение.

скрипт сверки · контракт outbox
17–22 RabbitMQ и доставка

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

сквозной поток с trace id
Р4·Р5

Разделы 6–7 · занятия 23–38 · 32 часа · самый большой блок

Защита платформы и управление доступом

16 пар
23–26 Угрозы и личности сервисов

Определяем, какие данные представляют ценность, кто к ним обращается и где проходит граница доверия. Дальше вы выдаёте каждому сервису отдельную учётную запись, выносите секреты из конфигурационных файлов в защищённое хранилище и переводите соединения на TLS.

модель угроз · карта личностей
27–33 Шифрование и аудит

Разбираем, где нужно шифрование, а где хватает маскирования. Один пользовательский запрос вы прослеживаете от API до обоих потребителей. Раздел закрывает рубежная приёмка платформы версии 0.5.

DATA PLATFORM v0.5
34–37 Права в каждом хранилище

Вы настраиваете роли и права GRANT в PostgreSQL, построчный доступ для разных арендаторов, ограниченные права потребителей MongoDB и ClickHouse, виртуальные хосты RabbitMQ и пространства ключей Redis.

негативные тесты доступа
38 Расползание привилегий

Фактические права вы сверяете с матрицей доступа. Затем мы намеренно вносим в конфигурацию избыточное разрешение — и автоматическая проверка обязана поймать его до релиза.

регрессионный набор
Мем: ваш IP записан
АУДИТ ВСЁ ВИДИТ
Р6·Р7

Раздел 8 · занятия 39–43 · 10 часов

Резервное копирование и восстановление

5 пар
39 Что копируем, что пересоздаём

Для каждого компонента вы решаете, что копировать, а что восстанавливать пересозданием. Здесь же появляются два числа: допустимый объём потери данных (RPO) и допустимое время простоя (RTO), а с ними — порядок восстановления компонентов.

матрица восстановления · RPO/RTO
40–42 Восстановление по частям

Вы делаете базовую копию, настраиваете архив журнала WAL и восстанавливаете базу на момент перед ошибочным изменением. Дальше — MongoDB со сверкой контрольных выборок и ClickHouse: резервной копией либо повторным проигрыванием событий.

подтверждения восстановления
43 Учение по всей платформе

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

runbook · измеренные RPO/RTO

Резервную копию, которую ни разу не разворачивали, мы считаем непроверенной — поэтому каждое копирование в разделе вы подтверждаете восстановлением. Всё на синтетических данных.

Мем: всё пропало
БЭКАП БЫЛ?
Р8

Раздел 9 · занятия 44–48 · 10 часов

Производительность, блокировки и пределы нагрузки

5 пар
44 Базовый замер

До всяких правок вы замеряете три критичные операции: задержку, пропускную способность, долю ошибок, а также p50 и p95. Без этой точки отсчёта «стало быстрее» проверить нечем.

стенд замера + сырые числа
45 План выполнения запроса

Разбираем план выполнения запроса: полное сканирование против поиска по индексу, обращение к таблице за недостающими полями, роль статистики. Медленный запрос вы находите, правите и замеряете эффект тем же стендом.

планы до и после
46 Блокировки и дедлоки

Разбираем уровни изоляции, длительность блокировки и цепочку ожидания. Взаимоблокировку вы вызываете намеренно, а потом устраняете причину, а не внешнее проявление.

граф дедлока + исправление
47–48 Пулы, таймауты, пределы

Вы проводите диагностику MongoDB и ClickHouse, затем настраиваете пулы соединений, таймауты, ограничение выборки у потребителя и контроль отставания очереди. Нагрузочный тест показывает границу, за которой система деградирует управляемо.

отчёт нагрузочного теста
Мем: крик на монитор
p95 НЕ СОШЁЛСЯ
Р9

Разделы 10–11 · занятия 49–57 · 18 часов · финал

Тесты, наблюдаемость и передача платформы

9 пар
49–52 Проверки, которые запускаются сами

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

интеграционный набор + pipeline
53–55 Наблюдаемость и инцидент

Метрики, журналы и трассировки вы связываете с инструкциями по реагированию, задаёте целевые показатели и три проверенных оповещения. Затем расследуете подготовленный сбой, причина которого заранее неизвестна.

дашборд · отчёт об инциденте
56–57 Приёмка и зачёт

Платформу вы поднимаете из чистого состояния, а преподаватель выдаёт случайную карточку отказа. На зачёте каждый получает свой запрос на изменение, реализует его и сопровождает обязательным тестом на отказ.

дифференцированный зачёт
Р10·Р11

Реляционный контур курса

Часть логики переносится внутрь базы

Источник истины в курсе — PostgreSQL. В отличие от прошлых курсов, база здесь не только хранит данные: триггер, функция и расширение выполняются на её стороне. Ниже — как раз механизм из занятия 16, записанный средствами PostgreSQL.

psql · platform=# триггер, который сам заполняет outbox
CREATE FUNCTION orders_to_outbox() RETURNS trigger AS $$
BEGIN
  INSERT INTO outbox (aggregate_id, event_type, payload)
  VALUES (NEW.id, 'order.status_changed', to_jsonb(NEW));
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER orders_outbox AFTER UPDATE OF status ON orders
  FOR EACH ROW WHEN (OLD.status IS DISTINCT FROM NEW.status)
  EXECUTE FUNCTION orders_to_outbox();

Функция триггера возвращает специальный тип trigger и обращается к изменяемой строке через NEW и OLD. Когда у заказа меняется статус, строку в outbox добавляет сама база — в той же транзакции, что и само изменение: сохраняются либо обе записи, либо ни одной. Приложение о таблице outbox не знает, и событие не потеряется, даже если приложение упадёт сразу после записи.

PG · 1

Реляционный контур · чем PostgreSQL расширяется

Свои типы и подключаемые модули

psql · platform=# тип и домен вместо текстового поля
-- перечисление: значения проверяет сама база
CREATE TYPE order_status AS ENUM
  ('new', 'paid', 'shipped', 'cancelled');

-- составной тип: поля под одним именем
CREATE TYPE money_amount AS (
  amount  numeric(14,2),
  currency char(3)
);

-- домен: тип с правилом, которое не обойти
CREATE DOMAIN email AS text
  CHECK (VALUE ~ '^[^@\s]+@[^@\s]+\.[^@\s]+$');

CREATE EXTENSION IF NOT EXISTS pgcrypto;
pgcryptoШифрование и хеширование прямо в базе: crypt(), digest().
pg_stat_statementsСтатистика по запросам: сколько раз выполнялся и сколько времени занял. С неё начинается поиск медленного.
pg_trgmПоиск по неточному совпадению и индекс GIN под него. Индекс бывает не только B-деревом.
PostGISСвои типы, операторы и индексы — расширение приносит в базу целую предметную область.
Своё расширениеНабор функций, типов и операторов ставится одной командой CREATE EXTENSION и так же удаляется.

Здесь важен не перечень модулей. Систему типов PostgreSQL можно дополнить своими типами и доменами, и тогда корректность значения проверяет сама база, а не каждый обработчик по отдельности. Расширение добавляет готовый набор функций, операторов и индексов одной командой.

PG · 2

Как проходит пара

Как устроены 90 минут

90 МИНУТ
0–25
ТеорияПреподаватель даёт задачу — нагрузку, дефект или запрос на изменение — и разбирает один механизм с одной типовой ошибкой на подготовленном стенде. Готовое решение для копирования не выдаётся.
25–86
ПрактикаОсновная часть занятия. Вы вносите изменение, запускаете его и получаете фактический вывод системы. Ближе к концу преподаватель выдаёт карточку отказа — меняет право доступа, набор данных или резервную копию, — и дальше вы работаете с неисправной системой, а затем повторяете проверку.
86–90
GitКоммит или Pull Request и краткий вывод: что доказано и какое ограничение осталось.
90М

С чем работаем

Стек курса

PostgreSQLMongoDBClickHouse RedisRabbitMQDocker ComposeTestcontainers .NET или Pythonpsql · pgcrypto · pg_stat_statementsмиграции схемыконтрактные тесты CI/CDметрики, логи, трассировкидашборд и оповещенияGit · Issue · Pull Request
Инфраструктуру вручную вы не поднимаете. Стартовый комплект DATA_PLATFORM_STARTER_PACK запускает все пять хранилищ одной командой и содержит синтетические наборы данных, скрипты сброса, заранее подготовленные неисправные случаи и шаблоны ADR.

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

СТК

Как оценивается

Оценка набирается по ходу года

  • Р1–Р3Занятия 1–12 · карта размещения данных, ADR, документный модуль, аналитическая витрина7 семестр
  • Р4–Р5Занятия 13–22 · матрица владения, политика кэша, outbox и publisher, идемпотентный потребитель7 семестр
  • Р6Занятия 23–33 · модель угроз, личности сервисов, секреты, аудит, четыре самостоятельные работы7 семестр
  • ПРЗанятие 33 · рубежная приёмка: сквозной поток и случайная карточка отказа. Метка semester-7-acceptedприёмка v0.5
  • Р7–Р9Занятия 34–48 · права во всех хранилищах, восстановление с измеренными RPO/RTO, работа с планами8 семестр
  • Р10–Р11Занятия 49–56 · интеграционные и контрактные тесты, конвейер, дашборд, разбор инцидента8 семестр
  • ЗЧЗанятие 57 · свой запрос на изменение: спланировать, сделать, протестировать, защититьзачёт

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

Мем про сессию
ДИФЗАЧЁТ
ОЦ

К концу года

Платформа, которую вы
поднимете заново

5 хранилищ под своими границами1 сквозной поток данных2 измеренных числа: RPO и RTO

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

Инженеры на совещании
ИТ