Pull to refresh

Comments 45

Дополнения по Microsoft SQL Server:
— основная реализация документ-ориентированной модели не JSON, а XML (с версии 2005): нативное хранение, индексация, язык запросов XQuery, поддержка XSD-схем документов. JSON действительно введен в версии 2016 скорее для промежуточного хранения и удобства;
— поддерживается не указанная в сравнительном списке модель «ключ-значение» на основе механизма хеш-таблиц в памяти;
— поддерживается (тoже не указана) многомерная модель — гиперкубы (SQL Server Analysis Services), была еще до версии 2005 под названием MS OLAP.
Да, спасибо! В случае с MarkLogic тоже был выбор про что рассказывать: про XML или про JSON. Решил тут про JSON, там про XML.

Поддержку «key-value» почти для всех СУБД обошел вниманием, упоминаю ее только если совсем нечего сказать.
JSON как был легким форматом для сериализации обьектов, так по сути им и остался. Понадобится обеспечение целостности, валидация — пиши код в приложении, языки запросов специфичны для СУБД, стандарты фактически отсутствуют, RFC — предел мечтаний.
XML изначально проектировался для хранения документов, обеспечения целостности и извлечения информации по запросам, стандарт устоялся и щироко используется в корпоративном софтостроении.
Сходство в том, что обе модели основаны на теоретико-графовой иеррхической модели. Но ограничения иерархий тоже известны с 1960-х годов, когда переходили к сетевым и множественным моделям данных.
Более подробно есть в статье "Classification of data models in DBMS" на researchgate и в книжке "СУБД для программиста" (пардон за продакт-плейсмент)
документы являются готовыми «агрегатами», которые не нужно каждый раз строить заново

Ну как это «не нужно»? А изменения как вносить? Либо говорим прямо — нас устроит реляционная БД с возможностью хранить длинные строки, куда мы и положим все эти не редактируемые документы. Ну и напомню — длинные строки в реляционных БД есть ещё со времён царя Гороха. Но тогда зачем новые модели БД?
Перефразируя известный баннер на авто: «Внесение изменений в данные придумали адепты реляционных БД!» :)

Сильных жалоб на трудности с тем, чтобы изменять документы в документных СУБД, вроде бы нет, см., например, db.collection.update() в MongoDB.


P.S. Понял, это был сарказм.

Термин «агрегаты» взят из второй главы NoSQL Distilled Садаладжа и Фаулера, там много об этом. Сам термин мне не нравится, больше нравятся «композиты», в том числе с точки зрения значений слов в UML.


По сути, речь идет о денормализации. Поскольку производительность операций соединения в РСУБД не очень высока, давайте не будем их выполнять при каждом запросе. Будем хранить пакеты данных с предвыполненными такими операциями в готовом к отправке формате. Если что, клиент доразберет.


Поскольку все нужные соединения как бы уже выполнены, давайте разучимся их хоть как-то выполнять. Тогда и масштабироваться будет легко, а то межшардовые джойны — ужас-ужас.


Однако аналоги других реляционных операций, например, выборки по значениям полей, делать будем уметь, а то нас назовут хранилищем «key-value». Особых же проблем с тем, чтобы изменять документы, удовлетворяющие условию выборки, в документных СУБД нет, см. следующий комментарий.


Примерно такова идеология документных СУБД в утрированном виде. Т. е. «строить» в цитированной вами фразе означало что-то типа «собирать», а не «отбирать» или «изменять».

соединения как бы уже выполнены

именно, что «как бы выполнены». Проблема иерархической модели (к коим относится документ-ориентированная) в необходимости дублирования данных в иерархиях. Или хранить логические ссылки (по коду, ID и т.п.) на другие иерархии с неизбежными соединениями в запросах.

Простейший пример, две иерархии (коллекции в терминах монги) заказов и отгрузок хранят данные о клиентах. Либо дублирование, либо третья иерархия клиентов со ссылками. «Нормализация» в рамках иерархической модели. Привет из 1960-х и от IBM IMS персонально :)
>> Поскольку производительность операций соединения в РСУБД не очень высока, давайте не будем их выполнять при каждом запросе

С этим отлично справляются РСУБД (храним XML/JSON в строках).

>> Поскольку все нужные соединения как бы уже выполнены, давайте разучимся их хоть как-то выполнять. Тогда и масштабироваться будет легко

Отказ от джойнов «вообще» — движение в каменный век. В РСУБД можно сделать таблицу со строками-документами и не джойнить к ней постоянно, а только в редких случаях. В результате имеем все удобства и ничего не тормозит.

