ここではMongoDBについてのみ回答できますが、HDFSやその他のそのようなテクノロジーについてよく知っているふりはしません。
GridFsの実装は、ドライバー自体の中で完全にクライアント側です。これは、MongoDB自体の中で提供されるファイルのコンテキストについて特別な読み込みや理解がないことを意味し、事実上、MongoDB自体はそれらがファイルであることさえ理解しません（http://docs.mongodb.org/manual/applications/gridfs/）。
これは、filesの任意の部分をクエリすることを意味します またはchunks コレクションは、他のクエリの場合と同じプロセスになります。これにより、必要なデータが、データのセット（またはすべて）を表すワーキングセット（http://en.wikipedia.org/wiki/Working_set）に読み込まれます。最適なパフォーマンスを維持するために、指定された時間枠内にMongoDBが必要とする（その時点でロードされたデータ）。これは、RAMにページングすることで実行されます（技術的にはOSが実行します）。
考慮すべきもう1つのポイントは、これがドライバー実装であるということです。これは、仕様が変わる可能性があることを意味しますが、私はそうは思わない。すべてのドライバーで、filesから一連のドキュメントをクエリできます。 ファイルのメタデータのみを格納するコレクション。後でchunksからファイル自体を提供できます。 単一のクエリによるコレクション。
ただし、これは重要なことではありません。データを含め、ファイル自体を提供する必要があります。これは、filesをロードすることを意味します コレクションとそれに続くchunks ワーキングセットへのコレクション。
そのことを念頭に置いて、私たちはすでに最初の障害にぶつかっています：
gridfsからのファイルはRAMにキャッシュされ、読み取り/書き込みパフォーマンスにどのように影響しますか？
小さなファイルの読み取りパフォーマンスは、RAMから直接、素晴らしいものになる可能性があります。書き込みも同様に優れています。
大きなファイルの場合はそうではありません。ほとんどのコンピューターには600GBのRAMが搭載されておらず、実際には、単一のmongodに単一のファイルの600GBのパーティションを格納する可能性があります。 実例。そのファイルは、提供されるためにワーキングセットに収まる必要がありますが、RAMよりも非常に大きいため、これは問題を引き起こします。この時点で、ページのスラッシング（http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29）が発生する可能性があります。これにより、サーバーは24時間年中無休でファイルを読み込もうとしてページに障害が発生します。ここでの書き込みも良くありません。
これを回避する唯一の方法は、1つのファイルを多くのシャードに配置し始めることです:\ 。
注：もう1つ考慮すべき点は、chunksのデフォルトの平均サイズです。 「チャンク」は256KBなので、600GBのファイルには大量のドキュメントが必要です。この設定は、ほとんどのドライバーで操作できます。
いくつかのファイルを同時に書き込もうとすると、gridfsはどうなりますか。読み取り/書き込み操作のロックはありますか？ （ファイルストレージとしてのみ使用します）
GridFSは仕様にすぎないため、他のコレクションと同じロックを使用します。データベースレベル（2.2以降）またはグローバルレベル（2.2より前）の読み取りロックと書き込みロックの両方を使用します。この2つは互いに干渉します。つまり、書き込まれているドキュメントを一貫して読み取るにはどうすればよいでしょうか。
とはいえ、競合の可能性は、シナリオの詳細、トラフィック、同時書き込み/読み取りの数、および私たちが知らない他の多くのことに基づいて存在します。
たぶん、私の問題をより効率的に解決できる他の解決策がいくつかありますか？
私は個人的に、冗長性を減らした形式のS3（@mluggyが言ったように）が、GridFSを使用するのと同じように、MongoDB内のファイルに関するメタデータのほんの一部を保存するのに最適であることがわかりましたが、チャンクコレクションはありません。あなたのための他のもの。
うまくいけば、私は明確になりました、それが役立つことを願っています。
編集：私が誤って言ったこととは異なり、MongoDBにはコレクションレベルのロックがなく、データベースレベルのロックです。