如何分析约 13GB 的数据？

Posted 2023-03-11

【中文标题】如何分析约 13GB 的数据？

【英文标题】：How can I analyse ~13GB of data?

【发布时间】：2012-07-12 02:13:49

【问题描述】：

我有大约 300 个文本文件，其中包含有关跟踪器、种子和对等点的数据。每个文件的组织方式如下：

tracker.txt

time torrent
    time peer
    time peer
    ...
time torrent
...

每个跟踪器有几个文件，并且大部分信息是重复的（相同的信息，不同的时间）。

我希望能够分析我拥有的东西并报告诸如此类的统计数据

每个跟踪器上有多少个种子 种子列表中列出了多少个跟踪器 种子有多少个同行 同行有多少洪流

庞大的数据量让我很难做到。这是我尝试过的。

MySQL

我将所有内容都放入数据库；每个实体类型一个表和保存关系的表（例如，这个种子在这个跟踪器上）。

将信息添加到数据库很慢（当我尝试这样做时，我没有 13GB 的信息），但事后分析关系是不行的。每个稍微复杂的查询都需要超过 24 小时才能完成（如果有的话）。

一个示例查询是：

SELECT COUNT(DISTINCT torrent) 
    FROM TorrentAtPeer, Peer 
    WHERE TorrentAtPeer.peer = Peer.id 
    GROUP BY Peer.ip;

我尝试增加my.cnf 文件中的内存分配，但似乎没有帮助。我使用了my-innodb-heavy-4G.cnf 设置文件。

编辑：添加表格详细信息

这是我使用的：

Peer         Torrent                  Tracker        
-----------  -----------------------  ------------------  
id (bigint)  id (bigint)              id (bigint)
ip* (int)    infohash* (varchar(40))  url (varchar(255))
port (int)

TorrentAtPeer      TorrentAtTracker
-----------------  ----------------
id (bigint)        id (bigint)
torrent* (bigint)  torrent* (bigint)
peer* (bigint)     tracker* (bigint)
time (int)         time (int)

*indexed field. Navicat reports them as being of normal type and Btree method.
id - Always the primary key

没有外键。我对仅使用与现有实体相对应的 ID 的能力充满信心，添加外键检查似乎是不必要的延迟。这是幼稚的吗？

Matlab

这似乎是一个为一些繁重工作而设计的应用程序，但我无法分配足够的内存来一次性保存所有数据。

我没有数字数据，所以我使用的是元胞数组，我从这些数组中转移到尝试以减少占用空间。我无法让它工作。

Java

迄今为止我最成功的尝试。我找到了 Limewire 人员提供的 Patricia Tries 的实现。使用它，我能够读取数据并计算我拥有多少个唯一实体：

13 个跟踪器 170 万种子下载 3200 万同行

我仍然发现很难计算出同龄人的种子数量的频率。我试图通过构建这样的尝试来做到这一点：

Trie<String, Trie<String, Object>> peers = new Trie<String, Trie<String, Object>>(...);
for (String line : file) 
    if (containsTorrent(line)) 
        infohash = getInfohash(line);
    
    else if (containsPeer(line)) 
        Trie<String, Object> torrents = peers.get(getPeer(line));
        torrents.put(infohash, null);
    

从我目前所做的来看，如果我能构建这个peers trie，那么我可以很容易地找出每个对等点有多少种子。我昨天运行了它，当我回来时，我注意到日志文件没有被写入，我^Z 应用程序和time 报告了以下内容：

real 565m41.479s
user 0m0.001s
sys  0m0.019s

这对我来说看起来不对，user 和 sys 应该这么低吗？我应该提一下，我还将 JVM 的堆大小增加到 7GB（最大和启动），否则我很快就会遇到内存不足的错误。

我不介意等待几个小时/几天，但看起来事情在大约 10 小时后就停止了。

我想我的问题是，我该如何分析这些数据？我尝试过的事情是正确的吗？有什么我想念的吗？ Java 解决方案似乎是迄今为止最好的，我可以做些什么来让它工作？

【问题讨论】：

您可以考虑使用Hadoop 和HBase 来分析您的数据。

我知道这些技术，尽管我从未使用过它们。我无法访问任何类型的机器集群，我真的只有一个。我还能从使用这样的东西中受益吗？

数据库服务器在运行什么？数据库服务器的规格是什么？它是否在您的本地机器上可能会遇到瓶颈？

使用 64 位版本的 Matlab，应该可以解决内存问题。不过，您可能需要点击一些额外的 RAM。

【参考方案1】：

您说您的 mysql 查询耗时过长。您是否确保有适当的索引来支持您提交的请求类型？在您的示例中，这将是Peer.ip 的索引（甚至是嵌套索引(Peer.ip,Peer.id)）和TorrentAtPeer.peer 的索引。

据我了解 Java 结果，您有很多数据，但没有那么多不同的字符串。因此，您也许可以通过为每个跟踪器、种子和对等点分配一个唯一的编号来节省一些时间。每个使用一个表，一些索引值保存字符串和一个数字主键作为 id。这样一来，与这些实体相关的所有表都只需要处理这些数字，这可以节省大量空间并使您的操作更快。