>> Особых же проблем с тем, чтобы изменять документы, удовлетворяющие условию выборки, в документных СУБД нет

Это вы заявляете на основе просто наличия самой возможности что-то поправить, но какова скорость правки? Для неё нужно распарсить документ, изменить нужное значение, снова сериализовать, ну а потом, понятно, сохранить. То есть на лицо лишняя нагрузка на процессор, плюс лишняя нагрузка на диск в случае приличного размера документов (а это — большинство из них). В РСУБД этого всего просто нет.

>> «строить» в цитированной вами фразе означало что-то типа «собирать»

Я так и понимал это слово, когда комментировал. Суть в необходимости парсить, а потом снова сериализовать документы минимум на несколько десятков килобайт, а то и на мегабайты.

ЗЫ. Я вообще не против нового, но оно обязано доказывать свою ценность.

Мне не хотелось бы сваливаться в комментариях в дискуссии на тему «SQL vs. NoSQL». Сойдемся на том, что люди используют (не обязательно по соображениям производительности) и то, и другое, причем порой одновременно. Тогда возникают две основных проблемы: сложность управления всем этим хозяйством и невозможность транзакций в такой гетерогенной среде. СУБД, называющие себя мультимодельными, пытаются их как-то решить. Некоторые — ценой ухудшения производительности по сравнению со специализированными «одномодельными». А по отношению к сторонам спора «SQL vs. NoSQL» я стараюсь выдерживать нейтральное отношение.


С этим отлично справляются РСУБД
Отказ от джойнов «вообще» — движение в каменный век.

Проблема джойнов в РСУБД в том, что подлежащие соединению кортежи, так сказать, вычисляются. Конечно, не выборкой из декартова произведения, но все же. Несколько штук джойнов могут сильно замедлить выполнение запроса. Поэтому даже в РСУБД практикуют денормализацию.


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


It may be argued that in some applications the problems have an immediate natural formulation in terms of networks. This is true of some applications, such as studies of transportation networks, power-line networks, computer design, and the like. We shall call these network applications and consider their special needs later.

Ну а документные СУБД решают проблему джойнов денормализацией и дублированием, да.


Это вы заявляете на основе просто наличия самой возможности что-то поправить, но какова скорость правки? Для неё нужно распарсить документ, изменить нужное значение, снова сериализовать, ну а потом, понятно, сохранить.

Это в SQL Server так, причем, хочется надеяться, временно. В документной СУБД документ уложен в какую-то структуру данных, хранится не как текст. Есть индексы по полям, работой с ними по сути можно и ограничиться, если пользователь просто хочет поменять себе год рождения :).


Например, так обстоят дела в MongoDB: https://docs.mongodb.com/manual/core/write-performance/. И в статьях с жалобами на документные СУБД жалобы на производительность модификации записей занимают не первое место. Первое место занимают джойны, ну а чего хотели-то?

>> Мне не хотелось бы сваливаться в комментариях в дискуссии

И мне туда же.

Но джойны в РСУБД ликвидируются просто (если нужно), а вот реляционная модель со всеми удобствами в нереляционных базах нереализуема (ибо очень дорого). В сумме РСУБД может не хуже NoSQL, а NoSQL не может как РСУБД.

Есть отдельные узкие ниши, где отказ от РСУБД может ускорить некоторые виды обработки данных, но ускорение получается так себе (хотя может кому-то важно хотя бы 20-40% роста в обмен на отказ от всем привычного и гибкого). А в плане удобства работы с документами — просто используем приличный ORM и опять NoSQL становится ненужным.

Но да, я не спора ради, я пробую простую идею донести — в массовом применении РСУБД объективно лучше, а массовая популяризация NoSQL ради каких-то узких ниш — совершенно не оправдана.
в массовом применении РСУБД объективно лучше, а массовая популяризация NoSQL ради каких-то узких ниш — совершенно не оправдана.

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

Хотя аналогия с модой, безусловно, есть. Но популяризируют продукт именно деньги корпораций, и лишь потому, что в их конкретной обстановке был выбран конкретный продукт. То есть бежать за этой «модой» — неэффективно, ибо выбор не основан на чём-то рациональном.

Среди людей принято увлекаться чем-либо, от религии до чайной церемонии, но религию обычно не называют модой, поэтому и выбор СУБД (и технологий вообще) — то же увлечение, которое даже может остаться на всю жизнь. Хотя если нравится, можно и модой обозвать :)
В данном случае, разумеется, речь про явление. Оно не полностью тождественно моде (как не полностью тождественно религии, философскому учению и т.п.), но весьма на неё похоже (в первую очередь именно отсутствием чёткой логической мотивации выбора).

