我们目前正在为专业公司内部实施类似CRM的解决方案。由于存储的信息的性质，以及信息的变化值和密钥，我们决定使用文档存储数据库，因为它完全符合目的（在本例中我们选择了MongoDB）。
作为CRM解决方案的一部分，我们希望存储实体之间的关系和关联，例子包括存储利益冲突信息，股东，受托人等。以最有效的方式将所有这些实体联系在一起，我们确定了“关系”的中心模型“是必要的。所有关系都应附有历史信息（开始和终止日期），以及不同的元数据;例如，股东关系也包含持有的股份数量。
由于传统的RDBMS解决方案不符合我们以前的需求，因此在目前的情况下使用它们是不可行的。我想要确定的是，在我们的情况下使用图形数据库是否更为相关，或者实际上只是使用mongo的内置关系信息是合适的。
关系信息将在整个系统中大量使用。我们希望执行的一些信息查询的示例是：
鉴于这种“树”结构的关系，使用图形数据库（如Neo4j）更合适吗？
答案 0 :(得分：8)
麦克，
您应该能够将关系数据存储在图形数据库中。它在遍历大图时的高性能来自于本地，即你不是全局运行查询而是启动一组节点（在你的情况下它们等于文档，由索引查找。你甚至可以存储起始节点 - 用于快速访问mongo文档的ID）。从那里，您可以在恒定时间（wrt数据集大小）中遍历任意大的路径。
您的其他要求是什么（即数据集大小，并发访问次数等，关系/图复杂度）。
您的查询非常适合图表数据库，并且可以轻松表达。
我建议您只需抓住像neo4j这样的graphdb并快速加入您的域名以验证一般可行性，并在投资第二项技术之前找出您想要回答的其他问题。
P.S。如果你还没有开始，你也可以使用纯graphdb方法，因为图形数据库是文档数据库的超集。而且你宁愿在你的案例中谈论域，而不仅仅是通用文档。 （例如structr是建立在Neo4j之上的CMS）。
答案 1 :(得分：6)
MongoDB中的文档非常类似于Neo4j中的节点，减去了关系。它们都具有键值属性。如果您已经选择使用MongoDB，则可以使用Neo4j存储关系，然后在应用程序中桥接存储。如果您正在选择新技术，您可以使用Neo4j获取所有内容，因为节点可以保存属性数据，就像文档一样。
至于关系部分，Neo4j非常适合。你有一个图表，而不是无关的文件。使用图形数据库在这里非常有意义，并且示例查询在其上编写了图形。
老实说，找出适合你的最佳方法是做一个低成本，高价值的PoC。
免责声明：我为Neo Technology工作。
答案 2 :(得分：1)
和mongodb呆在一起。有两个原因 - 1.如果你能降低复杂性，最好留在同一个域中2.例如，mongodb非常适合查询，比redis需要更少的工作。
答案 3 :(得分：1)
我们最终使用了两者，我们正在为运输网络实施搜索引擎。
一旦超越1或2个“链接”，尝试在MongoDB中实现关系可能会变得难以处理。基本上你会将对象存储在一个数组中，如果你想实现双向关系，那么你必须实现两个单独的链接。在Mongo中，实体（或“链接”）的“指针”只是另一个文本属性（可以被不同地解释），它不是像Neo4j中的关系那样的第一类对象。
因此我们决定使用Neo4j存储关系，使用MongoDB存储其他所有内容。然后，挑战使这两家商店保持同步。
我们正在使用名为“MongoConnector”的10gen实验室项目，该项目是使MongoDB与其他商店保持同步的机制。该项目目前不受支持，但代码可用：
http://blog.mongodb.org/post/29127828146/introducing-mongo-connector
MongoConnector使用副本机制来实现同步。基本上，您正在监视MongoDB OpLog，并且您正在为任何upsert（更新或插入）和删除实现回调。这个实现在MongoConnector中称为“DocumentManager”。我们结束了实现Neo4jDocumentManager。
在查询方面，我们发现Neo更适合“朋友的朋友”类型的查询，而MongoDB更适合于通用查询，即。处理日期的每个字段或范围查询。
我一直计划发表演讲和博客文章，但我还没有完成：
http://www.meetup.com/graphdb-boston/events/91703472/
此解决方案存在一些缺点，例如，如果进程停止或同步缓慢（不是实时），则会导致失去同步。