1 of 28

Понятие модели данных.

Типы моделей данных

Лекция 4

2 of 28

Что такое модель данных

3 of 28

Назначение

Обеспечивает единое представление данных
Упрощает хранение и доступ (поиск, обновление, удаление).
Помогает обеспечить целостность, нормализацию, минимизацию дублирования.
Влияет на производительность и масштабируемость.

4 of 28

История

Историческая эволюция

Первые модели — иерархическая (hierarchical) и сетевая (network) — появились в 1960-70-х годах. Эти модели справлялись с задачей тогда, когда вычислительные ресурсы были ограничены, и данные часто имели естественную иерархию или фиксированные связи [1-2]
Позже появилась реляционная модель (Edgar F. Codd, 1970-е), ставшая доминантной для большинства бизнес-приложений.
Затем появились модели NoSQL: документо-ориентированные, ключ-значение, колоночные, графовые, а также гибридные / мульти-модели.

А теперь давайте рассмотрим разные типы моделей, для некоторых из них увидим реальные кейсы использования их в жизни

5 of 28

1. Иерархическая (Hierarchical)

6 of 28

1. Иерархическая (Hierarchical)

Предсказуемость структуры и высокая эффективность навигации
Простота проектирования и понимания
Относительно высокая целостность (data integrity)

Жёсткая структура, низкая гибкость
Избыточность/дублирование
Ограниченность в запросах
Трудности при изменении структуры и поддержке

Плюсы

Минусы

Плюсы:

Предсказуемость структуры и высокая эффективность навигации. Так как связь предопределена, пути к данным “корень → потомок” известны заранее, запросы, которые проходят по этим путям - очень быстрые.
Простота проектирования и понимания. Для систем, где данные естественно иерархичны (например, каталоги, файловые системы, организационные структуры) - почти “отображение реального мира”.
Относительно высокая целостность (data integrity). Жёсткая связь “родитель-потомок” помогает исключить “осиротевшие” записи, легко управлять зависимостями.

Минусы:

Жёсткая структура, низкая гибкость. Если нужно изменить структуру - например, добавить связь “многие ко многим” или разрешить, чтобы один узел имел несколько родителей, - обычно всё усложняется, возможно потребуется реорганизация данных.
Избыточность/дублирование. Если один “потомок” должен принадлежать к двум “родителям”, то либо нужно дублировать, либо создавать искусственные узлы. Это приводит к расходу пространства, усложнению поддержки.
Ограниченность в запросах. Запросы вне “иерархического пути” (например, поиск всех элементов, удовлетворяющих условию без знания пути) сложны или неэффективны. Например, чтобы найти “все сотрудники старше 30 лет вне зависимости от отдела”, может потребоваться просмотреть много узлов.
Трудности при изменении структуры и поддержке. Добавление новых узлов, изменение связей - всё это может требовать перепроектирования или модификации клиентского кода, приложений.

7 of 28

1. Иерархическая (Hierarchical). Пример

“выведи все транзакции по счету клиента”

“найти все транзакции больше 10 000$ за месяц по всем клиентам”

Кейс: банковские системы 70-х и IBM IMS

Банк использует IBM IMS (Information Management System) для хранения данных о счетах и транзакциях.
У каждого клиента есть счета (родитель → потомок), у каждого счёта - список транзакций.
Для обработки запросов типа “выведи все транзакции по счету клиента” (CLICK) иерархия идеально подходит: (CLICK) быстрый спуск сверху вниз.
Проблема: когда потребовалось строить отчёты “найти все транзакции больше 10 000$ за месяц по всем клиентам” (CLICK), оказалось, (CLICK) что запросы приходится гонять по всей иерархии. Это дорого и сложно.
Вывод: идеально для транзакционных задач, больно для аналитики.

8 of 28

2. Сетевая (Network)

9 of 28

2. Сетевая (Network)

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

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

Плюсы

Минусы

10 of 28

3. Реляционная (Relational)

11 of 28

3. Реляционная (Relational)

Сила SQL, гибкость запросов
Нормализация и контроль избыточности
ACID-свойства (транзакции, согласованность)
Много зрелых инструментов, экосистема

Жесткость схемы (schema rigidity)
Неэффективность с полуструктурированными или неструктурированными данными
Проблемы масштабирования горизонтально
Производительность с очень большими данными и при сложных связях

Плюсы

Минусы

Плюсы:

