为什么小文件会在Google文件系统中创建热点？

Question

我不理解Google File Systems Paper

  

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

小文件有什么区别？许多客户端访问的大文件是否同样可能导致问题？

我认为/阅读以下内容： -

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

Answer 1

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

  

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

如果1000个客户端想要同时读取一个小文件，那么持有其唯一块的N个块服务器将同时收到1000个/ N个请求。这种突然的负荷是热点的意思。

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

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

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

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