Настоящий конспект представляет собой подробный поминутный сценарий проведения занятия №06 «Типы моделей данных» с развернутой прямой речью преподавателя. Сценарий адаптирован для двух базовых регламентов:
«Здравствуйте, коллеги! Садитесь. Проверим явку и готовность рабочих станций. На прошлых парах мы с вами детально разобрались, что такое база данных, почему файловые структуры не выдерживают параллельной работы и как трехуровневая модель ANSI/SPARC разделяет представления пользователей от дисковых секторов.
Сегодня мы совершим фундаментальный шаг в профессию системного архитектора. Тема нашего занятия: «Типы моделей данных».
Представьте типичную ситуацию на собеседовании или в реальном проекте. Заказчик или тимлид говорит: «Давайте возьмем привычный PostgreSQL и сохраним туда абсолютно всё: профили клиентов, историю кликов на сайте за пять лет, граф друзей и кэш сессий». Младший разработчик согласится. Но опытный инженер скажет: «Подождите. При миллиарде кликов реляционная база рухнет на агрегациях, а граф друзей превратит обычный поиск в цепочку из десяти тяжелых JOIN, которая положит весь сервер».
Наша цель сегодня — досконально понять, какие математические модели данных существуют в природе, почему иерархические деревья и сетевые базы уступили место реляционной модели Эдгара Кодда, и в каких случаях современный архитектор обязан выбирать документоориентированную, графовую или колоночную NoSQL СУБД.
Работать мы будем с интерактивным рабочим листом, где каждый из вас проведет сравнительный анализ и защитит архитектурное решение для конкретного промышленного кейса. Оценка индивидуального продукта — строго по закрытой 4-балльной рубрике. Приступаем!».
«Начнем со строгого определения. Модель данных — это не просто табличка или файл. Это формальная математическая теория, которая включает три обязательных элемента:
1. Структурная часть: в каком виде данные логически существуют — в виде дерева, плоской таблицы, графа с ребрами или JSON-документа.
2. Манипуляционная часть: как мы их запрашиваем и модифицируем — пишем ли мы декларативный SQL-запрос или вручную двигаем курсор по цепочке указателей.
3. Целостная часть: правила, запрещающие базе превращаться в мусорную свалку (уникальность ключей, запрет висячих ссылок, проверка допустимых диапазонов).
Перенесемся в конец 1960-х годов. Появилась иерархическая модель (классический пример — СУБД IBM IMS для лунной программы «Аполлон»). Данные организованы как строгое генеалогическое дерево из сегментов. Корень — один. Каждый дочерний сегмент имеет строго одного родителя. Если нам нужно связать подразделение и сотрудников — всё отлично. Но что делать, если студент одновременно учится на двух факультетах или записан на пять курсов? Возникает отношение «многие-ко-многим». В иерархической модели это катастрофа: приходится физически копировать целые ветви данных, плодя чудовищную избыточность. А при удалении родителя (например, закрытии курса) СУБД автоматически стирала всех привязанных к нему студентов!
В ответ консорциум CODASYL предложил сетевую модель. Сеть — это произвольный ориентированный граф. Теперь у записи могло быть несколько владельцев (Owners). Проблема связей M:N решилась. Но возникла другая беда: навигационный доступ. Чтобы найти студента, программист на COBOL был обязан писать циклы, буквально шагая по цепочкам физических указателей в оперативной памяти: FIND FIRST, FIND NEXT. Если администратор менял разметку диска — программа падала и требовала полной перекомпиляции.
И вот в 1970 году британский ученый Эдгар Франк Кодд произвел революцию, опубликовав статью о реляционной модели данных (РМД). Кодд сказал: «Хватит заставлять программистов думать о физических указателях на диске! Данные — это отношения (таблицы), строки — это кортежи, столбцы — атрибуты. Доступ должен осуществляться через реляционную алгебру и логику предикатов».
Кодд сформулировал свои знаменитые 12 правил. Запомните ключевые: Правило 2 (гарантированный доступ) — к любому значению можно обратиться по связке „Таблица — Первичный ключ — Имя столбца“. И Правила 8 и 9 — физическая и логическая независимость данных. Вы можете заменить HDD на NVMe-диск, добавить индекс B-Tree, разбить таблицу — если вы написали SQL-запрос, он продолжит работать без изменения единого символа кода!
Но почему же тогда в 2010-х годах грянул взрыв NoSQL? Потому что интернет вырос до миллиардов пользователей. Появились данные без четкой структуры. И инженеры сформулировали парадигму Polyglot Persistence:
— Если у нас товары с непредсказуемыми характеристиками (у смартфона есть „мегапиксели“, а у кроссовок — „размер стельки“), реляционные таблицы захлебнутся в NULL-значениях. Здесь побеждает документная модель (MongoDB), где каждый товар — это гибкий иерархический JSON-документ.
— Если у нас социальная сеть, рекомендательный движок или банковский антифрод, где критически важно отследить цепочку связей „кто кому перевел деньги через 5 подставных лиц“, реляционный JOIN сдохнет на втором шаге. Здесь правит графовая модель (Neo4j) с безындексной смежностью: переход по связям занимает константное время $O(1)$.
— Если у нас миллиарды логов кликов пользователей интернет-магазина (кликстрим) и нужно моментально посчитать средний чек за месяц, строчные базы сканируют терабайты ненужных данных. Здесь царствует колоночная модель (ClickHouse), которая читает только один нужный столбец и сжимает однотипные данные в 10 раз.
— А если нам нужно за доли миллисекунды отдать корзину или проверить токен авторизации — берется модель ключ-значение (Redis), работающая прямо в ОЗУ.
И наконец, запомните закон распределенных систем — CAP-теорему Эрика Брюэра. Из трех свойств: Согласованность (C), Доступность (A) и Устойчивость к сетевому разделению (P) — в распределенной сети физически невозможно получить все три одновременно. Сетевые аварии неизбежны, поэтому $P$ обязательно присутствует. Выбор архитектора: либо CP (жертвуем доступностью, отдаем ошибку, но балансы в банке не расходятся — реляционный подход ACID), либо AP (сервис всегда отвечает клиенту, но данные на узлах могут временно различаться — NoSQL парадигма BASE с концепцией Eventual Consistency)».
«Внимание на экран. Давайте разберем слайды интерактивной презентации. Обратите внимание на слайд №15. Перед вами легендарный комикс Рэндалла Манро xkcd №327 под названием „Exploits of a Mom“, больше известный как мем про „Bobby Tables“.
Мама назвала сына именем: Robert'); DROP TABLE Students;--. Когда нерадивый школьный программист выполнил обычную строковую конкатенацию вместо параметризованного запроса, реляционная СУБД восприняла закрывающую кавычку и точку с запятой как конец команды и радостно стерла всю таблицу успеваемости за год. В чем мораль этого мема для системного архитектора? Модель данных и ядро СУБД строго требуют понимания уровней абстракции, типизации доменов и валидации. Если вы не понимаете, как устроена выбранная вами модель, любая система превратится в уязвимую катастрофу.
А теперь открываем интерактивный рабочий лист zanyatie.html на своих компьютерах. Заполните фамилию, имя и номер группы — поля должны быть реальными, никаких плейсхолдеров.
Распределяем 4 варианта:
— Вариант 1 (первый ряд): Банковский процессинг. Обоснуйте, почему здесь категорически необходима реляционная СУБД с транзакциями ACID и строгой ссылочной целостностью, и какие риски несет переход на eventual consistency.
— Вариант 2 (второй ряд): Социальная сеть. Сравните графовую СУБД Neo4j с реляционной схемой и объясните, почему безындексная смежность ребер спасает от гибели каскадных JOIN.
— Вариант 3 (третий ряд): Аналитическая витрина кликстрима. Докажите преимущество колоночной ClickHouse перед построчным PostgreSQL при расчете агрегатов по миллиардам строк.
— Вариант 4 (четвертый ряд): Каталог маркетплейса с тысячами разных типов товаров. Обоснуйте выбор документоориентированной MongoDB против нормализованных таблиц или антипаттерна EAV.
Все данные сохраняются автоматически в браузере. У вас 20 минут (в 60-мин регламенте — 15 минут). Я на связи, задавайте технические вопросы».
zanyatie.html, заполняют личные данные, переключаются на назначенный вариант, строят сравнительную матрицу, аргументируют выбор СУБД под кейс, описывают риски нештатных ситуаций и отвечают на вопросы самопроверки.
«Время вышло. Остановите ввод данных. Давайте заслушаем представителей каждого варианта.
Кто защитит Вариант 1? Верно: в банковском процессинге малейшая потеря денег при сбое сети недопустима, поэтому мы выбираем CP-режим и реляционную модель с двухфазным коммитом. Кто по Варианту 2? Абсолютно точно: в Neo4j связь физически записана в заголовке вершины, поэтому обход графа на 3 рукопожатия выполняется за 5 миллисекунд, в то время как реляционный SQL сканировал бы индексы таблицы из 50 миллионов строк.
Взгляните на экран: перед вами закрытая критериальная рубрика оценивания (максимум 4 балла):
— 2 балла: точность заполнения сравнительной матрицы моделей данных (структура, связи, транзакции, схема).
— 1 балл: инженерная аргументация выбора конкретной модели под кейс с разбором рисков сбоя.
— 1 балл: корректность выводов и ответов на блок самопроверки.
Проведите честную самооценку в рабочем листе, нажмите кнопку сохранения и экспортируйте итоговый документ в PDF для отправки в учебный кабинет.
О домашнем задании: В папке материалов расположен файл domashnee_zadanie.html. Обратите внимание на плашку: это резервное дистанционное задание. Те, кто присутствовал сегодня очно и успешно защитил рабочий лист, освобождены от него. Задание предназначено строго для обучающихся, пропустивших пару по уважительной причине, либо тех, кому требуется индивидуальная доработка. Срок сдачи — до следующего занятия.
Спасибо за отличную инженерную работу! Урок окончен».