16MBを超えるドキュメントがあります。これらのドキュメントは、多くのキーと値のペアで構成され、それらを含むサブドキュメント（dict）と配列（list）は、数レベルの深さでネストされる場合があります。
これらのスーパー16MBファイルのいずれかを挿入しようとすると、ドキュメントのサイズが16MBを超えるというエラーが発生します。そこで、GridFSを調べ始めました。GridFSは、バイナリデータなどのファイルをチャンクアップするのに最適なようです。ただし、上記で説明したように、高度にネストされたK/Vドキュメントをどのように「チャンクアップ」するかについては明確ではありません。複数のドキュメントに挿入の原子性がないため、これらの巨大なドキュメントを小さなドキュメントに分割し、弾丸を噛んでトランザクションを実装する必要があるかもしれないと考えています。
GridFSについての私の理解は遠いですか？トランザクションサポートを使用してドキュメントを小さなドキュメントに分割するのが最善の方法ですか、それともここでGridFSを使用する方法がありますか？
ご清聴ありがとうございました。
キーと値のペアをコレクションではなくドキュメントに保存するのはなぜですか?
それらの多くが必要な場合は、それらをコレクションに格納するだけです (それらがすべて一意であり、ネストされた構造ではないと仮定します)。
または、そのデータを redis に移行することもできます。これは、とにかくキー/値を検索する際のパフォーマンスが高く、合理的な制限がありません。複数のストレージ エンジンを混在させても問題ありません。
コメント1に応じて編集：
ドキュメントで 16 MB のキーと値のペアを使用している場合、実際にどのようにデータをモデリングしているのか疑問に思うでしょう。データベースがスキーマレスであるからといって、mongo にキー値を格納する正しい方法が 1 つの大きなドキュメントにあるとは限りません。
あなたのニーズをよりよく理解し、より良い回答を提供できるように、あなたがしようとしていることについてより多くの情報を提供できますか? これ以上のお手伝いができると確信しています。
GridFS は、ファイルを不透明なバイナリ BLOB として扱います。「キー/値ドキュメント」と、たとえば画像ファイルを区別しません。
ドキュメントに含まれる値に対してクエリなどを実行する場合は、手動で小さなドキュメントに分割する必要があります。一方、ドキュメントが実際には内部構造を持つ不透明なデータの塊である場合 (DB ではなく、プログラム内でのみ気にする必要があります)、GridFS は適切な選択です。
もう 1 つの考慮事項はパフォーマンスです。16 MB 以上の巨大なドキュメントを読み書きする必要が本当にあるのでしょうか。それとも、通常、各ドキュメントのサブセットのみを扱っていますか? 前者の場合、GridFS を使用します。後者の場合は、ドキュメントを異なるコレクションに分割し、それらの間で参照を行います。