我近期发的博客“本地多模型的竞争”在 HN 和其他频道上引发了人们强烈的兴趣。就如预期的那样，社区里立刻建议改进公布的代码库，并且我也已经公布了几次更新（这里要特别感谢 Hans-Peter Grahsl，Aseem Kishore，Chris Vest 和 Michael Hunger）。
下面是最新的特性图表：
此次试验旨在表明多模型能成功地与那些在自己的地盘只关注性能与内存消耗的特殊玩家竞争。因此，不少读者对是否该包括 OrientDB 或者其他著名的本地多模型数据库有疑问也就不让人惊讶了。
我们想要让多模型变得更加强大，所以我的同事和我立刻开始给了 OrientDB 一个 Spin。有个官方支持的 node.js 驱动 Oriento 通过使用快速二进制协议和 OrientDB，很容易地就提供给我们用于比较手头上 SQL 方言所需一切 。
但是，结果却不如我们预期的那样好。很明显，我在使用 OrientDB 的方式上出了点错误。所以我请求 OrientDB 的用户帮我检查，不过他们也没能立即指出问题所在。所以，我很希望看到有人能提出一些建议，并且会尽快公布更新的结果。
结果
废话不多说，直接上结果，这次包括了 OrientDB，同时还有给出的很多建议
很明显，肯定有些事出错了。所以只要有人能提出改善的建议，我都无比感谢。讨论请上 HN。
我们使用 OrientDB 的细节
对 于 OrientDB，我们把配置文件导入一个类中而关系在另一个类中，但是它们也作为一个直接链接储存在 Profile 类的对象节点中（“自由指数邻接”）。所有的查询均作为 SQL 查询发送到数据库中。Oriento 驱动使用的是通常 node.js 风格的承诺（promises）。单文件查询和聚合都原生于 SQL，因此这十分简单明了。对于相邻的查询，我们使用直接链接的 OrientDB 图形扩展。二级相邻的特殊效果对我们来讲是个挑战，但是在外部的帮助下，我们设法找到了一个行之有效的 SQL 查询。在 SQL 的函数调用中，ShortestPath 也直接支持。
Oriento 目前只支持一个到数据库的连接。为了不使需求冲突，我们使用了 25 个驱动实例 —— 让 25 个平行线路连接到服务器。这种改进让性能增色不少。
对于某些原因的猜测
正 如之前说的，我们不知道这到底是什么情况。我们简单地看了下代码（开源版本）。跟 ArangoDB 和 Neo4j 相反，似乎 OrientDB 采用了 Dijkstra 的算法来实现 ShortestPath。这实际上解释了在最短路径测试上的糟糕表现，我们的社会图是高度连接的，并且显示了邻近极点距离的指数增长。
我只能在这里重复，任何有关如何改善这种状况的建议我们都是欢迎的，并且当有新发现的时候我们会立即更新。
我们会执行和以前完全相同的测试，请阅读这里所有的描述。
资源和贡献
本次测试所有的代码都可以从我的 Github 库上下载，所有的数据也已经在 Amazon S3 bucket 上公开发布。Tar 文件中包含了数据库文件和源文件。
https://s3.amazonaws.com/nosql-sample-data/arangodb-2.6.tar.bz2
https://s3.amazonaws.com/nosql-sample-data/mongodb-3.0.3.tar.bz2
https://s3.amazonaws.com/nosql-sample-data/neo4j-community-2.2.2.tar.bz2
https://s3.amazonaws.com/nosql-sample-data/orientdb-community-2.0.9.tar.bz2
我们欢迎任何人测试其他数据库并分享他的结果。
Source：ArangoDB
