1 of 37

Модели данных

Проектирование и разработка распределенных программных систем, лекция 3

2 of 37

Модель данных

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

3 of 37

Модели на разных слоях

  • Приложение: модель реального мира в объектах и структурах данных + API для работы с ними.
  • Хранение: JSON, XML, таблицы, графы.
  • Низкоуровневое хранение: представление данных в виде байтов в памяти, на диске и в сети.
  • Железо: представление байтов в виде тока, света, магнитного поля и т. д.

4 of 37

SQL и NoSQL

5 of 37

Реляционная модель

  • Появилась в 1970-е
  • Самая распространенная на текущий момент
  • Реализуется в MySQL, PostgreSQL, Microsoft SQL Server, Oracle и т.д.

6 of 37

Реляционная модель

  • Данные организованы в отношения (в SQL — таблицы)
  • Каждое отношение — множество кортежей (в SQL — записей)
  • Каждый кортеж — список значений атрибутов (в SQL — колонок)

7 of 37

Реляционная модель

8 of 37

Реляционная модель

Данные делятся на несколько таблиц и хранятся в нормализованном виде.

9 of 37

Реляционная модель

10 of 37

Объектно-реляционное несоответствие

11 of 37

Объектно-реляционное несоответствие

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

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

12 of 37

13 of 37

Проблемы

  • Сложно преобразовать одну модель в другую
  • Снижается эффективность работы с БД
  • Нужно думать в двух моделях

14 of 37

{

"user_id": 251,

"first_name": "Bill",

"last_name": "Gates",

"summary": "Co-chair of the Bill & Melinda Gates... Active blogger.",

"region_id": "us:91",

"industry_id": 131,

"photo_url": "/p/7/000/253/05b/308dd6e.jpg",

"positions": [

{"job_title": "Co-chair", "organization": "Bill & Melinda Gates Foundation"},

{"job_title": "Co-founder, Chairman", "organization": "Microsoft"}

],

"education": [

{"school_name": "Harvard University", "start": 1973, "end": 1975},

{"school_name": "Lakeside School, Seattle", "start": null, "end": null}

],

"contact_info": {

"blog": "http://thegatesnotes.com",

"twitter": "http://twitter.com/BillGates"

}

}

​

15 of 37

Документоориентированные БД

  • MongoDB
  • CouchDB
  • RethinkDB
  • ElasticSearch

16 of 37

Древовидная структура

17 of 37

Гибкий формат (schemaless)

Реляционные БД: schema-on-write (данные валидируются в момент записи)

Документоориентированные БД: schema-on-read (данные интерпретируются в момент чтения)

18 of 37

Гибкий формат (schemaless)

Удобно при миграции схемы БД

19 of 37

{

"user_id": 251,

"first_name": "Bill",

"last_name": "Gates",

"summary": "Co-chair of the Bill & Melinda Gates... Active blogger.",

"region_id": "us:91",

"industry_id": 131,

"photo_url": "/p/7/000/253/05b/308dd6e.jpg",

"positions": [

{"job_title": "Co-chair", "organization": "Bill & Melinda Gates Foundation"},

{"job_title": "Co-founder, Chairman", "organization": "Microsoft"}

],

"education": [

{"school_name": "Harvard University", "start": 1973, "end": 1975},

{"school_name": "Lakeside School, Seattle", "start": null, "end": null}

],

"contact_info": {

"blog": "http://thegatesnotes.com",

"twitter": "http://twitter.com/BillGates"

}

}

​

20 of 37

Почему ID, а не названия?

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

21 of 37

Связи «многие-к-одному»

Связи «многие-к-одному» плохо вписываются в документоориентированную модель.

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

22 of 37

Какая модель удобнее?

23 of 37

Зависит от приложения

24 of 37

Можно использовать обе

25 of 37

Сближение моделей

PostgreSQL и MySQL поддерживают колонки в JSON.

Документоориентированные БД внедряют поддержку джойнов.

26 of 37

Глубокие связи «многие-ко-многим»

27 of 37

Графы

  • Друзья в соцсетях
  • Ссылки между веб-страницами
  • Маршруты (дороги, железные дороги, аэропорты)
  • Разнородные графы (Фейсбук)

28 of 37

Графовая модель данных

  • Вершины (сущности)
  • Ребра (связи)

29 of 37

Графовые БД

  • Neo4j
  • Datomic
  • Titan
  • InfiniteGraph
  • AlegroGraph

30 of 37

Обход графа на SQL

WITH RECURSIVE [cte_name] (column, ...) AS (

[non-recursive_term]

UNION ALL

[recursive_term])

SELECT ... FROM [cte_name];

​

31 of 37

БД «ключ-значение»

Dictionary как отдельный сервис.

Кеширование, хранение значений для быстрого извлечения.

32 of 37

БД «ключ-значение»

  • Redis
  • Memcached
  • Riak

33 of 37

Колоночные БД

Та же модель данных, что и у реляционных БД.

Данные при хранении сгруппированы не по строкам, а по столбцам.

34 of 37

Колоночные БД

  • ClickHouse
  • Vertica

35 of 37

36 of 37

Объектные хранилища

  • Amazon S3
  • MinIO

37 of 37

Ссылки

NoSQL – коротко о главном: https://habr.com/ru/company/oleg-bunin/blog/319052/

Мартин Клеппман. Высоконагруженные приложения. Программирование, масштабирование, поддержка. Глава 2

CQRS documents: https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf