压缩图形表示？

Question

我正在开展一个侧面项目，现在涉及编码维基百科页面之间的所有链接。我已将此信息写入磁盘，但编码此图结构所需的内存使用量非常荒谬 - 有数百万个节点和数千万个链接。虽然这种结构确实适合记忆，但我不知道如果有十亿个链接或十亿页，我会怎么做。

我的问题是 - 有没有一种无损压缩图形太大而无法适应内存以便它适合内存的方法？如果没有，是否有一个很好的有损算法，对于某些“结构”的定义，不会从原始图中丢失太多的结构？

Answer 1

链接图和社交图等图表都经过深入研究，它们通常具有统计属性，可实现高效的压缩表示。

例如，其中一个属性是对于传出边缘，邻接列表的差分编码具有低功率分布，即存在许多非常小的值和非常少的大值，因此大多数{{3}工作得很好。特别是universal codes的类在这个设置中可以证明是最优的，并且在论文中，作者压缩了每个链接大约3比特的小型网络爬行的链接图。

他们的代码（对于Java，Python和C ++）是zeta codes作为图形压缩框架，所以你应该能够在没有太多编码的情况下进行实验。

这个算法有点陈旧（2005）并且在该领域已经有了发展但是我现在没有指向论文的指针，这些改进无论如何都不重要，我认为没有任何可用的并且测试了实现它们的代码。

Answer 2

我前一段时间是a paper的一部分，关于压缩网络图表以便它们适合内存。我们把它降低到每个链路约6位。

Answer 3

一般来说，如果每个节点有N个节点和平均X个出局链接，X远小于N，那么你需要XN ln N位信息来表示这一点，除非你能找到模式链接结构（然后你可以利用它来降低熵）。 XN ln N与32位邻接列表的复杂程度相差一个数量级。

你可以采取一些措施来缩小规模：

• 使用霍夫曼代码对链接目的地进行编码。将较短的代码分配给频繁引用的页面，将较长的代码分配给不常用的页面。
• 找到一种方法将页面集分解为类。将同一类中的页面之间的每个链接存储为“0”+“类内＃”;不同类别的页面之间的链接为“1”+“目的地类”+“＃在课堂内”。

来自Giuseppe的链接值得检查，但只有实验会告诉您这些算法对维基百科的适用程度。

Answer 4

如何将节点，链接和关联编写到现有的可伸缩数据库系统（MySQL，SQL Server，Oracle等）？如果需要，您可以创建索引和存储过程，以便更快地进行DB级处理。

如果由于某种原因无法使用此路线，则需要将数据输入和输出（就像数据库系统一样！）。在许多情况下，压缩数据是短期的乐队援助。如果由于某种原因无法提升RAM屋顶，那么你只能在有限的时间内购买，所以我建议不要压缩它。

Answer 5

如果您不需要可变性，请查看BGL如何代表compressed sparse row format中的图表。根据文档，它“将内存使用最小化为O（n + m），其中n和m分别是顶点和边的数量”。 Boost Graph Library甚至可以an example反映您的用例。

在你深入研究之前，你应该弄清楚你打算如何询问你的图表。您是否需要指向页面的链接以及页面外的链接？您是否需要能够有效地查找给定页面上的链接数量？有关基本图形操作的深思熟虑的列表，请查看Boost Graph Library's (BGL) concepts。然后，您可以将其映射到不同算法的要求。例如，Dijkstra's shortest path需要一个模拟“顶点列表图”和“发生图”的图表。

Answer 6

在您的情况下，您正在尝试将SINGLE图压缩为内存而不是一般的大型图形系列。当您只有一个图形进行压缩时，您可以找到任意的算法表示，这就成了Kolmogorov complexity的问题。通常，您无法有效地压缩随机图，因为它们是随机的，因此无法预测，当无法预测它们时，它们无法被压缩。这来自基础信息理论;同样的事情是你无法用随机噪声压缩图像。

假设您有2个 ³⁰ （十亿）页面，并且每个人都有2个 ⁴ 出站链接，并且这些链接是真正随机分布的。每个页面上的链接代表几乎16 * 30位的信息（不完全是因为16个链接都是不同的，这增加了极少量的冗余）。所以你有2 ³⁰ * 16 * 30 = 2 ³² * 120 = 15 GB的信息，而且信息理论说你找不到更小的GENERAL表示。您需要使用维基百科图的特定结构来获得信息理论下限。