データセットを一連の列として格納する便利な方法として MongoDB を使用しています。ここには、特定の列の値を格納するドキュメントと、データセットの詳細を格納する別のドキュメントがあり、他のドキュメントへのマッピングは、関連する列の値。物事が大きくなるにつれて私が直面している問題は、列全体を 1 つのドキュメントに格納できなくなったことです。
GridFS オプションもあるということは承知していますが、唯一の欠点は、ファイルをブロブとして保存すると信じていることです。つまり、列のチャンクまたは指定されたインデックスの値へのランダム アクセスが失われるということです。ドキュメント ストアからは便利ですが、他に選択肢がないかもしれません。
だから私の質問は: GridFS もドキュメントのサイズに上限を課していますか?もしそうなら、誰かがこれが何であるかを知っていますか? ドキュメントを調べましたが、何も見つかりませんでしたが、正しい場所を探していないか、制限がある可能性がありますが、十分に文書化されていません。
ありがとう、ヴァッカー
GridFS のドキュメントによると:
Instead of storing a file in an single document, GridFS divides a file
into parts, or chunks, and stores each of those chunks as a separate
document. By default GridFS limits chunk size to 256k. GridFS uses
two collections to store files. One collection stores the file chunks,
and the other stores file metadata.
GridFS を使用すると、任意の大きなファイルを保存できますが、これは実際にはユース ケースには役立ちません。GridFS 内のファイルは事実上大きなバイナリ BLOB になり、構造化ドキュメントとインデックス作成の利点は得られません。
根本的な課題は、スキーマ設計へのアプローチです。16Mb のドキュメント制限を超えて大きくなる可能性のあるドキュメントを作成している場合、ドキュメントのサイズが大きくなるにつれて、データベースのストレージと断片化にも大きな影響を与えます。
適切な解決策は、スキーマ アプローチを再考して、ドキュメントが際限なく増加しないようにすることです。これはおそらく、成長している「列」の配列をフラット化して、配列ではなくドキュメントのコレクションで表すことを意味します。
より適切な (そして別の) 質問は、予想されるデータ増加パターンを考慮してスキーマをリファクタリングする方法です。