NetworkX 有哪些可扩展性问题？答案

【问题标题】：What scalability issues are associated with NetworkX?NetworkX 有哪些可扩展性问题？
【发布时间】：2011-12-20 04:48:12
【问题描述】：

我对具有数百万个节点和数千万条边的大型网络的网络分析感兴趣。我希望能够做一些事情，比如解析多种格式的网络、查找连接的组件、检测社区以及运行 PageRank 等中心性度量。

我被 NetworkX 所吸引是因为它有一个很好的 api、良好的文档，并且多年来一直在积极开发中。另外，因为它是在 python 中的，所以应该可以快速开发。

在最近的一次演示中（幻灯片可在 github here 上找到），声称：

与许多其他工具不同，NX 旨在处理大规模数据与现代问题相关...NX 中的大多数核心算法都依赖于极快的遗留代码。

演示文稿还指出 NetworkX 的基本算法是用 C/Fortran 实现的。

但是，查看源代码，看起来 NetworkX 主要是用 python 编写的。我对源代码不太熟悉，但我知道 NetworkX 使用 numpy 进行繁重工作的几个示例（而后者又使用 C/Fortran 进行线性代数）。例如文件networkx/networkx/algorithms/centrality/eigenvector.py使用numpy计算特征向量。

有谁知道这种调用像 numpy 这样的优化库的策略是否真的在整个 NetworkX 中普遍存在，还是只有少数算法可以做到？还有谁能描述与 NetworkX 相关的其他可扩展性问题？

NetworkX 首席程序员的回复 我在 NetworkX 邮件列表上提出了这个问题，Aric Hagberg 回复道：

NetworkX 中使用的数据结构适用于扩展到大问题（例如数据结构是邻接表）。这算法具有各种缩放属性，但您可以使用其中一些提及是可用的（例如PageRank，连接的组件，是线性的边数的复杂性）。

此时 NetworkX 是纯 Python 代码。邻接结构使用 Python 字典编码，提供了极大的灵活性以牺牲内存和计算速度为代价。大图将占用大量内存，最终会耗尽。

NetworkX 确实将 NumPy 和 SciPy 用于主要是基于线性代数。在这种情况下，图形表示（复制）作为使用 NumPy 矩阵或 SciPy 的邻接矩阵稀疏矩阵。这些算法可以从遗留的 C 和在 NumPy 和 SciPY 中使用的 FORTRAN 代码。

【问题讨论】：

目前我自己似乎无法检查源代码。但无论如何，请考虑：80% 的时间可能花在 20% 的代码上。 Mercurial主要是用 Python 编写的，但与主要是 C 的 Git 相比，我还没有听到有人抱怨它的速度。
是的，但我也担心内存问题。 networkx 中的图形表示是一个 python 库。这是否意味着我只能将较小的图形放入内存中？

标签： python graph social-networking libraries

【解决方案1】：

这是一个老问题，但我认为值得一提的是graph-tool 具有与 NetworkX 非常相似的功能，但它是在 C++ 中使用模板实现的（使用 Boost Graph Library），因此速度更快（ up to two orders of magnitude) 并使用更少的内存。

免责声明：我是graph-tool的作者。

【讨论】：

我尝试了图形工具。它确实更快，但使用起来有点难看。 API 感觉不像 Python。
是的，您可以使用任何笔记本电脑轻松处理。
@user1938107 它需要对库进行大量更改，而我什至没有 Windows 机器。
@user1938107 我宁愿花 10 美分给你安装合适的操作系统...
@opt C++ 在 2019 年仍然比纯 Python 快几个数量级，所以答案是肯定的。该项目根本没有被放弃。那个github页面不是官方的，只是一些随机的fork。该网站是最新的，gitlab 页面也是如此。

【解决方案2】：

你的大问题将是记忆。 Python 只是无法处理数以千万计的对象，而无需在您的类实现中跳过障碍。许多对象的内存开销太高，你达到 2GB，32 位代码将无法工作。有很多方法可以绕过它——使用槽、数组或 NumPy。应该没问题，因为 networkx 是为提高性能而编写的，但如果有一些东西不起作用，我会检查你的内存使用情况。

至于缩放，算法基本上是图表中唯一重要的事情。如果图算法做错了，它们往往真的会出现丑陋的缩放，而且它们在 Python 中与任何其他语言一样有可能被正确地完成。

【讨论】：

【解决方案3】：

networkX 大部分是用 python 编写的这一事实并不意味着它不可扩展，也不意味着它是完美的。总是有一个权衡。如果您在“机器”上投入更多资金，您将获得所需的可扩展性以及使用 pythonic 图形库的好处。

如果没有，还有其他解决方案（here 和 here），它们可能会消耗更少的内存（基准测试，我认为 igraph 完全由 C 支持，所以它会），但你可能会错过 Python 的感觉NX。

【讨论】：

这部分回答了我的问题。但我也想知道 NetworkX 的许多“核心”算法是否如声称的那样在 C/Fortran 中实现。
我对（当前）源代码进行了一些调查，但没有发现 C/Fortran 实现。看来里面的一切都是纯python……
感谢您的浏览。请记住，如果调用 numpy，那么（取决于系统配置）numpy 可能会使用 LAPACK 或其他优化的线性代数包。我不太熟悉 NetworkX 实际使用 numpy 的频率（这是我的问题），但我知道几个例子。例如networkx/networkx/algorithms/centrality/eigenvector.py中的使用numpy来查找特征向量。
作为 igraph 的作者加入，这是上面引用的库之一。 igraph 的核心是用 ~90% C 和 ~10% C++ 实现的，我已经使用 igraph 处理了具有 ~200 万个节点和 ~700 万条边的图，没有问题。它有一个 Python 接口，因此您可以从 Python 中使用它，但由于它的 C 传统，Python API 不如 NetworkX 优雅。例如，节点和边在 igraph 中总是由整数标识（因为它在 C 级别上更容易处理），并且您必须使用顶点/边属性将它们映射到您的实际对象。