使用图形数据库进行关系的多语言持久性是个好主意吗？答案

【问题标题】：Polyglot persistece with a graph database for relationships is a good ideia?使用图形数据库进行关系的多语言持久性是个好主意吗？
【发布时间】：2013-04-06 11:03:17
【问题描述】：

我想知道是否值得使用图形数据库专门处理关系。

我假装使用关系数据库来存储“用户”、“页面”、“评论”、“帖子”等实体。

但在典型的基于社交图的工作负载的大多数情况下，我必须进行深度遍历，关系不好处理并且涉及缓慢的连接。

示例：评论 -(made_in)-> 发布 -(made_in)-> 页面等...

我正在考虑做这样的事情：

示例：

用户 ID：1

查询：获取user_id 1的所有关注者

为 ID 为 1 的节点用户查询所有名为“follows”的输出边的 Neo4j
使用 id 列表在用户表上查询它们：

选择 * 来自用户 WHERE user_id IN (ids)

这么慢吗？

我已经看到这个问题Is it a good idea to use MySQL and Neo4j together?，但仍然无法理解为什么正确的答案说这不是一个好主意。

谢谢

【问题讨论】：

“好主意”是非常主观的。如果您的主要目标是性能，那么我会说这是一个坏主意。将所有用户数据存储在 neo4j 中会显着提高效率。您是否有使用多语言系统的特定用例？

标签： database relational-database neo4j graph-theory

【解决方案1】：

对于像您这样需要深度遍历的应用程序，使用 Neo4j 是一种很好的技术选择。它是一个不错的选择的原因有两个：一个是 Cypher 语言使此类查询非常容易。第二个是深度遍历发生得非常快，因为数据在数据库中的结构方式。

为了同时获得这两个好处，您需要在图表中同时包含关系和人员（作为节点）。然后您就可以进行好友好友查询，如下所示：

START john=node:node_auto_index(name = 'John') 匹配 john-[:friend]->()-[:friend]->fof RETURN john, fof

和朋友的朋友的朋友查询如下：

START john=node:node_auto_index(name = 'John') 匹配 john-[:friend]->()-[:friend]->()->[:friend]->fofof RETURN john, fofof

...等等。（帖子和 cmets 的想法相同，只需替换名称即可。）

将 Neo4j 与 MySQL 一起使用很好，但我不会以这种特殊方式这样做，因为代码会复杂得多，而且您会在 Neo4j 和 MySQL 之间浪费太多时间。

祝你好运！

菲利普

【讨论】：

【解决方案2】：

一般来说，您拥有的数据库/系统/层越多，整体设置和操作就越复杂。

想想所有这些任务，如同步、导出/导入、备份/存档等，如果您的数据库规模扩大，这些任务就会变得非常昂贵。

只有在拥有专用和专用数据库的好处超过必须处理多个数据存储的缺点时，人们才会使用多语言持久性。 F.e.如果您有大量数据项（活动或事务日志 f.e.），每个都与用户相关，则可能会出现这种情况。如果您只对数据项之间的连接感兴趣，那么将所有信息存储在图形数据库中可能是没有意义的。所以你最好只存储图中的关系（节点只有一个指向另一个数据库的指针），以及 K/V 存储等中的每个项目的数据。

对于您的示例用例，我只会选择一个数据库，即 Neo4j，因为它是一个图表。

【讨论】：

【解决方案3】：

正如其他答案所示，最好使用 Neo4j 作为您的单一数据存储。但是，在某些情况下，如果您的产品背后已经有另一个数据库，则可能没有太多选择。我想补充一点，如果是这种情况，运行 neo4j 作为您的辅助数据库确实可以工作（我工作的产品在这种模式下运行）。您确实必须更加努力地弄清楚您期望从 neo4j 中获得什么功能，需要什么样的数据，如何保持数据同步以及遭受不总是实时结果的后果。我们的大多数用例都可以处理近乎实时的结果，所以我们很好。您的产品可能并非如此。尽管如此，对我来说，在这种模式下使用 neo4j 仍然比没有它运行更可取。因此，我们能够制作出许多非常棒的作品。

【讨论】：