Вы уже владеете SQL, проектированием реляционных баз, транзакциями, миграциями, слоем доступа к данным, HTTP-API, Git, Docker и тестированием. Эти навыки мы считаем входными и заново их не проходим.
входМДК.04.01 · 4 курс · 2026 / 2027
Технология разработки
и защиты баз данных
Выпускной курс. В течение года мы проектируем, собираем и эксплуатируем одну платформу данных: реляционный источник истины, две производные копии, кэш, брокер сообщений, контур защиты и восстановления.
Итоговый артефакт · DATA PLATFORM v1.0
Платформа данных, которую вы соберёте за два семестра
Точка на схеме — одно изменение данных: у заказа сменился статус. Приложение записывает изменение в PostgreSQL и в той же транзакции добавляет строку в таблицу outbox — очередь событий на публикацию. Publisher читает outbox и отправляет событие в RabbitMQ, откуда его независимо забирают два потребителя: первый обновляет документ в MongoDB, второй дописывает строку в ClickHouse. Redis в этой цепочке не участвует: в нём хранится только то, что можно потерять без последствий. Каждый раздел курса отвечает за свой участок схемы.
Зачем это на четвёртом курсе
Чем дисциплина отличается от курса баз данных
Реляционная база перестаёт быть всей системой: теперь это одна из пяти подсистем, и отвечает она только за исходные данные. Остальные четыре хранят производные копии. Отсюда вопросы, которых не возникает при одной базе: кто владеет записью, насколько копия отстала от оригинала, что подлежит восстановлению после сбоя и какие права выданы каждому сервису.
выходПланируемые результаты
Чему вы научитесь за год
Пять групп умений — их мы и проверяем на приёмке и на зачёте. Разделы курса, которые идут дальше, раскрывают каждую из них.
Подбираете систему под характер нагрузки и назначаете владельца каждой сущности
Пять технологий без разграничения ответственности
карта размещения + ADRДоставляете изменение в производные хранилища без потерь и дублей
Двойная запись, дубли и потерянные события
сквозной поток данныхВыдаёте минимальные права и подтверждаете отказ негативным тестом
Общие учётные записи, избыточные права, неучтённые копии
матрица доступаПоднимаете систему после сбоя, называете остаточную потерю и знаете предел нагрузки
Резервная копия, которую ни разу не разворачивали
измеренные RPO и RTOОформляете проверки так, что они переживают изменения кода и конфигурации
Ручная настройка, которую невозможно повторить
DATA PLATFORM v1.0Строка со знаком «!» — типичная ошибка, которую мы воспроизводим на занятиях намеренно: повреждаем резервную копию, выдаём избыточные права, теряем событие. Задача студента — обнаружить неисправность, устранить её и предъявить фактический вывод системы. Нижняя строка карточки — то, что сдаётся по этой группе умений.
Маршрут курса · 57 занятий · 11 разделов
Структура курса: 11 разделов, 57 занятий
Штриховкой отмечены четыре самостоятельные работы (занятия 24, 27, 30 и 32) — 8 часов из 114. Оставшиеся 106 часов аудиторные, это 53 пары. Седьмой семестр мы закрываем рубежной технической приёмкой платформы версии 0.5, восьмой — дифференцированным зачётом.
Разделы 1–2 · занятия 1–7 · 14 часов
Выбор хранилища и документная модель
7 парВы разворачиваете учебный стенд из чистого состояния, прогоняете первый smoke-тест и строите карту информационных потоков: где база, где кэш, где документное хранилище и аналитика, куда уходят выгрузки и в скольких местах лежит одна и та же запись.
карта потоков + реестр рисковДля пяти сценариев вы выбираете хранилище: реляционная база, документное хранилище, аналитическая витрина, кэш или брокер. Решение оформляете как ADR — короткую запись «выбрали это, потому что; отказались от того, потому что».
ADR-001 · границы системРазбираем документ и коллекцию, вложение против ссылки, схемную валидацию, индексы с замером плана explain до и после, конвейер агрегации и повторяемую миграцию документов из версии 1 в версию 2.
Раздел 3 · занятия 8–12 · 10 часов
ClickHouse: аналитика на потоке событий
5 парСравниваем колоночное хранение со строковым и разбираем, почему аналитическая витрина не может быть источником истины. Дальше группа согласует набор продуктовых событий.
контракт событий v1Разбираем семейство MergeTree, ключ сортировки и разбиение на партиции. Одну и ту же таблицу вы создаёте в двух вариантах — а разницу между ними видно на замере типовых запросов.
ADR-003 · DDL и замерыВы настраиваете пакетную вставку событий с контролем качества входных данных — вместе с заранее подготовленными некорректными записями. Затем строите три продуктовые метрики, материализованное представление и политику TTL.
витрина + отчёт качестваАналитическую таблицу вы удаляете целиком и собираете заново из эталонного источника. Как раз этим производные данные и отличаются от источника истины: их допустимо потерять.
скрипт rebuild + сверкаРазделы 4–5 · занятия 13–22 · 20 часов
Как изменение доходит до всех копий
10 пар · ядро курсаЗа каждой сущностью вы закрепляете единственного владельца, а за каждой копией — источник, из которого её можно восстановить. Redis подключаете так, чтобы очистка кэша не рушила состояние системы, и проверяете это запуском с холодного старта.
матрица владения · политика кэшаСначала мы воспроизводим рассогласование: в PostgreSQL изменение записано, а в производной копии его нет. Затем вы пишете скрипт сверки и переносите публикацию события в таблицу outbox — она заполняется в той же транзакции, что и само изменение.
скрипт сверки · контракт outboxРазбираем обменники, очереди и ключи маршрутизации, подтверждения публикации и обработки, политику повторов и очередь необработанных сообщений, идемпотентного потребителя. Раздел закрываем сквозным прогоном события и восстановлением одного потребителя с нуля.
сквозной поток с trace idРазделы 6–7 · занятия 23–38 · 32 часа · самый большой блок
Защита платформы и управление доступом
16 парОпределяем, какие данные представляют ценность, кто к ним обращается и где проходит граница доверия. Дальше вы выдаёте каждому сервису отдельную учётную запись, выносите секреты из конфигурационных файлов в защищённое хранилище и переводите соединения на TLS.
модель угроз · карта личностейРазбираем, где нужно шифрование, а где хватает маскирования. Один пользовательский запрос вы прослеживаете от API до обоих потребителей. Раздел закрывает рубежная приёмка платформы версии 0.5.
DATA PLATFORM v0.5Вы настраиваете роли и права GRANT в PostgreSQL, построчный доступ для разных арендаторов, ограниченные права потребителей MongoDB и ClickHouse, виртуальные хосты RabbitMQ и пространства ключей Redis.
Фактические права вы сверяете с матрицей доступа. Затем мы намеренно вносим в конфигурацию избыточное разрешение — и автоматическая проверка обязана поймать его до релиза.
регрессионный набор
Раздел 8 · занятия 39–43 · 10 часов
Резервное копирование и восстановление
5 парДля каждого компонента вы решаете, что копировать, а что восстанавливать пересозданием. Здесь же появляются два числа: допустимый объём потери данных (RPO) и допустимое время простоя (RTO), а с ними — порядок восстановления компонентов.
матрица восстановления · RPO/RTOВы делаете базовую копию, настраиваете архив журнала WAL и восстанавливаете базу на момент перед ошибочным изменением. Дальше — MongoDB со сверкой контрольных выборок и ClickHouse: резервной копией либо повторным проигрыванием событий.
подтверждения восстановленияИз чистого окружения вы поднимаете всю цепочку: база, документная модель, аналитическая витрина, топология брокера, прогрев кэша и обработка накопившихся событий outbox. Остаточную потерю и порядок восстановления записываете в runbook.
runbook · измеренные RPO/RTOРезервную копию, которую ни разу не разворачивали, мы считаем непроверенной — поэтому каждое копирование в разделе вы подтверждаете восстановлением. Всё на синтетических данных.