Сила SQL, гибкость запросов. Можно делать составные запросы (JOIN), агрегации, фильтрации, сортировки, подзапросы. Очень мощный и выразительный язык запросов.
Нормализация и контроль избыточности. Хорошо проработанные схемы позволяют минимизировать дублирование данных, обеспечивают целостность (constraints, foreign keys).
ACID-свойства (транзакции, согласованность). Это важно для систем, где важна надежность: банковские, финансовые, учетные системы.
Много зрелых инструментов, экосистема. Много СУБД, инструментов мониторинга, резервного копирования, безопасности и др.

Минусы:

Жесткость схемы (schema rigidity). Если требования часто меняются, например, появляются новые атрибуты, вложенные структуры, необходимо изменять схему, миграции — это часто больно.
Неэффективность с полуструктурированными или неструктурированными данными. Например, вложенные документы (JSON), массивы, blob’ы - обработка может быть неэффективной.
Проблемы масштабирования горизонтально. Реляционные БД традиционно хорошо масштабируются вертикально (лучше сервер), но при распределенных системах с огромными объемами данных множество JOIN’ов, распределенное хранение усложняют работу.
Производительность с очень большими данными и при сложных связях. Если таблиц много, связи сложные, запросы содержат много JOIN’ов — могут быть медленнее, особенно в распределенных БД.

12 of 28

3. Реляционная (Relational). Пример

в начале своей работы

когда пользователей стало очень много

+

NoSQL

+

Кейс: Amazon в ранние годы

Amazon в 90-е начал как интернет-магазин с реляционной БД (Oracle).
Таблицы: пользователи, товары, заказы, платежи. Всё чётко, ACID - критично для финансовых операций (ACID — это набор из четырёх свойств (Атомарность, Согласованность, Изоляция, Долговечность)).
Но когда ассортимент вырос до миллионов товаров и миллионы пользователей делали заказы одновременно, JOIN’ы и нагрузка на транзакции начали тормозить.
В итоге Amazon частично мигрировал на собственные NoSQL-решения (DynamoDB) для гибкости и масштабируемости, оставив SQL там, где транзакции действительно критичны.
Вывод: реляционные БД отлично работают для структурированных транзакций, но плохо масштабируются в условиях Big Data.

13 of 28

4. Документо-ориентированная (Document-oriented NoSQL)

14 of 28

4. Документо-ориентированная (Document-oriented NoSQL)

Гибкая схема (schema flexibility)
Хранение вложенных структур естественно
Масштабируемость горизонтально (sharding, репликация)
Быстрая разработка / быстрые итерации

Меньше гарантий целостности и транзакций
Избыточность данных
Неэффективность при сложных связях / агрегациях
Сложности при анализе / BI / отчетности

Плюсы

Минусы

Плюсы:

Гибкая схема (schema flexibility) — документы могут иметь разные поля, вложенность. Это даёт быстрее адаптироваться к изменяющимся требованиям.
Хранение вложенных структур естественно. JSON-документы удобно представляют вложенные данные, массивы, объекты, легко читать и модифицировать.
Масштабируемость горизонтально (sharding, репликация). Большинство NoSQL/документных БД построены с учётом распределённых узлов. Когда база растёт, легко добавить ноды.
Быстрая разработка / быстрые итерации. Если требования не зафиксированы, можно начинать с небольшого набора полей, добавлять по мере необходимости, не делая сложных миграций схемы.

Минусы:

Меньше гарантий целостности и транзакций. Многие документ-ориентированные СУБД либо не поддерживают ACID или делают это частично, либо “в стиле eventual consistency”. Это может быть критично для финансовых систем и др.
Избыточность данных. Если вложенность большая или документ включает вложенные документы, может быть дублирование информации, особенно если связи хранятся эквивалентно “из ссылок”, что может усложнять обновление.
Неэффективность при сложных связях / агрегациях. Когда требуется JOIN-подобная логика или анализ данных, документы могут потребовать много “разворачивания” или дублирования. Это может быть медленнее, чем реляционные модели, при сложных пересечениях данных.
Сложности при анализе / BI / отчетности. Если документы сильно различаются по структуре, тяжело делать отчёты, визуализации, агрегировать по полям, которых может не быть в документах.

15 of 28

4. Документо-ориентированная. Пример

Хранение данных о пользователях

Построение отчета по пользователям

Кейс: eBay и MongoDB

На eBay для хранения данных о пользователях и их профилях стали использовать MongoDB.
Документы позволяли легко хранить разные структуры профилей (у одних пользователей были фото, у других - соцсети, у третьих - отзывы).
Но когда потребовалось построить отчёт “среднее количество фотографий в профиле по всем пользователям” → пришлось писать сложные агрегации, которые в реляционной модели решались простым JOIN + COUNT.
Вывод: удобно хранить “живые” документы, неудобно для аналитики.

