我们正在启动一个新项目，并为我们的案例寻找合适的存储解决方案。对存储的主要要求如下:
- 能够支持高度灵活和连接的域
- 能够在ms 中支持诸如"给予该项目的所有子项目和链接到该子项目的项目"之类的查询
- 全文检索
- 临时分析
- 固态读写性能
- 可伸缩性(因为我们想提供我们产品的Saas版本)
首先，我们消除了所有的RDBMS，因为我们有非常灵活的模式，也可以由客户更改(添加新字段等)。因此，在任何RDBMS中支持这样的解决方案都可能成为一场噩梦……于是我们谈到了NoSQL。我们评估了几种NoSQL存储引擎，并选择了3个最合适的(我们认为)。
MongoDB
优点:
- 适合存储具有灵活结构的聚合(如我们所拥有的))
- 可伸缩性/成熟度/支持/社区 在以前的项目中使用MongoDB的经验
- 驱动程序，云支持
- Analitycs
- 价格(免费)
缺点:
- 不支持关系(对我们来说非常重要，因为我们有很多连接的项目)
- 连接数据检索缓慢(所有连接都发生在app中)
Neo4j:
优点:
- 支持连接数据建模，灵活性高
- 快速检索互联数据
- 驱动程序，云支持
- 成熟度/支持/社区(如果我们与其他图表数据进行比较)
缺点:
- 不支持聚合存储(我们希望聚合存储在一个顶点而不是多个顶点)
- 可扩展性(据我所知，现在所有数据都在其他服务器上复制)
- Analitics吗?
- 写性能?(阅读几个客户抱怨写性能的博客)
- 价格(不是免费的商业软件)
OrientDB
优点:
- 似乎OrientDB有我们需要的所有功能(聚合和graphdb在一个解决方案)
- 价格(看起来不是免费的)
缺点:
- 不成熟(与其他国家相比)
- 技术背后的小公司(特别是一个主要贡献者)，所以关于支持，已知问题等的问题
- 很多功能，但它们工作得很好吗
所以现在，as的主要困境是在Neo4j和OrientDB之间(MongoDb是第三个选择，因为它缺乏关系，这在我们的案例中非常重要-这篇文章解释了陷阱)。我已经搜索了这些db的任何基准/比较，但它们都是旧的。这是一个功能比较http://vschart.com/compare/neo4j/vs/orientdb。所以现在我们需要从已经使用过这些dbs的人那里得到建议，选择什么。提前感谢。
我认为每一个都有有趣的权衡:
- MongoDB不做图形;
- Neo4j的节点是平面键值属性;
- OrientDB强制您在图形和文档之间进行选择(不能同时进行)。
所以你的选择是在图存储(neo4j或orient)和文档存储(mongo或orient)之间。我的感觉是MongoDB是领先的文档存储，Neo4j是领先的图形数据库，这将导致我选择其中之一。但由于连接性很重要，我倾向于图形数据库并采用Neo4j。
Neo4j的可扩展性得到了证明:它被用于比Facebook更大的图表，以及像沃尔玛和EBay这样的大公司。所以，如果你的问题是在Facebook社交图谱的0-120%之间，Neo4j可以帮你解决。使用Neo4j写吞吐量很好——我在笔记本电脑上每秒有超过2000个适当的ACID事务，我可以很容易地排队写，把它乘出来。
其他一切都是相当平等的:您可以选择为其中的任何一个付费，或者在他们的开源许可下自由使用它们(包括Neo4j，如果您可以使用GPL/AGPL)。Neo4j的付费许可证有很大的支持(高达24x7x365，全球1小时周转)，而OrientDB的支持相当暗淡(仅在欧盟白天周转4小时)，我想MongoDB也有很好的支持(尽管我还没有检查过)。
简而言之，Neo4j成为连接数据的顶级数据库是有原因的:它太棒了!
吉姆纠正关于mongoDB的一些误解
- 关系通过链接到其他文档或嵌入它们来支持。请参阅mongoDB文档中的数据建模介绍了解详细信息。不过，你可能会被迫进行常态化交易，以对抗速度。然而，在某些用例中，与关系相比，嵌入是更好的解决方案。想想订单:当嵌入订单项目及其价格时，您不需要为每一个销售过的产品创建价格历史表。
- 不支持join。你可以通过嵌入文档来规避，如上所述。 MongoDB可以用于树结构。详细信息请参见使用物化路径的模型树结构。这种方法似乎是为上述用例实现树形结构的最合适的方法。另一种选择可能是祖先数组，这取决于你的需要。
话虽这么说，mongoDB可能在一个基本要求上失败，尽管这实际上取决于您如何定义它:特设分析。我的建议是使用面向文档的方法对预期的数据结构进行建模(与在面向文档的数据库上使用关系方法相反)，并使用虚拟数据对一个可能的分析用例进行原型化。