У меня нет идей и надеюсь получить полезный вклад. Я использую этот вопрос, чтобы сжать свой опыт и поделиться им, надеясь побудить некоторых дистрибьюторов перейти к следующему шагу с помощью моделирования графических баз данных как вопрос/способ первого класса.
Я проверил несколько решений для построения графиков, которые можно использовать node.js в течение нескольких недель. Моим вариантом использования является сохранение взаимодействия разных учетных записей социальных сетей. Необходимо использовать CPU и память наиболее эффективным способом.
Мои самые важные требования:
- in_memory (по крайней мере для индексации)
- с открытым исходным кодом (и свободный для использования)
- те же характеристики JavaScript/Node.js как гражданин первого класса
- удобный язык запросов и моделирования
Neo4j
Мне действительно нравится Cypher, поэтому лучшим выбором будет Neo4j. Но главная проблема с Neo4j заключается в том, что доступ к JavaScript не является родным. Он использует REST-API, который примерно в десять раз (10x) медленнее, чем прямой доступ к Java. Поэтому я взглянул на node-neo4j-embedded, но он неактивен более двух лет. Похоже, что автор неактивен вообще (плохой знак).
ArangoDB
Действительно хорошие разработчики ядра ArangoDB ответили на мой вопрос о внутренних компонентах. Наконец, это означает JavaScript является гражданином первого класса, потому что из JS могут быть вытеснены собственные запросы. Если посмотреть на тесты с открытым исходным кодом, я думаю, что это справедливо. Но я боюсь, что они не использовали node-neo4j-embedded для своего теста. Сравнительные тесты сравнивают REST-API (отредактировано из-за комментария @weinberger). Мне жаль, что они не сравнили родные API (возможно, кто-то достаточно скроен и попробует!) Дайте нам знать!). Обновление. Как я уже заметил, OrientDB имеет ответил на тест с помощью нового драйвера node.js(используя Кэш команд, запустив сервер с помощью -Dcommand.cache.enabled = true -Dcommand.cache.minExecutionTime = 3, what isn ' t честно, потому что это не критерий кешей запросов!)
Поскольку мне нравится использовать ArangoDB в качестве базы данных графа, у меня будет 3 варианта (источник: FAQ):
- traverse Объекты JS
- с помощью Функции графика AQLs
- с помощью REST API
В общем случае не удобно, как cypher. И я не уверен, как сравнивать и каков правильный способ моделирования данных (например, Neo4J очень хорошо объясняет). Я бы хотел иметь что-то подобное для диаграмм ArangoDB. Похоже, что ArangoDB ориентирован на операции с графикой, а Neo4J больше подходит для использования графиков, если у вас больше отношений, чем строк (причина использования графиков вместо отношений с соединениями).
MongoDB
Основанный на документе MongoDB не оптимизирован для операций с графами, но последний получил экспериментальный механизм хранения in_memory. Кроме того, есть несколько проектов, которые связаны с in_memory или graph, но ничто не является действительно убедительным. И в этой дискуссии похоже, что MongoDB не то, что мне нравится.
OrientDB
Поскольку существует сравнение OrientDB vs. MongoDB, доступный (из OrientDB), я собираюсь использовать этот. "OrientDB имеет гибридный механизм Document-Graph", используя SQL. Я бывший эксперт PHP/MySQL. Но где же модельная часть? Их глава работает с графиками не похожа на cypher. Это похоже на использование SQL for Graphs. В этом нет ничего плохого, но я использую cypher, прежде чем пропустить моделирование, как чувство. Если кто-то сделал процесс моделирования с OrientDB и Graphs, возможно, вы могли бы написать учебник, например Neo4J сделал.
Обновление: О доступе к JavaScript, как первый гражданин есть новости: "В следующем выпуске скорость этого драйвера будет сопоставима с родной Java one". Драйвер forked node.js был зафиксирован в последние дни bin.
Обновить. Прежде чем выбирать OrientDB, вы можете прочитать статью статью о некоторых проблемах и связанные с ней обсуждения. Статья затрагивает чувствительную проблему, и к ней следует обращаться с критическим умом. Примечание от автора этого обновления: я новичок в редактировании SO и не имею достаточной репутации, чтобы помещать это в комментарии. Я считаю, что эта информация является действительным моментом для обсуждения, а не уверен, как разместить ее здесь в соответствии с правилами SO.
LokiJS
Прежде чем я смотрел на Neo4J, ArangoDB и MongoDB, я играл с этой базой данных на основе JavaScript, основанной на базе LokiJS, какие швы следовать стратегии, чтобы игнорировать все, что замедляет производительность и эффективность. LokiJS пытается завершить Mongo-Style (RoadMap). Основной проблемой является плохая способность масштабирования. Из-за этого это не база данных графа, но это было интересное решение в начале моего проекта. Также было не идеальное чувство, чтобы найти всю распределенную документацию (возможно, они должны перезагрузиться вместе с GitBook). Наконец, LokiJS - очень интересный проект, и я надеюсь, что они пойдут вперед!
LevelDB
Раньше, когда я писал дипломную работу, я смотрел на levelDB. Вспоминая это во время написания этого сообщения, я искал LevelDB in_memory и получил многообещающий результат под названием MemDown (см. также). Я не тестировал эту находку, но, возможно, у кого-то есть опыт работы и моделирования для этого решения. Может быть, это был бы самый эффективный способ, если все остальные не подойдут, потому что я просто напишу легкий клофер cypher с целью оставаться очень легким, как я могу.
Изменить: Из-за комментария, вот ссылка на LevelGraph. В качестве идеи реализовать парсер CYPHER для LevelGraph/LevelDB отправной точкой будет сравнение
CREATE (SUBJECT:"a") - [b:PREDICATE] -> (OBJECT:"c")
RETURN, subject, predicate, object
var RETURN = { SUBJECT: "a", PREDICATE: "b", OBJECT: "c" };
db.put(RETURN, function(err) {
// ..
});
Заключение
Как вы, вероятно, заметили, что я не супергерой о графиках. Но это мое первоначальное погружение в это, и я пытаюсь получить обзор. Я предполагаю, что есть много людей, которые хотят задавать те же вопросы, что и я, но не имеют времени. Я надеюсь, что этот пост поможет многим людям и изменится по комментариям и ответам на станет хорошо продуманным обзором того, как моделировать данные для графиков.
@editors: Добро пожаловать.
@commenters: Это результат моих личных исследований - если вы тоже проделали путешествие, как я, ответьте короткой речью, как я сделал для каждой БД, которую я оценил (не забудьте указать мой 4 гола).