16 of 28

5. Модель ключ-значение (Key-Value Store)

17 of 28

5. Модель ключ-значение (Key-Value Store)

высокая производительность,
масштабируемость,
простота

не подходит, если нужно сложные запросы, связи между объектами, агрегации и т.д.

Плюсы

Минусы

18 of 28

5. Модель ключ-значение. Пример

Instagram использует Redis для кэширования ленты.

Лента пользователя хранится как ключ (user_id) - значение (json с постами).

Запрос “дай последнюю ленту” - это мгновенное обращение к Redis.

Но Redis - это key-value: если нужно сделать сложный запрос “найти все посты с хэштегом #AI у всех пользователей”, то это невозможно без отдельной индексации.

Ключ-значение идеально для кэшей и быстрых lookup, но не для сложных поисковых задач

19 of 28

6. Column-Family / Wide-Column Stores

20 of 28

6. Column-Family / Wide-Column Stores

Оптимизированы для аналитики и агрегирования
Хороши для выполнения запросов, в которых мало столбцов, но много строк
Масштабируемость

Плохо подходят для операций с большим количеством insert/update/ delete строк; особенно если они касаются множества столбцов или строк
Сложнее поддерживать связи / JOIN’ы
Сложность при изменении схемы

Плюсы

Минусы

Плюсы:

Оптимизированы для аналитики и агрегирования. Хранение по столбцам позволяет выбирать только нужные столбцы, что экономит I/O.
Хороши для выполнения запросов, которые касаются небольшого числа столбцов но большого числа строк (типичные OLAP-запросы).
Масштабируемость. Часто колоночные СУБД поддерживают распределение данных по узлам.

Минусы:

Плохо подходят для транзакционных нагрузок с большим количеством insert/update/ delete строк; особенно если операции касаются множества столбцов или строк.
Сложнее поддерживать связи / JOIN’ы: объединения между большими таблицами могут быть медленными.
Сложность при изменении схемы: добавление столбцов, распределение данных, переиндексация — могут быть затратными.

21 of 28

6. Column-Family / Wide-Column Stores. Пример

У YouTube - терабайты логов просмотров.

Важно быстро считать статистику: сколько раз ролик посмотрели за день, какие страны лидируют и т.д.

В реляционной БД на строках пришлось бы читать все данные.

В Bigtable данные хранятся по колонкам, и когда нужно только поле “views” или “country”, то читается лишь часть таблицы - это очень быстро

Если YouTube хочет удалить все просмотры от определенного пользователя (например, по GDPR), то это будет сложнее, потому что данные “размазаны” по колонкам.

Колоночные БД — супер для аналитики и отчетов, но не для пользовательских транзакций.

Кейс: YouTube и Google Bigtable

У YouTube — терабайты логов просмотров.
Важно быстро считать статистику: сколько раз ролик посмотрели за день, какие страны лидируют и т.д.
В реляционной БД на строках пришлось бы читать ВСЕ данные.
В Bigtable данные хранятся по колонкам, и когда нужно только поле “views” или “country” — читается лишь часть таблицы → очень быстро.
Минус: если YouTube хочет удалить все просмотры от определенного пользователя (например, по GDPR) — это сложнее, потому что данные “размазаны” по колонкам.
Вывод: колоночные БД — супер для аналитики и отчетов, но не для пользовательских транзакций.

22 of 28

7. Графовая модель

23 of 28

7. Графовая модель

Естественное представление сложных сетевых/реляционных структур
Запросы связей (traversal) быстрые
Гибкость при усложнении связей

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

Плюсы

Минусы

Плюсы:

Естественное представление сложных сетевых/реляционных структур. Например, социальные сети, рекомендации, пути, связи между сущностями, когда каждый объект может быть связан с множеством других.
Запросы связей (traversal) быстрые, особенно когда база оптимизирована под графовые операции: узлы + ребра.
Гибкость при усложнении связей. Можно динамически добавлять новые виды связей, новые свойства к ним.

Минусы:

Сложность масштабирования. Многие графовые базы данных плохо масштабируются горизонтально для очень больших графов или маршрутов, особенно когда запросы требуют глобального подсчёта.
Запросы и индексация усложняются: traversal может стать дорогим, если граф глубоко вложенный или связи многочисленны.
Меньше зрелых стандартов/инструментов по сравнению с реляционными; средств для анализа часто меньше.

