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

Question

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

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

也许最好的方法是仅将图形数据库用于它的好处，然后将它们用于事件之类的事情，将它们放入 SQL 数据库中。一个反驳的论点可能是，我可能会遇到所有麻烦，然后想要一个汇总，比如“有多少朋友的朋友喜欢这个？”我就回到了图表的后院。

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

Answer 1

罗伯，

有几种选择，

• 有些人认为最好将图形数据保留在图形中，将原始事件保留在其他一些存储中，然后从事件流中派生出更高级别的概念和构造，并将它们具体化到图形中
• 存储聚合数据的二级索引很相似，但可能与事务图集成得不太好
• 还可以使用图内结构来表示聚合值或访问模式，René Pickard 通过graphity 实时推文查询展示了这一点。源代码在github

通常您必须查看您的用例，阅读所有喜欢更重要还是只有少数喜欢真正重要，计数也是如此，如果经常阅读它是有意义的聚合它（并保持同步）并从聚合位置读取它。

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

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