结合图形数据库和 RDBMS

Question

为一个应用程序实现两个或多个数据库是否设计不好/困难？

例如，假设我有User一些想要存储到关系数据库中的对象。这些“用户”对象彼此之间存在关系，并且有用户提要（想想 Twitter / Facebook），我想存储这些关系以便能够找到朋友的朋友，看看我对一系列信息的“深入”程度提要等。这些关系将存储在图形数据库中。

有没有更好的方法来解决这个问题，或者使用图形数据库进行关系和使用关系数据库进行数据存储是最好的解决方案？

Answer 1

免责声明：我还没有使用过 Neo4j 的企业版，因此​​它可能具有我不知道的功能可以帮助您。

如果您可以将所有内容保留在 Neo4j 中，那是最好的，因为它在多个方面都保持较低的复杂性，包括数据建模、保持数据同步以及保持查询简单和原子，而不是在单独的数据库之间拆分它们。

了解您使用 RDBMS 的要求以及这些要求是否证明了上面介绍的复杂性是合理的，这将有所帮助。

如果您决定这样做，那么您可以选择高数据冗余，或者使用更骨架的 Neo4j 数据库，该数据库仅保留 ID、关系和最少的数据。

通过高数据冗余，在 Neo4j 中镜像大多数（如果不是全部）数据，那么您就会增加保持数据库之间所有内容同步和一致的复杂性（一点也不简单）。这可以让您通过 Neo4j 获得更丰富的查询，因为大多数数据都在同一个数据库中，并且您可以在将来从 RDBMS 中断开并仅使用 Neo4j。但是任何改变两个数据库的查询都不会自动成为原子的......您必须为此在服务器端代码中执行某种强制措施，这可能很棘手。

通过骨架方法，大多数 Neo4j 查询都将具有 ID 输入和 ID 输出。丰富的数据可能不可用，因此您将获取这些 ID，并在这些 ID 上的 RDBMS 上进行选择以获取所需的数据。任何涉及关系和期望返回数据的查询都需要使用两个数据库，这对开发人员来说可能很麻烦，但在服务器端代码上可能没问题。您将避免同步问题，也可能避免原子性问题，因为两个数据库之间的公共数据将很少。

值得注意的是，有一些解决方案可以按照与您提出的类似的模式与其他数据库集成。

GraphAware 有一个图形辅助搜索的概念，它提供 ElasticSearch 和 neo4j 之间的集成，尽管这主要是为了满足丰富的可搜索性的要求。这可以用于提供 ElasticSearch 作为纯粹的搜索引擎，也可以让您将所有数据存储在 ES 中，并根据 Neo4j 中的关系数据增强或影响结果。

Answer 2

我不同意所有那些说不应该在一个项目中使用两种不同类型的数据库的人的观点。我已经构建系统 30 多年了，在我有机会参与的所有企业系统中，我们总是为项目的每个部分使用最好的工具。将对象/图形数据库与关系数据库和文档数据库组合到同一个项目中是很常见的。我们将支持对象/图数据库中的高速链接分析，然后跳出关系数据库获取元数据，然后跳入文档数据库获取原始源信息。或者您可以反转整个过程并从文档搜索开始，然后进行高速链接分析。

在许多情况下，这是一个被迫使用 EB 级遗留关系数据的问题，但需要添加新功能，例如高速链接分析。我们不需要尝试将所有关系数据移植到对象/图形数据库，而是只移动我们需要的信息。

不要将方钉强行插入圆孔中。为项目的每个部分使用最好的工具。