Графовые БД против БД документов против триплсторов
Это несколько абстрактный и общий вопрос. Меня интересуют присущие (а также специфические для конкретной реализации) свойства различных подходов к сохранению неструктурированных данных с большим количеством внутренних ссылок (графоподобных) и большим количеством свойств (JSON-подобных).
-
Поскольку граф является надмножеством дерева, вы можете рассматривать графовые БД (например, Neo4j) как надмножество документальных БД (например, MongoDB). То есть, графовая БД обеспечивает всю функциональность документарной БД, плюс дополнительно позволяет циклы или имеет собственный тип указателя, так что вам не нужно вручную разыменовывать чужие ключи/иды. Итак, существует ли некая переломная точка, которую вы достигаете при добавлении большего количества ссылок на ваши объекты/ресурсы, когда вам лучше использовать графовую БД, но раньше лучше было использовать хранилище документов? Есть ли преимущества у хранилищ документов (место для хранения, производительность?) или лучше всегда использовать графовую БД на случай, если в будущем вам понадобится больше ссылок?
-
Аналогично, как сравниваются графовые БД и триплсторы (например, хранилища RDF)? Графовые БД (где узлы и ребра имеют свойства) кажутся супермножеством простых триплсторов. Так для каких задач (если таковые имеются) триплсторы действительно лучше, чем, скажем, Neo4j? (Одним из преимуществ RDF-хранилищ является наличие стандартизированного языка запросов - SPARQL - хотя, похоже, есть много людей, которым SPARQL не нравится, и поэтому они назвали бы это недостатком).
Я думаю, мой вопрос в следующем: графовая модель (со свойствами), кажется, может аккуратно выражать все виды данных, в чем подвох, когда вы входите в реальность? Я полагаю, что загвоздка графовых БД заключается в производительности, поэтому я хотел бы увидеть некоторые цифры или эмпирические правила о том, какого рода замедления следует ожидать при загрузке, запросах и модификации данных, а также о требованиях к памяти и постоянному хранению (по сравнению с хранилищами документов и тройных данных). А как насчет горизонтальной масштабируемости? У меня сложилось впечатление, что там игровое поле довольно ровное.
Как вы думаете, возможно ли, что графы с их выразительностью станут новой моделью хранения по умолчанию для проектов, не имеющих сверхбольших данных, или мы обречены на десятилетие Polyglot Persistence с RDBMS, JSON-хранилищами и Graph DBs, живущими друг с другом, которые должны быть интегрированы с еще большим количеством "клейкого" кода?
Я не уверен, что соглашусь с мнением, что многим людям не нравится SPARQL. SPARQL 1.0 действительно имел некоторые недостатки, но он довольно хорошо справлялся с тем, для чего он был разработан, а новая итерация, SPARQL 1.1, развивает его, добавляя многие конструкции из SQL, которые люди ожидали увидеть в оригинальной спецификации, включая подзапросы, агрегаты и семантику обновления. Я думаю, что тот факт, что это стандарт, и вы можете ожидать увидеть одинаковый разбор и семантику в каждом тройном хранилище, в отличие от диалектов 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 или другой язык обхода для изучения графа.
Что касается вопроса "обречены ли мы с полиглотной персистентностью": Независимо от вопроса о базе данных документов/графов, я считаю, что RDBMS будут существовать еще некоторое время. Так что ответ на этот вопрос: "да, это очень вероятно".
Существует специальный стандарт для баз данных графов - Tinkerpop, включающий язык запросов Gremlin (императивный), поддерживаемый практически всеми, кроме ArangoDB.
Чтобы еще больше запутать воду, существуют также гибридные документально-графовые базы данных OrientDB и ArangoDB.
Мне кажется, что основное различие между хранением дочерних отношений с помощью ребра в графовой базе данных и в виде встроенного объекта в базе данных документов заключается в том, что в первом случае дочернее отношение можно дешево переместить к другому родителю без риска того, что оно появится в двух разных местах.