У меня закончились идеи, и я надеюсь получить полезную информацию. Я использую этот вопрос, чтобы сжать свой опыт и поделиться им, надеясь вдохновить некоторых дистрибьюторов сделать следующий шаг с моделированием графовых баз данных в качестве первоклассного вопроса / пути.
Я проверял некоторые решения для графовых баз данных, которые может использовать node.js в течение нескольких недель. Я использую для сохранения взаимодействий различных учетных записей социальных сетей. Необходимо максимально эффективно использовать ЦП и память.
Мои самые важные требования:
- 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 (используя Command Cache, запустив сервер с -Dcommand.cache.enabled = true -Dcommand.cache.minExecutionTime = 3, что несправедливо, потому что это не был тест кеширования запросов!)
Поскольку мне нравится использовать ArangoDB в качестве базы данных графов, у меня есть 3 варианта (источник: FAQ):
- просматривать объекты JS
- с использованием функций графиков AQL
- с помощью REST API
В общем, это неудобно, как шифр. И я не уверен, как сравнивать и как правильно моделировать данные (например, Neo4J очень хорошо объясняет < / а>). Я бы хотел иметь что-то подобное для графиков ArangoDB. Кажется, что ArangoDB ориентирован на операции с графами, а Neo4J больше подходит для нужд использования графов, если у вас больше связей, чем строк (причина использовать графы вместо отношений с объединениями).
MongoDB
MongoDB на основе документа не оптимизирован для операций с графами, но в последнее время получил экспериментальный механизм хранения in_memory. Также есть несколько проектов, связанных либо с in_memory, либо с графами, но ничего действительно интересного. И в этом обсуждении похоже, что MongoDB не то, что мне нравится использовать. .
OrientDB
Поскольку существует сравнение OrientDB и MongoDB, доступное (от OrientDB), я собирался используйте это. «OrientDB имеет гибридный механизм Document-Graph» с использованием SQL. Я бывший эксперт по PHP / MySQL. Но где же модельная часть? Их глава работа с графиками не похожа на шифрование. Это похоже на использование SQL для графиков. В этом нет ничего плохого, но, используя шифрование, я скучаю по моделированию как по ощущениям. Если кто-то делал процесс моделирования с помощью OrientDB и Graphs, возможно, вы могли бы написать учебник, например, Neo4J сделал.
Обновление: о доступе к JavaScript, например о первом гражданине, есть новости: "В следующем выпуске скорость этого драйвера будет сопоставима со скоростью нативного Java" Разветвленный драйвер node.js в последние дни был исправлен ящик.
Обновление: перед тем, как выбрать OrientDB, можно прочитать статья о некоторых проблемах и обсуждениях, связанных с ней. Статья затрагивает деликатный вопрос, и к ней следует подходить критически. Примечание автора этого обновления: я новичок в редактировании SO, и у меня недостаточно репутации, чтобы оставлять это в комментариях. Я считаю, что эта информация является правильным поводом для обсуждения, но не знаю, как разместить ее здесь в соответствии с правилами SO.
LokiJS
Прежде чем я посмотрел на Neo4J, ArangoDB и MongoDB, я поигрался с базой данных in_memory, основанной на JavaScript, которая называется LokiJS, что может следуйте стратегии игнорировать все, что снижает производительность и эффективность. LokiJS пытается завершить Mongo-Style (RoadMap). Основная проблема - это плохая способность масштабирования. Конечно, это не графическая база данных, но это было интересное решение в начале моего проекта. Также было не очень приятно найти всю распространяемую документацию (возможно, им стоит перезагрузиться с GitBook). Наконец, LokiJS вообще очень интересный проект, и я надеюсь, что они будут продвигаться вперед!
LevelDB
Раньше, когда я писал свою дипломную работу, я смотрел на levelDB. Вспоминая об этом во время написания этого сообщения, я поискал LevelDB in_memory и получил многообещающий результат под названием MemDown (см. также ). Я не тестировал эту находку, но, возможно, у кого-то есть опыт работы и моделирования для этого решения. Возможно, это был бы наиболее эффективный способ, если бы все остальные не подходили, потому что я бы просто написал легкий клон шифра с целью оставаться намного легче, чем я могу.
Изменить: из-за комментария вот ссылка на 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 гола).
