小さなファイルがGoogleファイルシステムでホットスポットを作成するのはなぜですか？

Question

は、私は小さなファイルはチャンクの数が少ない、おそらくちょうど1で構成されていGoogle File Systems Paper

からこれを理解していません。多くのクライアント が同じファイルにアクセスしている場合、それらのチャンクを格納しているチャンクサーバーはホットスポットになる可能性があります。

小さなファイルではどのような違いがありますか？多くのクライアントからアクセスされている大きなファイルに問題が発生する可能性はありませんか？私は/には、以下を読んで考えた

： -

• 私は大きなファイルのチャンクが、これにより、負荷を分散するさまざまchunkserversに格納されていることを（私が間違っているなら、私を修正）を前提としています。このようなシナリオでは、1000のクライアントは各チャンクサーバーからのファイルの1/100にアクセスします。したがって、各チャンクサーバーは必然的に1000のリクエストを受け取ることになります。 （1000のクライアントが1つの小さなファイルにアクセスするのと同じではありません。サーバーは小さいファイルに対して1000件の要求を、大きなファイルの一部に対しては1000件の要求を受け取ります）
• 私はスパースファイルについて少し読んでいます。紙に応じて小さなファイルがチャンクまたは複数のチャンクを埋めます。だから私の理解には、小さなファイルは再構成されないので、ホットスポットの原因としてこれを排除しました。

Answer 1

後続のテキストの一部を助けることができる明確化：GFSは最初のバッチキューシステムによって を使用した場合

しかし、ホットスポットが開発しました：実行可能ファイルは、シングルとしてGFS に書かれていました-chunkfileを実行してから、数百台のマシンで同時に起動します。 この 実行可能ファイルを格納している少数のチャンクサーバーは、数百の同時要求によってオーバーロードされました。 この問題は、このような実行可能ファイル をより高いレプリケーションファクタで保存し、バッチキュー のシステムをアプリケーションの開始時刻に合わせることで解決しました。潜在的な という長期的な解決策は、クライアントがこのような状況で他の クライアントからデータを読み取ることができるようにすることです。

1000人のクライアントが同時に小さなファイルを読み取る場合、その唯一のチャンクを保持するN個のchunkserversは、1000/N個の同時要求を受け取ります。この突然の負荷は、ホットスポットの意味です。

大きなファイルは、特定のクライアントによって一度にすべて読み込まれることはありません（結局、サイズが大きい）。代わりに、ファイルの一部をロードして作業し、次の部分に移動します。

シャーディング（MapReduce、Hadoop）のシナリオでは、ワーカーは同じチャンクをまったく読み取ることさえできません。 Nのうちの1つのクライアントは、ファイルの1/Nのチャンクを他のクライアントと区別して読み込みます。

実際には、シャドー以外のシナリオでも、クライアントは完全には同期されません。彼らはすべてファイル全体を読むことになるかもしれませんが、統計的にホットスポットがないようにランダムアクセスパターンを使用します。あるいは、彼らが順番にそれを読んでいれば、ワークロードの違いのために（クライアントを意図的に同期していない限り....）同期が取れなくなります。

大量のクライアントであっても、大容量のファイルが必要とする作業の性質上、大容量ファイルのほうがホットスポットが少なくなります。がであるとは限りません。実際には、複数のチャンクファイルのすべてのチャンクで分散クライアントが連携して動作するわけではありません。