Продолжаем обсуждение глав из кабанчика («Высоконагруженные приложения» Мартина Клепманна). Подозреваю, что сейчас вы возможно не хотите это читать, но перед собесом вы вспомните обо мне и пойдёте перечитывать эти посты 😃

Вторую главу я бы назвала обзорной. В ней рассматриваются различные модели данных – то что мы обычно называем видами баз данных.

В книге приведен пример с профилем в LinkedIn. Предлагаю рассмотреть пример с маркетплейсом.

Возьмём таблицы:
- product для товаров
- user для пользователей
- order для заказов
- seller для продавцов.

Пользователь связан с заказами как «один-ко-многим». Продавец связан с товарами как «один-ко-многим». Заказы и товары связаны как «многие-ко-многим».

В реляционных БД легко поддерживать связи «один-ко-многим» и «многие-ко-многим» через внешние ключи на идентификаторы строк в другой таблице.

В случае документоориентированных моделей данные обычно хранятся в виде JSON. Тут встаёт вопрос, как лучше спроектировать связи. Например, мы можем хранить отдельные модели документов: товары и продавцы. Тогда у каждого товара будет ссылка на документ продавца.

Документоориентированные БД иногда называют бессхемными (schemaless) или неструктурированными. Более точным было бы название schema-on-read (схема при чтении). Этот подход удобен, когда данные разнородны. Например, характеристики товаров на маркетплейсах. У разных товаров могут быть совершенно разные характеристики. В подобных ситуациях схема может принести больше вреда, чем пользы, а неструктурированные документы окажутся намного более естественной моделью данных.

Реляционные БД реализуют подход schema-on-write (схема при записи). В этом случае у нас имеется явная схема, и база гарантирует, что все записываемые данные ей соответствуют.
Этот подход удобен, когда структура всех записей одинакова, например, данные в профиле пользователя.

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

Документоориентированные модели плохо поддерживают связь «многие-ко-многим». С помощью реляционной модели можно иметь дело с простыми случаями связей «многие-ко-многим». Если же таких взаимосвязей много, то на сцену выходят графовые базы данных.
Графы состоят из двух типов объектов: вершин и рёбер. В виде графа можно смоделировать множество типов данных. Типичные примеры:
- знакомства людей в социальных сетях
- веб-страницы и ссылки между ними
- дороги или железнодорожные сети.

В этих примерах все вершины графов представляют, по сути, одно и то же (людей, веб-страницы, перекрестки дорог). Однако в графе можно хранить различные типы объектов. Например, одна западная соцсеть поддерживает единый граф с множеством различных типов вершин и ребер. Вершины означают людей, местоположения, события, комментарии. Ребра указывают, какие люди являются друзьями, кто какой пост прокомментировал, кто какое мероприятие посетил и т. д.

В главе 2 были рассмотрены реляционные, документоориентированные и графовые БД. Не были рассмотрены такие виды noSQL БД, как ключ-значение и колоночные.
Интересный факт: noSQL сейчас расшифровываются как not only SQL.

Если говорить о моем опыте, то я много работала с реляционными БД, немного с noSQL (ElasticSearch, Redis, ClickHouse) и пока не сталкивалась на практике с графовыми.

#сисдиз #кабанчик