使用图表数据库进行多语言持久性关系是一个好主意?

时间:2013-04-05 20:39:08

标签: database relational-database neo4j graph-theory

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

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

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

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

我在想这样的事情:

示例:

用户ID:1

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

  • 查询Neo4j,了解id为<1 li>的节点用户名为“follow”的所有输出边
  • 使用ID列表在Users表中查询它们:

    SELECT * 来自用户 WHERE user_id IN(ids)

这很慢吗?

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

由于

3 个答案:

答案 0 :(得分:2)

使用Neo4j是像您这样的应用程序的一个很好的技术选择,需要深度遍历。它是一个很好的选择的原因是双重的:一个是Cypher语言使这样的查询非常容易。第二个是深度遍历很快发生,因为数据在数据库中的结构方式。

为了获得这两种好处,您需要在图表中同时拥有关系和人员(作为节点)。然后,您将能够按如下方式进行朋友的查询:

START john = node:node_auto_index(name ='John') MATCH john - [:friend] - &gt;() - [:friend] - &gt; fof 返回john,fof

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

START john = node:node_auto_index(name ='John') MATCH john - [:朋友] - &gt;() - [:朋友] - &gt;() - &gt; [:朋友] - &gt; fofof 返回john,fofof

......等等。 (对帖子和评论也一样,只需替换名称。)

将Neo4j和MySQL一起使用很好,但我不会这样做,因为代码会复杂得多,而且你会在Neo4j和MySQL之间跳过太多时间。

祝你好运!

菲利普

答案 1 :(得分:1)

通常,您获得的数据库/系统/层越多,整体设置和操作就越复杂。

考虑所有这些任务,例如同步,导出/导入,备份/存档等,如果您的数据库大小增加,这些任务会非常昂贵。

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

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

答案 2 :(得分:1)

正如其他答案所示,使用Neo4j作为您的单个数据存储更可取。但是,在某些情况下,如果您的产品背后已有另一个数据库,则可能没有太多选择。我想补充一点,如果是这种情况,运行neo4j作为辅助数据库确实有效(我工作的产品在这种模式下运行)。你必须更加努力地弄清楚你对neo4j的期望是什么,你需要什么样的数据,如何保持数据同步以及不总是实时结果的后果。我们的大多数用例都可以使用近乎实时的结果,所以我们没问题。可能不是您的产品的情况。不过,对我来说,在这种模式下使用neo4j仍然比没有它时运行更好。 由于它,我们能够产生很多图形化的东西。