nosql - 在图形数据库中进行聚合的想法

Question

我知道肯定有很多人在做这件事。

正在使用 neo4J 处理一个项目。假设我有一个名为 Photo 的实体。现在它出现在互联网上，有一百万人喜欢它。将这百万个点赞放入图表中，然后导航该图表以计算合计，这样我就可以显示计数似乎很愚蠢。当然，索引可以使这更有效，特别是如果索引用于计算聚合(就像它们在 SQL 中一样)，但大量的搜索让我认为情况并非如此。当然，许多聚合只是特定节点的关系计数，但这似乎仍然是错误的(例如，从 Photo 到 Like 事件的图形关系看起来很丑陋)。

也许最好的方法是只使用图形数据库来做它擅长的事情，然后将事件之类的事情放在 SQL 数据库中。一个相反的论点可能是，我可以解决所有这些麻烦，然后想要一个汇总，例如“有多少 friend 的 friend 喜欢这个？”我就回到了图表的后院。

那里的选择似乎是 write some java或一堆密码查询。

Answer 1

罗布

有几个选项，

• 有些人决定最好将图形数据保存在图形中，将原始事件保存在其他一些存储中，只是从事件流中导出更高级别的概念和构造，并将它们具体化在图形中
• 存储聚合数据的二级索引很相似，但可能没有与交易图集成得那么好
• 也可以使用图内结构来表示聚合值或访问模式，René Pickard 用 graphity 表明了这一点实时推文查询。其来源可在 github 中找到。

通常你必须看看你的用例，是阅读所有的喜欢更重要还是只有一小部分喜欢真的很重要，同样重要的是，如果经常阅读它是有意义的聚合它(并保持同步)并从聚合的地方读取它。

由于图表的无模式性质，您还可以改进它 - 这意味着如果您只有几个点赞，那么当您的点赞数量超过一定数量，您可以将其迁移到图像本身的变量中。

这也可能是一种时间驱动的方法，例如图片发布后不久，周围发生了很多事情，所以你宁愿保持最新的计数(记住，毕竟计数相差几个百分点并不重要，所以你也可以懒惰地更新).一段时间后，该图片不再受到那么多关注，只需将点赞计数汇总到一个属性中即可。