使用MongoDB作为我们的主数据库，是否应该使用单独的图数据库来实现实体之间的关系? [英] Using MongoDB as our master database, should I use a separate graph database to implement relationships between entities?

问题描述

我们目前正在内部为一家专业公司实施类似 CRM 的解决方案.由于存储信息的性质以及信息的不同值和键，我们决定使用文档存储数据库，因为它非常适合这些目的(在这种情况下我们选择了 MongoDB).

We're currently in the process of implementing a CRM-like solution internally for a professional firm. Due to the nature of the information stored, and the varying values and keys for the information we decided to use a document storage database, as it suited the purposes perfectly (In this case we chose MongoDB).

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

As part of this CRM solution we wish to store relationships and associations between entities, examples include storing conflicts of interest information, shareholders, trustees etc. Linking all these entities together in the most effective way we determined a central model of "relationship" was necessary. All relationships should have history information attached to them ( commencement and termination dates), as well as varying meta data; for example a shareholder relationship would also contain number of shares held.

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

As traditional RDBMS solutions didn't suit our former needs, using them in our current situation is not viable. What I'm trying to determine is whether using a graph database is more pertinent in our case, or if in fact just using mongo's built-in relational information is appropriate.

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

The relationship information is going to be used quite heavily throughout the system. An example of some of the informational queries we wish to perform are:

• 获取作为xyz limited"客户"的公司的所有主要联系人"
• 获取john"是股东的公司的所有其他股东"
• 获取abc limited"的客户"和trust us bank limited"的客户实体的所有主要联系人"

鉴于这种关系的树"结构，使用图形数据库(例如 Neo4j)是否更合适?

Given this "tree" structure of relationships, is using a graph database (such as Neo4j) more appropriate?

推荐答案

Mike,

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

you should be able to store your relationship data in the graph database. Its high performance on traversing big graphs comes from locality, i.e. you don't run queries globally but rather start a a set of nodes (which equal documents in your case, which are looked up by an index. you might even store start-node-ids for quick access in your mongo documents). From there you can traverse arbitrarily large paths in constant time (wrt data set size).

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

What are your other requirements (i.e. data set size, # of concurrent accesses etc, relationship/graph complexity).

您的查询非常适合图形数据库，并且很容易用其术语表达.

Your queries are a really good fit for the graph database and easily expressable in its terms.

我建议您只使用像 neo4j 这样的 graphdb 并快速访问您的域以验证一般可行性，并在投资第二种技术之前找出您想要回答的其他问题.

I'd suggest that you just grab a graphdb like neo4j and do a quick spike with your domain to verify the general feasibility and also find out additional questions you would like to have answered before investing in the second technology.

附言如果您还没有开始，您也可以采用纯 graphdb 方法，因为图数据库是文档数据库的超集.无论如何，您宁愿在您的情况下谈论域，而不仅仅是通用文档.(例如，structr 是建立在 Neo4j 之上的 CMS).

P.S. If you hadn't started yet, you could also have gone with a pure graphdb approach as graph databases are a superset of document databases. And you'd rather talk domain in your case anyway than just generic documents. (E.g. structr is a CMS built on top of Neo4j).

这篇关于使用MongoDB作为我们的主数据库，是否应该使用单独的图数据库来实现实体之间的关系?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！