Раздел 9 · занятия 44–48 · 10 часов
Производительность, блокировки и пределы нагрузки
5 парДо всяких правок вы замеряете три критичные операции: задержку, пропускную способность, долю ошибок, а также p50 и p95. Без этой точки отсчёта «стало быстрее» проверить нечем.
стенд замера + сырые числаРазбираем план выполнения запроса: полное сканирование против поиска по индексу, обращение к таблице за недостающими полями, роль статистики. Медленный запрос вы находите, правите и замеряете эффект тем же стендом.
планы до и послеРазбираем уровни изоляции, длительность блокировки и цепочку ожидания. Взаимоблокировку вы вызываете намеренно, а потом устраняете причину, а не внешнее проявление.
граф дедлока + исправлениеВы проводите диагностику MongoDB и ClickHouse, затем настраиваете пулы соединений, таймауты, ограничение выборки у потребителя и контроль отставания очереди. Нагрузочный тест показывает границу, за которой система деградирует управляемо.
отчёт нагрузочного теста
Разделы 10–11 · занятия 49–57 · 18 часов · финал
Тесты, наблюдаемость и передача платформы
9 парВы собираете одноразовое окружение с настоящими сервисами вместо заглушек. Дальше разбираем совместимые миграции схемы, документов и контракта событий — такие, что не требуют одновременного релиза всех компонентов, — контрактные тесты и сборочный конвейер с проверкой прав и поиском секретов в коде.
интеграционный набор + pipelineМетрики, журналы и трассировки вы связываете с инструкциями по реагированию, задаёте целевые показатели и три проверенных оповещения. Затем расследуете подготовленный сбой, причина которого заранее неизвестна.
дашборд · отчёт об инцидентеПлатформу вы поднимаете из чистого состояния, а преподаватель выдаёт случайную карточку отказа. На зачёте каждый получает свой запрос на изменение, реализует его и сопровождает обязательным тестом на отказ.
дифференцированный зачётРеляционный контур курса
Часть логики переносится внутрь базы
Источник истины в курсе — PostgreSQL. В отличие от прошлых курсов, база здесь не только хранит данные: триггер, функция и расширение выполняются на её стороне. Ниже — как раз механизм из занятия 16, записанный средствами PostgreSQL.
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 не знает, и событие не потеряется, даже если приложение упадёт сразу после записи.
Реляционный контур · чем PostgreSQL расширяется
Свои типы и подключаемые модули
-- перечисление: значения проверяет сама база 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;
crypt(), digest().CREATE EXTENSION и так же удаляется.Здесь важен не перечень модулей. Систему типов PostgreSQL можно дополнить своими типами и доменами, и тогда корректность значения проверяет сама база, а не каждый обработчик по отдельности. Расширение добавляет готовый набор функций, операторов и индексов одной командой.
Как проходит пара
Как устроены 90 минут
С чем работаем
Стек курса
Если какой-то сервис недоступен, занятие проводим на локальном стенде по тому же сценарию: подготовленные журналы, планы запросов и резервные копии лежат в комплекте.
Как оценивается
Оценка набирается по ходу года
- Р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 · свой запрос на изменение: спланировать, сделать, протестировать, защититьзачёт
На зачёте мы оцениваем индивидуальный вклад: вы вносите изменение в существующую платформу и обязательно сопровождаете его тестом на отказ.

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