The Google File System Section 2.3という論文では、次のように述べています。
ファイルは固定サイズのチャンクに分割されます。
しかし、理由は言わないでください。それの利点は何ですか?
The Google File System Section 2.3という論文では、次のように述べています。
ファイルは固定サイズのチャンクに分割されます。
しかし、理由は言わないでください。それの利点は何ですか?
複製の容易さ。ファイル全体を複製するよりも、複数のチャンクを複製する方が簡単です。レプリケーション中にエラーが発生した場合は、失敗したチャンクのみを再度コピーする必要があります。
サーバーの負荷を分散します。読み取りと書き込みの両方の操作は、すべてのチャンク サーバー間で分離できます。
読み取りと書き込みの両方のスループットを向上させます。何百ものサーバーが同時に要求を処理できるため、読み取りと書き込みの両方のスループットを向上させることができます。アプリケーションは、ファイルのチャンクのメタデータをマスター サーバーから取得し、それらのチャンクをチャンク サーバーから直接取得します。
ディスク使用率の向上。ファイルがチャンクよりも大きくなる傾向があり、ディスクにわずかなスペースしかない場合は、ファイル全体ではなくチャンクに十分なスペースを見つける方が簡単です。
完全性チェックの容易さ。チャンクのチェックサムの計算は、ファイル全体よりも高速です。破損したチャンクが検出された場合、ファイル全体ではなくチャンクを修正する方が簡単です。
この概念は、下層の OS と DBMS によって正確に踏襲されているようです。そこでは、仮想メモリとディスク上のデータ配置に固定サイズのページ/ブロックが使用されます。固定サイズのブロックは断片化に役立ちます。つまり、ファイルが削除された場合にスペースが使用されなくなり、再利用が非常に困難になるため、ブロックのサイズも小さく保たれます。ここで、GFS は実際には後処理にのみ使用されるため、多くの削除はありません。しかし、小さい固定サイズのブロックを使用すると、マップ削減ジョブも非常に簡単に実行できます。
このようにして、クライアントは、各サイズが 64 MB しかないことを知っている特定のブロックを要求できるため、キャッシュをより有効に活用することもできます。