GoogleファイルシステムやHadoopのような分散ファイルシステムは、ランダムI/Oをサポートしていません。
(以前に書き込んだファイルを変更することはできません。書き込みと追加のみが可能です。)
なぜ彼らはこのようなファイルシステムを設計したのですか?
デザインの重要な利点は何ですか?
PS私はHadoopが書き込まれたデータの変更をサポートすることを知っています。
しかし、彼らは、それはパフォーマンスが非常に良くないだろうと言いました。なんで?
GoogleファイルシステムやHadoopのような分散ファイルシステムは、ランダムI/Oをサポートしていません。
(以前に書き込んだファイルを変更することはできません。書き込みと追加のみが可能です。)
なぜ彼らはこのようなファイルシステムを設計したのですか?
デザインの重要な利点は何ですか?
PS私はHadoopが書き込まれたデータの変更をサポートすることを知っています。
しかし、彼らは、それはパフォーマンスが非常に良くないだろうと言いました。なんで?
Hadoopはファイルを配布および複製します。ファイルは複製されるため、書き込み操作では、ネットワーク全体で複製された各セクションを見つけて、ファイルを更新する必要があります。これにより、操作にかかる時間が大幅に長くなります。ファイルを更新すると、ファイルがブロックサイズを超えてプッシュされ、ファイルを2つのブロックに分割してから、2番目のブロックを複製する必要があります。内部とそれがいつ/どのようにブロックを分割するかはわかりません...しかし、それは潜在的な問題です。
すでに更新を行って再実行されたジョブが失敗または強制終了された場合はどうなりますか?ファイルを複数回更新する可能性があります。
分散システムでファイルを更新しないことの利点は、ファイルを更新するときに他に誰がファイルを使用しているかわからないこと、ピースがどこに保存されているかわからないことです。タイムアウトが発生する可能性があるため(ブロックのあるノードが応答しない)、データの不一致が発生する可能性があります(ここでも、hadoopの内部がわからず、ノードがダウンした状態の更新が処理される可能性があります。これは私がブレインストーミングしていることです。 )。
HDFS上のファイルの更新には、多くの潜在的な問題があります(上記のいくつかの問題)。それらのどれも克服できないものではありませんが、チェックして説明するためにパフォーマンスヒットが必要になります。
HDFSの主な目的は、mapreduceで使用するデータを保存することであるため、この段階では行レベルの更新はそれほど重要ではありません。
これはデータのブロックサイズが原因だと思います。Hadoopの全体的な考え方は、データを移動するのではなく、アルゴリズムをデータに移動することです。
Hadoopは、データの非リアルタイムバッチ処理用に設計されています。応答時間とランダムアクセスの点で従来のRDBMSのようなものを実装する方法を検討している場合は、Hadoop上に構築されたHBaseを参照してください。