私は、画像、音楽、ビデオなどのモンゴの世界の大きなデータがGridFSに行くことを知っています。小さなの構造のデータはMongoに直接送られます。mongoに大きなファイル（メディアではない）を保存する適切な方法はありますか？
最近、私はBSONObjサイズの制限を超えました。実際にのオブジェクトのような私のファイルは、小さな規則的なデータ（ネストされた構造）のように見えますが、大きさは20Mbから始まります。私は確信していませんが、bytearrayへの事前変換を使ってGridFSに書き込むことは悪い考えです（ベクトルは動的で一定ではありません）。いくつかの回避策はありますか？
任意で、そのオブジェクトにクエリを実行する必要があります。トップレベルのベクトルから最初のスライス（インデックス）をフェッチします。
サポートしたいクエリによっては、2つの選択肢があります。しかし、数百MBのデータサイズの場合、RAM内のすべてを実行し、MongoDBを単なるブロブストアとして使用するよりも遅くなると考えています。
1つの次元を別のオブジェクトに入れることができます。
FirstLevel {
"_id" : ObjectId("..."),
"Children" : [ ObjectId("..."), ... ]
// list of vector ids (of the second level)
}
恐らく非常に良い解決策ではありません。格納できるアイテムの数にはまだ制限がありますが、数字はかなり大きくなるはずです。(16M/id size)^3です。Fooが大きなオブジェクトの場合は、はるかに小さくなります（リーフ内）。
アクセスがかなり遅くなるのは、ツリーを歩かなければならないためです。ノードとリーフのデータ形式は多少異なります。しかし、非常に拡張可能です（任意の次元数）。あなたのデータは3次元であるので
2）、あなたはそれが真の3次元「保存することができます：{x, y, z}タプル上の複合インデックスを使用して
Data {
Coords : { "x" : 121, "y" : 991, "z" : 12 },
ActualData : { /* Serialized Foo */ }
}
が、これは除いて、非常によく次元スライスをサポートしていますのような操作はすべてz = 13を選択し、次にxで注文します。。このアプローチにはかなりのオーバーヘッドがあり、おそらくカスタム（デ）シリアライザが必要になります。私はC++ドライバについてはわかりませんが、C＃では実装が非常に簡単です。
これはギザギザの配列も非常によくサポートします。
2a）2）のオーバーヘッドを必要としない場合は、座標を単一のlongに絞ることができます。これは、geohashingに似ています。これは、MongoDBが地理空間インデックスに対して行っていることです。
座標スライスを照会するのはビットマスク操作ですが、残念ながらまだクエリではサポートされていません（$bitは更新のみ）。あなたはvote for itすることができます。
あなたの目的に合わせてジオハッシングを悪用する可能性もありますが、それはむしろ実験的なことです。