多语言持久性与图形数据库用于关系是否是一个好的想法？

Question

我想知道是否值得使用图形数据库来专门处理关系。我打算使用关系型数据库来存储实体，如“用户”，“页面”，“评论”，“帖子”等。但在大多数基于社交图的工作负载中，我需要进行深度遍历，而关系型数据库不适合处理这种情况，并且涉及缓慢的连接。例如：评论 -(made_in)-> 帖子 - (made_in) -> 页面等等。我正在考虑做类似于以下内容的事情：用户ID：1，查询：获取用户ID 1的所有关注者。使用Neo4j查询名为“follows”的所有出边以获取具有ID 1的用户节点，然后使用ID列表在Users表上查询它们：SELECT * FROM users WHERE user_id IN（ids）。这样会很慢吗？

我看到了这个问题使用MySQL和Neo4j是否是一个好主意？，但仍然不明白为什么正确答案说那不是一个好主意。

谢谢

- Luccas

---

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

Answer 1

使用Neo4j对于像您的应用程序这样需要进行深度遍历的技术来说是一个很好的选择。之所以是个好选择，有两个原因：一是Cypher语言使这样的查询非常容易。第二个原因是由于数据在数据库中的结构方式，深度遍历会非常快。

为了获得这两个优势，您将希望在图形中同时拥有关系和人（作为节点）。然后，您将能够执行以下的朋友的朋友查询：

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

以及以下的朋友的朋友的朋友查询：

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

...等等。（对于帖子和评论也是同样的想法，只需替换名称即可）。

使用MySQL和Neo4j并行使用没有问题，但我不会以这种特定的方式去做，因为代码会更加复杂，并且在Neo4j和MySQL之间跳转会浪费太多时间。

祝您好运！

Philip

- Philip Rathle

Answer 2

总的来说，数据库/系统/层次结构越多，整个设置和操作就会越复杂。 想想所有那些任务，比如同步、导入/导出、备份/归档等，在数据库规模增长时成本变得非常昂贵。

只有在具有专用和专业化数据库的好处超过处理多个数据存储的缺点时，人们才使用多语言持久性。例如，如果您拥有大量与用户相关联的数据项（例如活动或交易日志），则可能不明智将所有信息存储在图形数据库中，因为您只对数据项之间的连接感兴趣。 因此，最好仅将关系存储在图形中（节点只有指向其他数据库的指针），并且将每个项目的数据存储在K/V存储或类似存储器中。

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

- Axel Morgner

Answer 3

正如其他答案所示，将Neo4j用作您的单一数据存储是更可取的。然而，在某些情况下，您可能已经有另一个数据库支持您的产品，这时可能没有太多选择余地。我想补充说，如果是这种情况，将neo4j作为您的次要数据库确实可行（我们正在使用此模式运行产品）。您必须努力弄清楚您期望从neo4j获得哪些功能，需要哪种类型的数据，如何保持数据同步以及遭受不总是实时结果的后果。我们的大多数用例可以使用接近实时的结果，所以我们很好。但对于您的产品可能并非如此。尽管如此，在我看来，使用此模式中的neo4j仍然比没有运行它更可取。我们能够因此产生很多图形化的东西。

- Luanne