Базы графов против БД документов и триплетов
Это несколько абстрактный и общий вопрос. Меня интересуют присущие (а также зависящие от реализации) свойства различных подходов для сохранения неструктурированных данных с большим количеством внутренних ссылок (графических) и множеством свойств (JSON-подобных).
Поскольку граф является надмножеством дерева, вы можете посмотреть на графические БД (например, Neo4j) как на расширенный набор документов БД (например, MongoDB). То есть графовая БД обеспечивает все функциональные возможности БД документа, а также дополнительно допускает циклы или имеет собственный тип указателя, поэтому вам не нужно разыменовывать внешние ключи / идентификаторы вручную. Так есть ли какой-то переломный момент, которого вы достигнете при добавлении большего количества ссылок на ваши объекты / ресурсы, когда вам лучше работать с графической БД, но ранее вам было лучше с хранилищем документов? Есть ли преимущества для документирования БД (объем памяти, производительность?) Или вы всегда должны использовать графическую БД на случай, если в будущем понадобится больше ссылок?
Точно так же, как сравниваются графовые БД и триплетные хранилища (например, магазины RDF)? БД графов (где узлы и ребра имеют свойства) кажутся надмножеством простых триплетов. Итак, для каких задач (если они вообще есть) лучше всего выполнять триплеты, скажем, Neo4j? (Одним из преимуществ хранилищ RDF является то, что существует стандартизированный язык запросов - SPARQL - хотя, похоже, многим людям не нравится SPARQL, и поэтому он назвал бы это недостатком.)
Я предполагаю, что мой вопрос: графовая модель (со свойствами), кажется, способна аккуратно выразить все виды данных, в чем выгода, когда вы входите в реальность? Я предполагаю, что выгода графических БД - это производительность, поэтому я хотел бы увидеть некоторые цифры или практические правила о том, какие замедления следует ожидать при загрузке, запросе и изменении данных, а также памяти и требований к постоянному хранилищу (по сравнению с документом). и тройные магазины). А как насчет горизонтальной масштабируемости? У меня сложилось впечатление, что там игровое поле довольно ровное.
Как вы думаете, возможно ли, что графы с их выразительностью станут новой моделью хранения по умолчанию для проектов, в которых нет сверхбольших данных, или мы обречены на десятилетие Постоянства Polyglot с RDBMS, JSON-хранилищами и Graph DB, живущими друг с другом что должно быть интегрировано с еще большим количеством кода?
3 ответа
Я не уверен, что согласился бы с мнением о том, что многим людям не нравится SPARQL. SPARQL 1.0 имел некоторые недостатки, но он довольно хорошо отвечал тому, для чего он был разработан, и новая итерация, SPARQL 1.1, основывается на нем, добавляя много конструкций из SQL, которые люди ожидали увидеть в исходной спецификации, включая подзапросы, агрегаты & обновить семантику. Я думаю, что тот факт, что он является стандартным, и вы можете ожидать, что в каждом тройном хранилище можно увидеть одинаковый синтаксический анализ и семантику, является отличной особенностью.
Я также утверждал бы, что все тройные хранилища являются графовыми базами данных; Вы можете поместить свойства на определенные ребра в RDF, хотя и не так хорошо, как вы можете с Neo4j. Но у тройных хранилищ есть преимущество реального языка запросов, стандартного представления данных w3c, которое упрощает перенос ваших данных в другое хранилище тройных хранилищ, а для ряда тройных хранилищ - возможность выполнять рассуждения на основе OWL.
Я ничего не знаю о масштабируемости большинства графических БД, но в целом коммерческие базы данных RDF достаточно хорошо масштабируются. Все может масштабироваться до миллиардов троек, что позволяет использовать множество вариантов использования. Хотя то, как они обрабатывают масштабирование, сильно отличается от поставщика к поставщику в зависимости от масштабирования или масштабирования, кластеризации и т. Д. Вы также увидите довольно разные требования к памяти и оборудованию, чтобы соответствовать реализациям для каждого. Для меня я обычно собирался взять экземпляр EC2, обычно 2XL или 4XL, смонтировать EBS, достаточно большой для хранения данных, и я довольно хорошо настроен.
Кроме того, некоторые тройные хранилища интегрируются с Lucene или аналогичными технологиями для предоставления инвертированных индексов по данным, и многие теперь начинают включать геопространственные и временные индексы. Это очень полезные функции, которые я не уверен в их наличии в Neo4j.
С учетом сказанного, они не собираются масштабировать так же хорошо, как реляционные базы данных, они просто не такие зрелые. Но вы также не будете облажаться, если у вас есть "реальные" объемы данных. Конечно, одно из преимуществ магазинов троек - это рассуждение, выполнение которого в масштабе сложно, но это во многом причина того, почему были созданы различные профили OWL. Но вы можете нарисовать себя в углу, если вы не думаете заранее.
Я думаю, что графовые базы данных, в частности, тройные хранилища, могут быть очень хорошими для множества создаваемых приложений, но я не думаю, что это означает, что с ними должно быть все сделано. Как и все остальное, они являются инструментами с их положительными и отрицательными сторонами, поэтому вы должны сделать правильный выбор в зависимости от своего приложения. Но они, вероятно, всегда заслуживают хотя бы рассмотрения в эти дни.
Небольшое исправление ответа amk: Tinkerpop также содержит адаптер для ArangoDB, см. https://github.com/triAGENS/blueprints-arangodb-graph/wiki/Gremlin. Таким образом, вы можете использовать запросы Gremlin с ArangoDB.
В общем, многомодельные базы данных, такие как ArangoDB или OrientDB, позволяют использовать все приятные возможности баз данных документов (без схем, индексов) вместе со структурами графов. Вершина или ребро - это просто документ, как в базе данных документов. Вы можете иметь столько свойств или даже встроенных документов, сколько захотите. Вы можете определить хеш, диапазон, полнотекстовые или географические индексы в этих документах. Или вы можете забыть о структуре документа и просматривать ваши документы как вершины и ребра, используя Gremlin или какой-либо другой язык обхода для исследования лежащего в основе графа.
Что касается вопроса "мы обречены на постоянство полиглотов": независимо от вопроса о базе данных документов / графиков, я полагаю, что СУБД будет еще немного дольше. Итак, ответ на этот вопрос: "да, это очень вероятно".
Существует специальный стандарт для графовых баз данных - Tinkerpop, включая язык запросов Gremlin (императив), поддерживаемый практически всем, кроме ArangoDB.
Для того, чтобы мутить воду дальше, существуют также гибридные базы документов-графиков OrientDB и ArangoDB.
Меня поражает, что основное отличие между хранением дочерних отношений с использованием ребра в базе данных графов и встроенного объекта в базе данных документов заключается в том, что с первым ребенок может быть перемещен к другому родителю дешево и без риска его появления в базе данных. два места с двумя разными местами.