【讨论】：

是的，索引正确的列将有助于分配。它使用更多的数据库空间和内存，但将查询时间减少了很多倍。

我会将表格详细信息添加到问题中，我确实有我认为最好的字段的索引。看看

【参考方案2】：

我会再试一次 MySQL，但使用不同的架构：

此处不要使用 id 列

在此处使用自然主键：Peer：ip、端口Torrent：infohashTracker ：urlTorrentPeer：peer_ip、torrent_infohash、peer_port、时间TorrentTracker：tracker_url、torrent_infohash、时间

对所有表使用 innoDB 引擎

这有几个优点：

InnoDB 使用聚集索引作为主键。意味着当您只从主键列请求数据时，可以直接从索引中检索所有数据，而无需额外查找。所以 InnoDB 表在某种程度上是按索引组织的表。 尺寸更小，因为您不必存储代理键。 -> 速度，因为相同结果的 IO 更少。 您现在可以在不使用（昂贵的）连接的情况下进行一些查询，因为您使用自然主键和外键。例如，链接表TorrentAtPeer 直接包含peer ip 作为对等表的外键。如果您需要查询子网中对等方使用的种子，您现在可以在不使用连接的情况下执行此操作，因为所有相关数据都在链接表中。

如果您想要每个对等方的 torrent 计数，并且您也希望对等方的 ip 在结果中，那么在此处使用自然主键/外键时我们再次具有优势。

使用您的架构，您必须加入以检索 ip：

SELECT Peer.ip, COUNT(DISTINCT torrent) 
    FROM TorrentAtPeer, Peer 
    WHERE TorrentAtPeer.peer = Peer.id 
    GROUP BY Peer.ip;

使用自然主键/外键：

SELECT peer_ip, COUNT(DISTINCT torrent) 
    FROM TorrentAtPeer 
    GROUP BY peer_ip;

编辑 好吧，原始发布的架构不是真实的。现在Peer 表有一个port 字段。我建议在这里使用主键（ip、端口）并仍然删除 id 列。这也意味着链接表需要有多列外键。调整了答案...

【讨论】：

我会再试一次 MySQL。使用自然索引对我来说似乎很奇怪，我不是在复制信息并因此增加了所需的空间吗？ Torrent 的 infohash 是一个 40 个字符的字符串，将其存储在 Torrent 表中一次，然后再为 TorrentAtPeer 中的每个实例存储一次似乎比使用 ID 占用更多空间？为了简洁起见，我从表中删除了一些字段，我不应该删除的是 Peer 的端口。我概括地说，如果 Peer 共享 IP 但不共享端口，那么它们应该被视为同一个 Peer。

您的普通非链接表变成一列表。在这里您可以节省空间并加快查询速度。对于其他表，更重要的是您通常可以避免连接，这比节省几个字节更重要。而且我认为您可以从这里的 InnoDBs 聚集索引中受益匪浅。因此，相关数据必须在主键中。

好的，我会读一些关于聚集索引的文章。你有什么好的建议吗？如果没有，我会访问 Wikipedia 和 MySQL 站点。感谢您的帮助！

MySQL 站点应该没问题。关键是 InnoDB 表在存在时使用主键作为聚集索引。当所有相关数据都是该索引的一部分时，就没有额外的查找了。当您有一个代理 id-column 作为主键时，InnoDB 聚集索引不包含大多数查询的相关数据，并且会有额外的查找来检索表的其他列的所需值。

顺便说一句，在大多数情况下，代理 id 列是一个好主意，但在这里不是。

【参考方案3】：

您很可能遇到可以通过 NOSQL 和分布式技术解决的问题。

i) 我会使用 Hadoop/HBase 编写一个分布式系统。

ii) 租用几十 / 百台 AWS 机器，但只租几秒钟（它仍然花费不到 0.50 美元）

iii) 利润！！！

【讨论】：

这让我觉得这是一个非常有趣（和书呆子酷）的想法。我没有写分布式系统的经验，你有什么推荐的读物吗？我可以在我的个人机器上试运行和调试这样的系统吗？

【参考方案4】：

如果你会使用 C++，你应该看看Boost flyweight。

使用享元，您可以像编写字符串一样编写代码，但字符串的每个实例（您的跟踪器名称等）仅使用指针的大小。

无论是哪种语言，您都应该将 IP 地址转换为 int（查看 this question）以节省更多内存。

【讨论】：

不幸的是，我不懂任何 C++。我曾想过能够使用指针会使我的存储问题变得更容易一些。我认为确定我是否已经处理过种子太低效了；我将不得不遵循数以百万计的指示。我对吗？我对这些事情的了解很粗略。

@WilliamMayor 假设 C++ 中的解决方案与 java 中的解决方案看起来应该没有太大区别。 Boost Flyweight 的美妙之处在于，您根本不必关心指针。