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

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

使用neo4J处理项目。假设我有一个叫做Photo的实体。现在它出现在互联网上，有一百万人喜欢它。把那一百万个喜欢放进一个图表，然后导航该图表来计算总喜欢数，这样我就可以显示计数了，这看起来很愚蠢。当然，索引可以提高效率，特别是当索引用于计算聚合时（就像在SQL中一样），但我认为情况并非如此。当然，许多聚合只是特定节点上的关系计数，但这似乎仍然是错误的（例如，从照片到类似事件的图形关系看起来很难看）

也许最好的方法是只使用graph db来表示它的用途，然后对于事件之类的事情，将它们放在SQL db中。一个相反的论点可能是，我可能会费尽周折，然后想要一个像“有多少朋友的朋友喜欢这个”这样的汇总，而我又回到了图表的后院

现在的选择似乎是要么是一堆密码查询。

Rob

有几种选择

• 有些人认为最好将图形数据保存在图形中，将原始事件保存在其他存储中，然后从事件流中派生出更高级别的概念和结构，并在图形中具体化这些概念和结构
• 存储聚合数据的二级索引类似，但可能没有与事务图很好地集成
• 勒内·皮卡德（RenéPickard）通过实时推特查询表明，也可以在图形结构中表示聚合值或访问模式。其来源可在中找到

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

由于图形的无模式性质，您也可以对其进行改进，这意味着如果您只有几个喜欢，则通过计算关系来计算该数字会更快、更合理，当您的喜欢计数超过某个数字时，您可能会将其迁移到图像本身的变量中

---

这也可能是一种时间驱动的方法，例如，图片发布后不久，周围会发生很多事情，因此您希望保持最新的计数（请记住，如果该计数毕竟相差几个百分点，则这并不重要，因此您也可以懒洋洋地进行更新）。过了一段时间，这张照片再也没有得到那么多的关注，只需将类似的计数聚合到一个属性中就可以了。

嗨，Michael。回答得好，谢谢。我知道问题空间中精确性的所有变幻莫测之处。我主要是在寻找一些想法（正如标题所暗示的）来做一些不会在中等负荷下折叠起来的事情。即使事情可以处理负载，承担完全没有意义的负载也是一个坏主意。我考虑的一个选择是将一些信息注入Vertica这样的列式数据库，因为这样我可以得到有效缓存的愚蠢的快速聚合，而无需管理它们（在存储和缓存中）。谢谢