Question

我没有想法，希望得到一些有用的意见。我正在使用这个问题来压缩我的经验并分享它们，希望激励一些经销商进一步将图形数据库建模为一流的问题/方式。

我已经验证了node.js可以使用的一些图形数据库解决方案几周。 我的用例是保存不同社交用户网络帐户的互动。需要以最有效的方式使用CPU和内存。

我最重要的要求是：

in_memory（至少用于编制索引）
开源（并免费使用）
相同的 JavaScript / Node.js 作为头等公民的表现
舒适的查询和建模语言

Neo4j的

我真的很喜欢cypher所以我最好的选择是Neo4j。但是关于Neo4j的主要问题是JavaScript访问是非原生的。它使用的REST-API比直接Java访问about ten times (10x) slower。所以我看一下node-neo4j-embedded，但它已经停用两年多了。看起来它author根本不活跃（坏迹象）。

ArangoDB

ArangoDB真正优秀的核心开发人员回答了my question关于内部的问题。最后，它意味着JavaScript是一等公民，因为原生查询可以被推出JS。看看开源基准测试，我认为这是公平的。但我担心他们没有使用node-neo4j-embedded作为他们的基准。基准测试比较REST-API（由于@weinberger评论而编辑）。我希望他们比较本机API（也许有人足够snoopy并尝试一下！ - 让我们知道！）。更新：正如我现在注意到的那样，OrientDB有answered the benchmark一个新的node.js驱动程序（使用Command Cache启动服务器 -Dcommand.cache.enabled = true -Dcommand.cache.minExecutionTime = 3 ，什么不公平，因为它不是查询缓存基准！）

因为我喜欢使用ArangoDB作为图形数据库，所以我有3个选择（来源：FAQ）：

一般来说，像并不舒服。我不确定如何比较以及建模数据的正确方法（如Neo4J explains very well）。我喜欢ArangoDB Graphs的类似内容。感觉ArangoDB专注于图形操作，如果关系比行（the reason to use graphs instead of relations with joins）更多，Neo4J更适合使用图形。

MongoDB的

基于文档的MongoDB未针对图形操作进行优化，但后来has gotten an experimental in_memory storage engine。还有一些项目是in_memory或图形相关，但没有什么是真正引人注目的。在this discussion，看起来MongoDB不是我喜欢使用的。

OrientDB

因为有关OrientDB vs. MongoDB可用的比较（来自OrientDB），我虽然即将使用这个。＆＃34; OrientDB有一个混合的Document-Graph引擎＆＃34;使用SQL。我是以前的PHP / MySQL专家。但建模部分在哪里？他们的章节working with graphs不像密码那样。就像使用SQL for Graphs一样。这没有什么不对，但在我错过像感觉之类的建模之前使用cypher。如果有人使用OrientDB和Graphs进行建模过程，您可以编写像Neo4J had done这样的教程。

更新：关于第一个公民there are news的JavaScript访问权限：＆＃34; 在下一个版本中，此驱动程序的速度将与原生Java 相比＆＃34;分叉的node.js驱动程序had bin fixed last days。

更新：在选择OrientDB之前，您可能希望阅读article about some issues以及从那里链接的讨论。这篇文章涉及一个敏感问题，应该以批判的态度来处理。本更新作者的注意事项：我是编辑SO的新手，并且没有足够的声誉将其用于评论。我相信这些信息是一个有效的讨论点，不知道如何根据SO规则将其放在这里。

LokiJS

在我看到Neo4J，ArangoDB和MongoDB之前，我使用了基于JavaScript的in_memory数据库LokiJS来玩，接下来的策略是忽略所有会降低性能和效率的因素。 LokiJS正试图完成Mongo-Style（RoadMap）。主要问题是bad ability to scale。因为它不是图形数据库，但在我的项目开始时它是一个有趣的解决方案。找到所有分发文档（也许他们应该使用GitBook重启）并不是一种完美的感觉。最后LokiJS是一个非常有趣的项目，我希望他们能继续前进！

性LevelDB

以前当我写学位论文时，我正在查看levelDB。在撰写这篇文章的同时记住这一点，我搜索了 LevelDB in_memory 并获得了一个名为MemDown的有希望的结果（参见also）。我还没有测试过这个发现，但也许有人有为这个解决方案工作和建模的经验。也许这将是最有效的方式，如果所有其他人都不适合，因为我只是编写一个轻量级的密码克隆，其目标是尽可能保持轻量级。

修改：由于评论，此处是指向LevelGraph的链接。作为为LevelGraph / LevelDB实现CYPHER解析器的想法，您的出发点是比较

Cypher：

CREATE (SUBJECT:"a") - [b:PREDICATE] -> (OBJECT:"c") 
RETURN, subject, predicate, object

LevelGraph：

var RETURN = { SUBJECT: "a", PREDICATE: "b", OBJECT: "c" };
db.put(RETURN, function(err) {
  // ..
});

结论

你可能已经注意到我不是关于图表的超级英雄。但这是我最初的研究，我试图得到一个概述。我假设那里有很多人想问我和我一样的问题但是没有时间。我希望这篇文章能够帮助很多人，并且会通过评论和答案来改变成为一个完善的概述如何为图表建模数据。

@editors：欢迎你。

@commenters：这是我个人研究的结果 - 如果你也像我一样完成了一次旅程，请回答我为每个我评估过的数据库做的简短摘要（不要＆＃ 39;忘记定位我的4个目标。）

Answer 1

通过任何本机功能（例如流）和高级查询语言（如CYPHER）组合节点式性能的想法实际上非常简洁。

你可能不会得到任何类型的低级API，因为这对于DB作者来说相当罕见，并且据推测，他们的设计模式并不需要。因此，长时间运行的tcp连接应该可以正常运行。

cypher-stream因为要融入所有这一切，而（表面上判断）保持良好的风格。

由于您可能无法进一步搜索，我建议如果需要任何其他功能，请向他发送拉取请求：）

Answer 2

你应该看看Gundb https://github.com/amark/gun 它是开源的，有一个非常活跃和有帮助的首席开发人员。

加入我们https://gitter.im/amark/gun

什么（in_memory）图表数据库，如果建模数据是专注的

2 个答案: