非常に大きくなる可能性のあるコレクションがあります。これで、MongoDB には実際には問題がないことがわかりましたが、非常に大きなデータセットを快適に処理できるスキーマを設計する方法がよくわかりません。ということで、問題の概要を説明します。
私たちは、お客様のために大量のデータを収集しています。基本的に、このデータを収集すると、3 タプル (a、b、c) として表されます。ここで、b と c はそれぞれセット B と C のメンバーです。この特定のケースでは、B セットと C セットは時間の経過とともにあまり大きくならないことがわかっています。現在の顧客については、約 200,000 人のメンバーについて話しています。ただし、Aセットは時間の経過とともに成長し続けるものです. 現在、顧客あたり約 2,000,000 人のメンバーがいますが、これは (おそらく急速に) 成長する予定です。また、b->a と c->a の間には 1->n の関係があります。
このデータ セットのワークロードは、基本的に 3 つのユース ケースに分割されます。コレクションは定期的に更新され、A が最も多くの書き込みを取得し、B と C はいくつかの書き込みを取得しますが、多くはありません。2 番目のユース ケースは、B へのランダム アクセスであり、B の b \ に関連する C のいくつかのドキュメントを集約します。最後のユース ケースは、基本的に A と B から大きなサブセットをストリーミングして、新しいデータを生成します。
私たちが直面している問題は、インデックスがかなり大きくなっているということです。現在、約 8 人の小規模な顧客とのテスト セットアップがあり、現時点での合計データセットのサイズは約 15 GB で、インデックスは約 3 GB から 4 GB で実行されています。ここでの問題は、データセットに実際にはホット ゾーンがないことです。基本的に、すべてのドキュメント間で負荷が均等に分散されます。
基本的に、これを行うには 2 つのオプションを考え出しました。上で説明したもので、すべての顧客のすべてのデータが 1 つのコレクションに積み上げられています。これは、そのコレクション内のドキュメントを特定の顧客にリンクするフィールドのインデックスを作成する必要があることを意味します。
その他のオプションは、すべての b と c をまとめて (これらのセットは比較的小さい)、顧客ごとに 1 つの C コレクションを分割することです。この最後のソリューションは管理が少し難しいと想像できますが、複数の顧客のデータに同時にアクセスすることはめったにないため、メモリの問題を防ぐことができます. MongoDB は、customers インデックスをメモリにロードして、そこから実行することができます。
これについてどう思いますか？
PS: これが漠然としすぎていないことを願っています。不明な点があれば、さらに詳しく説明します。