24 of 28

7. Графовая модель. Пример

Пример: у пользователя миллиарды пользователей, и нужно мгновенно ответить: “кто из друзей его друзей видел этот пост?”.

В реляционной БД это JOIN таблицы “пользователи - друзья” на миллионы строк - это очень дорого.

В графовой базе (Neo4j) каждая связь “друг” - это ребра графа, переходы “user - friend - friend” выполняются очень быстро.

Когда граф стал огромным (миллиарды рёбер), масштабирование оказалось непростым: traversal на 4-5 шагов глубже начинает занимать секунды.

Графовые БД - лучшие для социальных сетей и рекомендаций, но плохо масштабируются в ширину.

Кейс: Facebook и Neo4j (соцсети)

Представь: у тебя миллиарды пользователей, и нужно мгновенно ответить: “кто из друзей твоих друзей видел этот пост?”.
В реляционной БД это JOIN таблицы “пользователи ↔ друзья” на миллионы строк → адски дорого.
В графовой базе (Neo4j) каждая связь “друг” - это рёбра графа, переходы “user → friend → friend” выполняются очень быстро.
Проблема: когда граф стал огромным (миллиарды рёбер), масштабирование оказалось непростым: traversal на 4-5 шагов глубже начинает занимать секунды.
Вывод: графовые БД - лучшие для социальных сетей и рекомендаций, но плохо масштабируются в ширину.

25 of 28

8. Модель Entity-Attribute-Value (EAV)

26 of 28

8. Модель Entity-Attribute-Value (EAV)

экономия места,
гибкость, когда заранее неизвестно, какие атрибуты нужны

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

Плюсы

Минусы

27 of 28

Интересные факты

Некоторые современные базы данных построены гибридно: они совмещают модели (PostgreSQL поддерживает JSON-документы внутри реляционных таблиц; есть “multi-model” СУБД).
Динамичные данные - документно-ориентированные или модели ключ-значение; для отчетов - извлечение данных в реляционный формат или ETL-конвейеры.
В Big Data часто встречаются колоночные базы данных и системы, использующие “схему-на-чтение” (schema-on-read) или гибкие схемы - потому что заранее неизвестно, что именно придет.

Некоторые современные базы данных построены гибридно: они совмещают модели - например, PostgreSQL поддерживает JSON-документы внутри реляционных таблиц; есть “multi-model” СУБД.

Когда данные очень динамичны, часто используют документно-ориентированные или ключ-значение модели, но при необходимости построить отчеты / аналитику / отчетность, может потребоваться извлечение данных в реляционный формат или ETL-конвейеры.�—--�Что такое ETL?�ETL = Extract → Transform → Load.

Extract — извлечение данных из источников (БД, API, файлов).

Transform — очистка, нормализация, преобразование (например, даты к единому формату, валюты к одной системе).

Load — загрузка в хранилище данных (обычно в реляционную БД или Data Warehouse).

ETL-конвейер = последовательность шагов, которые автоматически выполняют эту работу.

Сегодня часто говорят ещё ELT (Extract → Load → Transform), где сначала всё грузится в “озеро данных” (Data Lake), а потом обрабатывается под конкретный запрос.�—--�

В Big Data часто встречаются колоночные базы данных и системы, использующие “схему-на-чтение” (schema-on-read) или гибкие схемы - потому что заранее неизвестно, что именно придет.

—--�Что значит “схема-на-чтение” (schema-on-read) или гибкие схемы

Это принцип хранения данных в Big Data.

Schema-on-write (схема-на-запись)

→ Вы заранее строго определяете структуру данных (схему таблицы) перед записью.

→ Пример: реляционные БД. Ты должен сказать: “В этой таблице есть поле user_id (int), name (varchar), age (int)”. Если формат не совпадает — ошибка.

Schema-on-read (схема-на-чтение)

→ Данные можно хранить “как есть” (сырые JSON, CSV, Parquet и т.п.).

→ Когда вы их читаете, тогда и определяете схему (какие поля есть, какой тип у age).

→ Пример: Hadoop, Spark, Amazon S3 Data Lake.

Зачем это нужно в Big Data?

Потому что часто мы не знаем, какие данные придут завтра. Например, IoT-сенсор может прислать новые параметры, которых не было вчера. В реляционной БД пришлось бы менять схему, а в Data Lake просто добавляется новый ключ в JSON.

28 of 28

Понятие модели данных.

Типы моделей данных

Лекция 4