Чем же реляционная модель объективно лучше графовой?

Областью применимости.

Переведите разработку инфосистем на графы, тогда их область применимости станет более подходящей.
user_man, по-видимому, имел в виду, «субъективно». Просто разработчикам удобно при небольшом количестве связей (короткие JOIN), когда на переходе по ним и время теряется не сильно, и SQL запросы получаются не гигантские. До 3-4 join это как-то работает. В этом случае — да, лучше.

И чем же запрос вида


select
    users.id ,
    users.name ,
    images.href ,
    images.width ,
    images.height
from
    images,
    users
where
    users.id = images.user_id

проще и быстрее такого


select from users
fetchplan
    *:-2
    id:0
    name:0
    images.href:0
    images.width:0
    images.height:0

?

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

У меня вообще нет джойнов.

а как же users.id = images.user_id ?

В графовой джойнов нет.

Кстати, в общем виде такое утверждение всё-таки не совсем верно. Оно верно при чисто навигационном стиле запросов, который не всегда возможен и не всегда оптимален.


См., например, статью «How to avoid costly traversals with join hints» в базе знаний Neo4j. Пример запроса оттуда:


MATCH (me:Person {name:'Me'})-[:FRIENDS_WITH]-(friend)-[:LIKES]->(a:Artist)<-[:LIKES]-(me)
USING JOIN on a
RETURN a, count(a) as likesInCommon

Я говорил про приведённые мной два запроса. Не про вообще, конечно же.

Я вообще не против нового, но оно обязано доказывать свою ценность.

Ну, строго говоря, документо-ориентированные БД — это совсем не новое (и появились они ДО реляционных, которые, в свою очередь, как раз и решали многие проблемы предшественников) :)
Я бы назвал те древние подходы файло-ориентированными. Хотя не исключаю, что где-то в тёмных и мрачных пещерах с очень умными неандертальцами проскакивал шаблон хранения структурированных данных, но не на основе реляционной модели. Только это было исключением. Массово же — файлы. Да ещё с микроскопической скоростью обработки и на ленточных носителях…
Называть их можно как угодно. Тогда это называли сетевыми и иерархическими БД.
Но было это не только в эпоху ленточек, но уже и во вполне себе «дисковые времена».
Есть еще продукты InterSystems, лидер в Объектно ориентированных. В основе хранения много-мерный глобал (переменная) хранимый а базе данных с помощью B*-tree. Поверх которого добавлен слой из объектов и реляционная модель. Так же уже есть и варинт с DocumentDB.

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


Что до объектной модели… Тот же Gartner в «IT Market Clock for DBMSs 2019»» предсказывает ей скорую кончину (а мультимодельным СУБД, наоборот, расцвет).


Картинка с циферблатом


Как человеку, занимавшемуся информатизацией здравоохранения, мне будет Caché немного жаль :-). Однако вот OrientDB тоже заявляет о поддержке объектной модели.

Не вижу причин, для беспокойства за Caché и есть уже более свежий новый продукт IRIS. У нас все равно есть мультимодельность, и объектно ориентированность лишь слой. Как раз наличие большого количества уже работающих проектов, не даст сгинуть совсем. А новые проекты так же еще появляются, в том числе и в здравоохранении.
В SQL Server реляционная модель тоже реализована поверх B-tree, но к нему нет прямого доступа, как в Caché.
В дополнение к статье.
Еще одна современная архитектура/паттерн: Data Lake — хранилище «сырых» разнородных данных (структурированных, полуструктурированных, неструктурированных). Применяется для работы с необработанными данными, может поддерживать динамические схемы хранения. Особенно незаменимо при исследовании данных.

Мне кажется, это стоит упоминания, если мы говорим про мультимодельные ИС.

Ну, это немного другая разновидность того, что в совокупности можно назвать конвергентными платформами хранения или как-то так. Наверное, стоило бы в статье указать на отличия этих разновидностей. Про нестуктурированные данные вы сами говорите, про преимущественно не-OLTP характер задач тоже :-).

Использование JSON и/или XML в СУРБД это прямой путь к проблемам.
На текущем проекте так сделали на MS SQL. Тормоза приотличнейшие.
Успешно решал подобную проблему у клиента еще на версии 2005. Они вовремя спохватились, не имея в штате специалистов по СУБД и сделав нагрузочные тесты на ранней стадии. Усеченный пример есть в книжке (в профиле).

mad_nazgul, я бы за любую РСУБД так не сказал, может, где и можно побороться.


