つまり、さまざまなサイズのドキュメントが多数あり、最大オブジェクトサイズに達するドキュメントが比較的少ない場合、それらのドキュメントをMongoDBに保存するためのベストプラクティスは何ですか？
私は次のような一連のドキュメントを持っています：
{_id: ...,
values: [12, 13, 434, 5555 ...]
}
値リストの長さは、ドキュメントごとに大きく異なります。ほとんどのドキュメントでは、いくつかの要素が含まれ、いくつかのドキュメントでは数千万の要素が含まれ、MongoDBの最大オブジェクトサイズ制限に達します。問題は、非常に大きな（そして比較的少数の）ドキュメントに対して私が思いついた特別な解決策であり、そうでなければMongoDBコレクションで幸せに生きる小さなドキュメントの保存方法に影響を与える可能性があります。
私が見る限り、私には次の選択肢があります。それらの長所と短所、および私が逃した他のオプションについての入力をいただければ幸いです。
1）別のデータストアを使用する：それはあまりにも劇的に思えます。私はMongoDBが好きですが、多くのオブジェクトのサイズ制限に達したわけではありません。言葉の場合、私のアプリケーションは非常に大きなオブジェクトと残りのオブジェクトを異なる方法で処理できます。エレガントではないようです。
2）GridFSを使用して値を格納します。従来のDBのblobのように、値の最初の数千の要素をドキュメントに保持でき、リストにさらに要素がある場合は、残りをGridFSオブジェクトに保持できます。バイナリーファイル。この部分では検索できませんが、それで生活することはできます。
3）GridFSの悪用：すべてのドキュメントをgridFSに保持できます。（小さな）ドキュメントの大部分では、ファイルコレクションがすべてを保持できるため、バイナリチャンクは空になります。残りの部分については、チャンクコレクションに余分な要素を保持することができます。オプション＃2と比較してオーバーヘッドが発生しますか？
4）本当にGridFSを悪用する：GridFSのファイルコレクションのオプションフィールドを使用して、すべての要素を値に格納できます。GridFSは、ファイルコレクションに対してもスマートチャンクを実行しますか？
5）追加の「リレーショナル」コレクションを使用して1対多の関係を格納しますが、このコレクション内のドキュメントの数は簡単に1,000億行を超えます。