JUNG Graph 性能 - 密集图上的 PageRank答案

【问题标题】：JUNG Graph Performance - PageRank on Dense GraphJUNG Graph 性能 - 密集图上的 PageRank
【发布时间】：2014-12-28 22:13:02
【问题描述】：

考虑到我使用的数据，我想知道 JUNG2 和 PageRank 相对较慢的性能是否合理。

给定一个具有约 200 个顶点和约 40000 条边的图，计算该图的 PageRank 大约需要 15 秒。给定一个包含约 900 个顶点和约 800000 条边的图，计算该图的 PageRank 需要将近 5 分钟。

我意识到这些图表非常密集，可能自然需要一段时间来计算。然而，这些图并不是特别大，按照这个速度，一次只能计算一个图的一个小子集是不可能的。（10,000 个顶点和 100,000,000 条边大约需要 8 小时）。

我使用 DirectedSparseGraph 以原始整数作为顶点和边，并且没有边权重。这些显然不是稀疏图，所以也许有更合适的图结构可以使用，对于密集图来说更优化？

我在服务器模式下运行具有大量堆空间的 jvm，并已确认整个图形都适合内存并且没有使用交换。

排序结果正确，总和为1，与Jung源内部和其他地方的测试样例相匹配。

也许有一个更高性能的方法和/或库来解决这个问题？但是，即使它快 10 倍，它似乎具有与边数成正比的时间复杂度这一事实是否意味着我很快就会超过 whatever 方法的限制我在用吗？

例如，我考虑过完全跳过图形方法并使用矩阵来表示转换概率，这可能会提供显着的提升。但是 - PageRank 并不是我唯一感兴趣的算法。如果我开始推出自己的方法，可以解决一个问题并引入其他几个问题。

另外，我使用的是双核 1Ghz 的慢速机箱，因此，您的数字可能会好很多（比如我的第一个示例中的 4-5 秒），但重点是成立的。我主要担心的是代码是否预计会以数量级的速度更快地运行，或者预计会以对数方式扩展。

无论如何，感谢您的见解。

【问题讨论】：

【解决方案1】：

tl;dr：渐近地说，这是 PageRank 算法的固有限制。

任何想要考虑所有边的算法都将具有 Omega(|E|) 的时间复杂度。任何试图测量全局拓扑属性的算法（例如，特征向量测量，如 PageRank）都必须至少查看每条边一次。

您可以通过更改 Graph 实现来通过一些常数来提高性能，但最终在密集图上做一些事情往往会很昂贵。

框架问题：您的图表的语义是什么，您希望从中学习什么计算PageRank？你想解决什么问题？

【讨论】：

我正在对正文中的句子进行排名，其中节点是句子，边缘是它们的语义相似性。可以想象，在我达到页面排名之前，nlp 处理就已经很昂贵了。我可以通过消除不太可能在最终结果中占高分的低得分边缘来显着减少边缘。另外...我正在使用具有 2(Vn) 个边的有向图来说明每个原点顶点的不同权重。这可以通过覆盖您在相关问题中建议的 getEdgeWeights 来改进。
换句话说......似乎我唯一的选择是通过任何必要的方式减少边数，以便计算任何大图。但我想知道如何计算非常大的图表？只用硬件解决问题？
我同意全对 NLP 可能比 PR 计算贵很多。要减少边缘，您可以尝试对句子进行聚类，如果您有某种方法不是 O(N)，然后计算聚类内边缘。不确定为这种网络计算 PR 有什么有趣的地方，但那是你的问题。 :)
关于大图的计算，有两个基本的答案：（1）大的完整图非常罕见（对于非常多的节点来说是不切实际的）和（2）是的，在这种情况下投入资源的问题对于大图是必要的。对于稀疏图，计算通常至少在某种程度上是可并行的，尽管管理图算法的并行性本身就是一件棘手的事情。