Вариант 1: Финансовый транзакционный процессинг банка
Описание кейса: Разработка ядра автоматизированной банковской системы (АБС). Сервис выполняет межбанковские переводы, начисление процентов по депозитам и блокировку средств по картам. Критическое требование бизнеса: баланс счетов дебета и кредита должен сходиться с абсолютной математической точностью (двойная запись). Потеря транзакции или промежуточное чтение незавершенной проводки недопустимы.
Часть 1. Сравнительная матрица моделей данных (2 балла)
Сравните реляционную модель данных (PostgreSQL / Oracle) и распределенную нереляционную NoSQL модель с гарантией Eventual Consistency.
| Критерий сравнения |
Реляционная СУБД (PostgreSQL) |
NoSQL со слабой согласованностью |
| Транзакционные гарантии (ACID vs BASE) |
|
|
| Ограничения целостности и связи |
|
|
| Позиционирование по CAP-теореме |
|
|
Часть 2. Обоснование выбора архитектуры и анализ рисков (1 балл)
Почему для транзакционного процессинга банка выбрана реляционная модель с репликацией? Смоделируйте финансовую катастрофу, которая произойдет, если банк применит модель Eventual Consistency (BASE) при сетевом сбое.
Часть 3. Самопроверка и вывод (1 балл)
Какое из 12 правил Кодда гарантирует, что ограничения баланса счетов контролируются ядром СУБД, а не прикладным кодом программиста?
Вариант 2: Социальная сеть с динамическим графом связей
Описание кейса: Проектирование модуля рекомендаций друзей и поиска общих контактов («друзья друзей через 2–4 рукопожатия») в масштабе социальной платформы на 30 миллионов активных пользователей. Пользователи объединяются в сообщества, ставят отметки и имеют сотни связей с другими профилями.
Часть 1. Сравнительная матрица моделей данных (2 балла)
Сравните реляционную модель данных (с таблицей-связкой) и графовую модель данных (Neo4j / Property Graph).
| Критерий сравнения |
Реляционная модель (таблицы + JOIN) |
Графовая модель (Neo4j, Cypher) |
| Структура хранения связей |
|
|
| Вычислительная сложность обхода графа |
|
|
| Язык запросов и выразительность |
|
|
Часть 2. Обоснование выбора архитектуры и анализ рисков (1 балл)
В чем заключается концепция безындексной смежности (index-free adjacency) в графовой СУБД, и почему реляционная СУБД испытывает экспоненциальное падение скорости при поиске связей глубже 3 уровней?
Часть 3. Самопроверка и вывод (1 балл)
С какими трудностями сталкивается графовая база данных при необходимости горизонтального шардирования на десятки физических серверов?
Вариант 3: Аналитическая витрина кликстрима интернет-магазина
Описание кейса: Сбор и обработка потока событий пользовательской активности (кликстрим): просмотры страниц, клики, добавления в корзину, скроллинг карточек товаров. Нагрузка: 500 миллионов событий в сутки. Задачи аналитиков: интерактивные дашборды, расчет конверсий, воронки продаж и группировки по временным срезам в реальном времени.
Часть 1. Сравнительная матрица моделей данных (2 балла)
Сравните классическую строчную реляционную модель (PostgreSQL) и колоночную модель данных (ClickHouse).
| Критерий сравнения |
Строчная СУБД (OLTP, PostgreSQL) |
Колоночная СУБД (OLAP, ClickHouse) |
| Физическое размещение на накопителе |
|
|
| Коэффициент сжатия и дисковый ввод-вывод |
|
|
| Эффективность агрегаций (SUM, COUNT) |
|
|
Часть 2. Обоснование выбора архитектуры и анализ рисков (1 балл)
Почему колоночная база данных ClickHouse на несколько порядков опережает PostgreSQL в аналитических агрегациях, но абсолютно не подходит для проведения классических банковских транзакций и точечных UPDATE?
Часть 3. Самопроверка и вывод (1 балл)
К какому полюсу компромисса CAP-теоремы (CP или AP) логично отнести витрину кликстрима, и почему временная потеря одного клика не является критической аварией?
Вариант 4: Каталог товаров маркетплейса с произвольными свойствами
Описание кейса: Разработка каталога крупного маркетплейса, содержащего более 5 миллионов наименований в 2 000 категориях. У каждой категории абсолютно уникальный состав характеристик: у смартфонов — диагональ экрана и частота процессора, у одежды — состав ткани и размер, у автомобильных шин — посадочный диаметр и индекс нагрузки. Каждую неделю появляются новые категории товаров.
Часть 1. Сравнительная матрица моделей данных (2 балла)
Сравните жесткую реляционную модель (включая антипаттерн EAV) и документоориентированную модель данных (MongoDB / JSON).
| Критерий сравнения |
Реляционная модель (жесткая схема / EAV) |
Документная NoSQL (MongoDB / BSON) |
| Гибкость схемы (Schema-on-write vs read) |
|
|
| Представление вложенных характеристик |
|
|
| Сложность добавления новой категории товаров |
|
|
Часть 2. Обоснование выбора архитектуры и анализ рисков (1 балл)
Почему использование реляционной модели для разнородного каталога приводит либо к разреженной таблице с сотнями NULL-полей, либо к антипаттерну EAV (Entity-Attribute-Value)? Каковы преимущества MongoDB в этом сценарии?
Часть 3. Самопроверка и вывод (1 балл)
Какой риск несет денормализация данных (встраивание цен и остатков прямо в документ товара) при одновременном оформлении заказов сотнями покупателей?