3

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

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

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

那里的选择似乎是编写一些 java或一堆密码查询。

4

1 回答 1

4

抢，

有几种选择，

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

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

由于图表的无模式特性，您还可以改进 - 这意味着如果您只有几个喜欢，当您的喜欢计数超过某个数量时，通过计算关系来计算该数字会更快、更明智您可以将其迁移到图像本身的变量中。

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

于 2012-05-16T19:15:33.260 回答