1

我从Google 文件系统论文中不明白这一点

一个小文件由少量块组成，也许只有一个。如果许多客户端访问同一个文件，存储这些块的块服务器可能会成为热点。

一个小文件有什么不同？许多客户端访问的大文件不是同样可能导致问题吗？

我曾想过/阅读以下内容：-

  • 我假设（如果我错了，请纠正我）大文件块存储在不同的块服务器上，从而分配负载。在这种情况下，假设 1000 个客户端从每个块服务器访问文件的 1/100。所以每个 chunkserver 不可避免地会收到 1000 个请求。（与访问单个小文件的 1000 个客户端不同。服务器收到 1000 个小文件请求或 1000 个大文件部分请求）
  • 我读了一些关于稀疏文件的内容。小文件根据文件填满一大块或几块。因此，据我了解，不会重建小文件，因此我已将其排除为热点的可能原因。
4

1 回答 1

5

随后的一些文本可以帮助澄清：

然而，当批处理队列系统首次使用 GFS 时，热点确实出现了：一个可执行文件作为单个块文件写入 GFS，然后同时在数百台机器上启动。存储此可执行文件的少数块服务器因数百个同时请求而过载。我们通过以更高的复制因子存储此类可执行文件并使批处理系统错开应用程序启动时间来解决此问题。一个潜在的长期解决方案是允许客户端在这种情况下从其他客户端读取数据。

如果有 1000 个客户端要同时读取一个小文件，则持有其唯一块的 N 个 chunkserver 将同时收到 1000/N 个请求。这种突然的负载就是热点的意思。

给定的客户端不会一次读取大文件（毕竟它们很大）。相反，他们将加载文件的某些部分，对其进行处理，然后继续进行下一部分。

在分片（MapReduce、Hadoop）场景中，worker 甚至可能根本不会读取相同的块；N 个客户端中的一个客户端将读取文件的 1/N 块，与其他客户端不同。

即使在非分片场景中，实际上客户端也不会完全同步。他们可能最终都读取整个文件，但使用随机访问模式，因此统计上没有热点。或者，如果他们确实按顺序读取它，他们会因为工作量的不同而失去同步（除非你有目的地同步客户端......但不要这样做）。

因此，即使有很多客户端，由于大文件所需的工作性质，较大的文件也不会出现热点问题。不能保证，这就是我认为您在问题中所说的，但实际上分布式客户端不会在多块文件的每个块上协同工作。

于 2017-10-05T18:27:18.610 回答