使用MongoDB作为我们的主数据库,我应该使用单独的图数据库来实现实体之间的关系吗？

我们目前正在为专业公司内部实施类似CRM的解决方案.由于存储的信息的性质,以及信息的变化值和键,我们决定使用文档存储数据库,因为它完全符合目的(在本例中我们选择了MongoDB).

作为这个CRM解决方案的一部分,我们希望存储实体之间的关系和关联,例子包括存储利益冲突信息,股东,受托人等.以最有效的方式将所有这些实体链接在一起我们确定了"关系"的中心模型是必要的.所有关系都应附有历史信息(开始和终止日期),以及不同的元数据; 例如,股东关系也包含持有的股份数量.

由于传统的RDBMS解决方案不适合我们以前的需求,因此在我们目前的情况下使用它们是不可行的.我想要确定的是在我们的情况下使用图形数据库是否更为相关,或者实际上是否只使用mongo的内置关系信息是合适的.

关系信息将在整个系统中大量使用.我们希望执行的一些信息查询的示例如下:

获取'xyz limited''客户'公司的所有"关键联系人"

获得"约翰"是股东的公司的所有其他"股东"

获取"abc limited"的"客户"实体的所有"主要联系人",并且是"信任我们银行限制"的客户

鉴于这种"树"结构的关系,是使用图形数据库(如Neo4j)更合适吗？

麦克风,

您应该能够将关系数据存储在图形数据库中.它在遍历大图时的高性能来自于本地,即你不是全局运行查询而是启动一组节点(在你的情况下它们等于文档,由索引查找.你甚至可以存储起始节点 - 用于快速访问mongo文档的ID).从那里,您可以在恒定时间(wrt数据集大小)中遍历任意大的路径.

您的其他要求是什么(即数据集大小,并发访问数量等,关系/图复杂度).

您的查询非常适合图形数据库,并且可以轻松表达.

我建议您只需抓住像neo4j这样的graphdb并快速查看您的域名以验证一般可行性,并在投资第二项技术之前找出您想要回答的其他问题.

PS如果你还没有开始,你也可以使用纯graphdb方法,因为图形数据库是文档数据库的超集.而且你宁愿在你的案例中谈论域,而不仅仅是通用文档.(例如,structr是一个建立在Neo4j之上的CMS).

MongoDB中的文档非常类似于Neo4j中的节点,减去了关系.它们都具有键值属性.如果您已经选择使用MongoDB,则可以使用Neo4j存储关系,然后在应用程序中桥接存储.如果您正在选择新技术,您可以使用Neo4j获取所有内容,因为节点可以保存属性数据,就像文档一样.

至于关系部分,Neo4j非常适合.你有一个图表,而不是无关的文件.使用图形数据库在这里非常有意义,并且示例查询在其上编写了图形.

老实说,找出适合你的最佳方法是做一个低成本,高价值的PoC.

免责声明:我为Neo Technology工作.