База данных документов ArangoDB, а также база данных графиков? Как это возможно?

Отказ от ответственности: я Макс из ArangoDB, один из основных разработчиков.

Прежде всего, более подробное обсуждение этого и других связанных вопросов можно найти в моей статье Графики в моделировании данных — голый ли император?, но здесь я постараюсь кратко ответить на оба вопроса.

(1) Хранить граф в хранилище документов относительно просто (как и в реляционной базе данных), можно, например, просто сохранить документ для каждой вершины в «коллекции вершин» и документ для каждого ребра в « край-коллекция». Нужно только убедиться, что каждое ребро запоминает, из какой вершины оно приходит и в какую вершину идет. В ArangoDB мы используем для этого атрибуты _from и _to в пограничном документе.

Однако важнейшее свойство графовой базы данных состоит в том, что она должна эффективно отвечать на запросы о графах. Типичные запросы для графов: (а) «Каковы соседи вершины в графе?» или (b) «Каков кратчайший путь из вершины A в вершину B в графе?» или (c) «дайте мне все вершины, которых я могу достичь из вершины A, следуя ребрам». Принимая во внимание, что (а) просто нужен хороший индекс для набора ребер, (б) и (в) включают априори неизвестное количество шагов в графе. Следовательно, (b) и (c) не могут быть эффективно выполнены с помощью традиционных языков запросов к базам данных, таких как SQL, просто потому, что они требуют большого объема связи между клиентом и сервером или, по крайней мере, очень сложного выражения с переменным числом символов. присоединяется. Поэтому я называю запросы типа (b) и (c) «графикой», не определяя это строго.

Поэтому мой краткий ответ на вопрос "как хранилище документов может быть графовой базой данных?" заключается в следующем: сохраните график, как указано выше, и реализуйте графические запросы на сервере базы данных, доступном из языка запросов хранилища данных. В принципе, то же самое можно сделать с реляционной базой данных и некоторыми существенными расширениями SQL.

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

Это приводит к моему ответу на вопрос (2), который, очевидно, немного предвзят:

По сравнению с ArangoDB, которая является распределенной мультимодельной базой данных в указанном выше смысле, Neo4j представляет собой классическую графовую базу данных. Он хранит графики, позволяет запрашивать их с помощью «графических запросов» и имеет хранилище и механизм запросов, оптимизированный для этого. Neo4j особенно хорош в сопоставлении путей, используя встроенный шифр языка запросов. Он позволяет прикреплять свойства к вершинам и ребрам, но это не полнофункциональное хранилище документов. Он не оптимизирован для обработки запросов документов с использованием нескольких вторичных индексов и не выполняет соединения. Кроме того, Neo4j не распространяется.

Neo4j написан на Java, ArangoDB написан на C++ и включает Google V8 для выполнения расширений JavaScript.

Для сравнения производительности см. этот пост< /а>.