С XML и JSON тоже дела могут обстоять не одинаково. Например, в SQL Server для XML есть индексы, а для JSON нет.


Какие-то рекомендации по увеличению производительности при работе с c JSON в SQL Server 2017 были по второй ссылке в том разделе статьи (извиняюсь, она сначала дублировала первую, исправил это).

Да, спасибо, закомментировал.

Рекомендую также обратить внимание на мультимодельные БД Virtuoso и GRAKN.

С OpenLink Software создателей NitrosBase связывают достаточно давние напряженные отношения :-). Подробнее на этот и следующий ваши комментарии отвечу попозже.

В общем, спасибо еще раз за замечание, я наконец-то созрел дать взвешенный ответ.


GRAKN, конечно, интересен. В первую очередь тем, что является единственным отличным от триплсторов более-менее популярным в наши дни представителем того, что Дейт называет «системами баз данных, основанными на логике». В их мультимодельности я бы посомневался… Да, они говорят, что поддерживают реляционную модель, но это не традиционная реляционная модель, а ее, гм, обобщение. Впрочем, тот же известный нам с вами K. I. любит утверждать, что графовая модель тоже реляционная, а Кодд, стало быть, просто узурпировал название. Не согласен с этим, тисну скоро один перевод на эту тему.


Ну и главное, про Virtuoso. Он немного ломает всю классификацию, поэтому не стал его включать (зато для любителей RDF рассказывается про MarkLogic). Базовая модель в Virtuoso реляционная, по сути это такой EAV на стероидах, однако ведущей реляционной СУБД он не является. Логика же истории была к том, что мономодельные СУБД тех времен пытались стать мультимодельными. Virtuoso же был мультимодельным уже тогда. Было принято решение в качестве «субстрата» для хранения RDF использовать реляционную модель (ну а что, разработчики КИС до сих пор всё в нее укладывают), а заодно разработать классную реляционную СУБД. Эх, сейчас так уже не делают, а берут в качестве нижележащей системы хранения RocksDB (писал об этом тут).


Если же о причинах не риторических… Когда поддерживаются и реляционная модель, и RDF, то хочется каких-то содержательных отношений между ними, а не просто чтобы первая была субстратом для второй. Адепты RDF люди избалованные, им хочется чего-то вроде RDB2RDF DM в обе стороны. Кстати, что-то подобное есть в NitrosBase. А когда отношение между данными в двух моделях заключается в банальном EAV, не очень ясна практическая применимость этих вкусностей Virtuoso наподобие SPASQL (возможность сочетать SQL- и SPARQL-запросы), пополнения SQL-таблиц результатами присоединения следствий и пр.


И самое главное… Реализованная через EAV мультимодельность кажется мне причиной багов Virtuoso, связанных с поддержкой property paths. Она на самом деле в Virtuoso весьма плохая. Предполагаю, что потому, что пришлось ее реализовывать через механизм транзитивных SQL-запросов.


Disclaimer

Но можно дипломатично согласиться, что Virtuoso просто опередил свое время. OpenLink поспешили реализовать property paths, но в SPARQL 1.1 те были стандартизованы не совсем так, как реализованы в Virtuoso, что и стало источником проблем. Но если посмотреть на работу SPARQL 1.2 CWG, то можно увидеть в вопросе о property paths некоторое тяготение в сторону Virtuoso. Но больше все предвкушают SPARQL 2, заточенный на работу с RDF*. Сможет ли Virtuoso его в принципе поддержать — не знаю. Про RDF* я немного написал тут.

А как у вас хранятся графы? И как делаются по ним выборки?

Для хранения сведений о связях между ребрами используется оригинальный sparse link index, довольно далекий от B-деревьев и их производных. Можно сказать, что он быстрый, как в специализированных графовых библиотеках, но быстрый еще и на запись. А для хранения скалярных атрибутов используются (когда используются) довольно стандартные индексы.


Я много рассказать не могу, вот в открытом доступе информация в объеме и формате патентной заявки.

Коллеги подкинули ссылку на статью C. Zhang, J. Lu, P. Xu, Y. Chen. UniBench: A Benchmark for Multi-Model Database Management Systems из сборника проходившей год назад в Рио-де-Жанейро 10th TPC Technology Conference on Performance Evaluation and Benchmarking (боковой трек в VLDB 2018).


Табличка из нее, похожая на приведенную в посте, предлагает классификацию мультимодельных СУБД. Не все в этой табличке согласуется с написанным в посте.


Таблица

Все четверо из Хельсинкского университета. На финско-китайской границе всё спокойно — был такой анекдот.

Sign up to leave a comment.

Articles