Графические базы данных и базы данных документов против Triplestores

Это несколько абстрактный и общий вопрос. Меня интересуют присущие (а также специфичные для реализации) свойства разных подходов к сохранению неструктурированных данных как с множеством внутренних ссылок (по графику), так и с множеством свойств (JSON-like).

Так как граф является надмножеством дерева, вы можете посмотреть на графические DB (например, Neo4j) в виде надмножества DB-документов (например, MongoDB). То есть, DB графа обеспечивает все функциональные возможности документа DB плюс дополнительно также позволяет циклы или имеет собственный тип указателя, поэтому вам не нужно вручную разыскивать внешние ключи/идентификаторы. Итак, есть ли какой-то переломный момент, который вы достигаете, добавляя больше ссылок на свои объекты/ресурсы, где вам лучше с помощью графической базы данных, но раньше было лучше с хранилищем документов? Имеются ли преимущества для документирования БД (пространство для хранения, производительность?) Или вы всегда должны идти с графическим DB на случай, если вам понадобится больше ссылок в будущем?
Аналогично, как сравнивают DB-диаграммы и трипрессторы (например, хранилища RDF)? Графические DB (где узлы и ребра имеют свойства) кажутся суперсетными простыми трипрессорами. Итак, для каких проблем (если таковые имеются) лучше выполнять триплестры, скажем Neo4j? (Одно из преимуществ хранилищ RDF заключается в том, что существует стандартизованный язык запросов - SPARQL - хотя, похоже, много людей, которым не нравится SPARQL, и, таким образом, назвал бы это недостатком.)

Я предполагаю, что мой вопрос: модель графа (со свойствами), кажется, способна аккуратно выражать все виды данных, что является уловкой, когда вы входите в реальность? Я полагаю, что уловка графических DB - это производительность, поэтому я хотел бы увидеть некоторые цифры или эмпирические правила о том, какие замедления ожидать при загрузке, запросе и изменении данных, а также памяти и постоянных требованиях к хранению (по сравнению с документом и тройные магазины). Что же касается горизонтальной масштабируемости? У меня сложилось впечатление, что игровое поле достаточно ровное.

Считаете ли вы возможным, что графики с их выразительностью станут новой моделью хранения по умолчанию для проектов, которые не имеют сверхбольших данных, или мы обречены на десятилетие Polyglot Persistence с RDBMS, магазинами JSON и графическими DB, живущими друг с другом, которые должны быть интегрированы с еще большим количеством кода клея?

Ответ 1

Я не уверен, что соглашусь с тем, что многим людям не нравится SPARQL. У SPARQL 1.0 были короткие предложения, но он довольно хорошо рассмотрел то, для чего он был разработан, а новая итерация SPARQL 1.1 основывается на том, что он добавляет множество конструктов из SQL, которые люди ожидали увидеть в исходной спецификации, включая подзапросы, агрегаты и обновить семантику. Я считаю, что тот факт, что он стандартный, и вы можете ожидать увидеть тот же синтаксический анализ и семантику в каждом трехместном хранилище, в отличие от диалектов SQL, - хорошая функция.

Я бы также утверждал, что все тройные магазины представляют собой базы данных графов; вы можете поместить свойства на определенные ребра в RDF, хотя и не так хорошо, как вы можете с Neo4j. Но в тройных магазинах есть преимущество реального языка запросов, стандартное представление данных w3c, которое делает тривиальным перенос ваших данных в другой трипстер, а для нескольких трёх магазинов - возможность выполнять рассуждения на основе OWL.

Я не знаю ничего о масштабируемости для большинства графических db, но, как правило, коммерческие базы данных RDF довольно хорошо масштабируются. Все могут масштабироваться в миллиарды троек, которые обрабатывают множество вариантов использования. Хотя то, как они справляются с масштабированием, резко отличается от поставщика к поставщику, чтобы масштабировать или масштабировать, кластеризовать и т.д. Вы также увидите довольно разные требования к mem и аппаратным средствам, чтобы соответствовать реализациям для каждого. Для меня я, как правило, просто ухватился за экземпляр EC2, как правило, 2XL или 4XL, смонтировал EBS достаточно большой для хранения данных, и я довольно хорошо настроен.

Кроме того, некоторые тройные магазины интегрируются с Lucene или аналогичными технологиями для обеспечения инвертированных индексов по данным, и многие из них теперь начинают включать геопространственные и временные индексы. Это очень полезные функции, которые я не уверен в их доступности в чем-то вроде Neo4j.

С учетом сказанного они не будут масштабироваться, а также реляционные базы данных, они просто не так зрелы. Но вы также не собираетесь ввернуться, когда у вас есть "реальные" объемы данных. Конечно, одним из преимуществ магазинов троек является аргументация, которая выполняется в масштабе сложна, но большая часть причин, по которым были созданы различные профили OWL. Но вы можете нарисовать себя в угол, если не подумаете.

Я думаю, что графические базы данных, трёхлокальные магазины, могут быть довольно хорошим совпадением для множества приложений, которые строятся, но я не думаю, что это означает, что с ними все должно быть сделано. Как и все остальное, это инструменты с их хорошими моментами и их плохими моментами, поэтому вы должны сделать правильный выбор на основе своего приложения. Но в наши дни они, вероятно, всегда заслуживают по крайней мере рассмотрения.

Ответ 2

Просто небольшая коррекция ответа на amk: Tinkerpop также содержит адаптер для ArangoDB, см. https://github.com/triAGENS/blueprints-arangodb-graph/wiki/Gremlin. Таким образом, вы можете использовать запросы Gremlin с ArangoDB.

В целом, многомодельные базы данных, такие как ArangoDB или OrientDB, позволяют использовать все приятные функции баз данных документов (без схемы, индексы) вместе с структурами графов. Вершина или край - это просто документ, как в базе данных документа. У вас может быть как можно больше свойств или даже встроенных документов. Вы можете определить хэширование, диапазон, полнотекстовый или геоиндекс на этих документах. Или вы можете забыть о структуре документа и просмотреть свои документы в виде вершин и ребер, используя Gremlin или некоторый язык обхода для исследования базового графика.

Что касается вопроса "мы обречены на сохранение полиглота": независимо от вопроса о базе данных документа/графа, я считаю, что СУБД будет примерно через некоторое время. Итак, ответ на этот вопрос: "да, это очень вероятно".

Ответ 3

Существует специальный стандарт для баз данных графов - Tinkerpop, включая язык запросов Gremlin (императивный), поддерживаемый всем остальным чем ArangoDB.

Для более грязной воды существуют также гибридные базы данных документа OrientDB и ArangoDB.

Мне кажется, что существенное различие между сохранением дочерних отношений с использованием ребра в базе данных графа в сравнении с встроенным объектом в базе данных документов заключается в том, что с первым ребенок может быть перемещен в другой родитель дешево и без риска он появляется в двух местах с двумя разными местами.