28

大きなファイル用のスケーラブルなストレージを作成するための最適なソリューションを見つけようとしています。ファイル サイズは、1 ～ 2 メガバイトから 500 ～ 600 ギガバイトまでさまざまです。

Hadoop と HDFS に関する情報をいくつか見つけましたが、Map/Reduce ジョブやその他の多くの機能は必要ないため、少し複雑に見えます。現在、MongoDB を使用することを考えています。それは、ファイル ストレージ ソリューションとして GridFS です。

そして今、質問：

  1. いくつかのファイルを同時に書き込もうとすると、gridfs はどうなりますか。読み取り/書き込み操作のロックはありますか? （ファイルストレージとしてのみ使用します）
  2. gridfs からのファイルは RAM にキャッシュされ、読み書きのパフォーマンスにどのように影響しますか?
  3. 私の問題をより効率的に解決できる他のソリューションがいくつかあるのではないでしょうか?

ありがとう。

4

3 に答える 3

21

ここでは 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 から直接、素晴らしいものになる可能性があります。書き込みは同じくらい良いでしょう。

より大きなファイルの場合、そうではありません。ほとんどのコンピューターには 600 GB の RAM が搭載されておらず、1 つのmongodインスタンスに 1 つのファイルの 600 GB のパーティションを格納するのが一般的です。そのファイルが提供されるためには、作業セットに収まる必要がありますが、RAM よりも非常に大きいため、これは問題を引き起こします。この時点で、ページのスラッシング ( http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29 ) が発生する可能性があり、サーバーはファイルをロードしようとして 24 時間年中無休でページ フォールトを発生させます。ここでの書き込みも同様に優れています。

これを回避する唯一の方法は、単一のファイルを多数のシャードに配置すること:\です。

注: もう 1 つ考慮すべき点は、chunks「チャンク」のデフォルトの平均サイズが 256KB であるため、600GB のファイルに対して大量のドキュメントになることです。この設定は、ほとんどのドライバーで操作可能です。

いくつかのファイルを同時に書き込もうとすると、gridfs はどうなりますか。読み取り/書き込み操作のロックはありますか? （ファイルストレージとしてのみ使用します）

仕様に過ぎないGridFSは、データベースレベル(2.2+)またはグローバルレベル(2.2より前)で読み取りロックと書き込みロックの両方で、他のコレクションと同じロックを使用します。この 2 つは相互に干渉します。つまり、書き込まれているドキュメントを一貫して読み取るにはどうすればよいでしょうか?

そうは言っても、シナリオの詳細、トラフィック、同時書き込み/読み取りの数、および私たちが知らない他の多くのことに基づいて、競合の可能性が存在します。

私の問題をより効率的に解決できる他のソリューションがいくつかあるのではないでしょうか?

個人的には、(@mluggy が言ったように) 冗長性を抑えた形式の S3 が、MongoDB 内のファイルに関するメタデータのほんの一部を保存するのに最適であることがわかりました。これは、GridFS を使用するのと同じですが、チャンクコレクションがなくても、S3 にそのすべての配布、バックアップ、および処理を処理させます。あなたのための他のもの。

うまくいけば、私は明確になりました。

編集: 誤って言ったこととは異なり、MongoDB にはコレクション レベルのロックはなく、データベース レベルのロックです。

于 2013-02-23T01:17:17.680 に答える
5

メタデータを MongoDB に保存し、実際のファイルを Amazon S3 に書き込むことを検討しましたか? どちらも優れたドライバーを備えており、後者は冗長性が高く、クラウド/cdn 対応のファイル ストレージです。私はそれを試してみます。

于 2013-02-22T18:47:52.713 に答える