0

Mongo の世界では、画像、音楽、ビデオなどのビッグ データは GridFS に送られ、小さくて構造化されたデータは直接 Mongo に送られる ことを私は知っています。

BSONObj最近、サイズの制限を超えました。実際にはオブジェクトである私のファイルは、小さな通常のデータ (ネストされた構造を持つ) のようvector<vector<vector<Foo>>>に見えますが、巨大なサイズ (20Mb から始まる) です。よくわかりませんが、以前に bytearray に変換して GridFS に書き込むのは悪い考えのようです (ベクトルは動的で一定でない長さを持ちます)。回避策はありますか？

必要に応じて、そのオブジェクトに対してクエリを実行したいと考えています。たとえば、最上位のベクターから最初のスライス (インデックス) をフェッチします。

4

1 に答える 1

1

サポートしたいクエリに応じて、2 つの選択肢が思い浮かびます。ただし、数百 MB のデータ サイズの場合、すべてを RAM で実行し、MongoDB を単なるブロブ ストアとして使用するよりも遅くなると思います。

1）各次元を別々のオブジェクトに入れることができます：

FirstLevel {
   "_id" : ObjectId("..."),
   "Children" : [ ObjectId("..."), ... ]
   // list of vector ids (of the second level)
}

おそらくあまり良い解決策ではありません。保存できるアイテムの数にはまだ制限がありますが、 が大きなオブジェクトである (16M / id size)^3場合は、大まかに、(リーフ内で) はるかに小さいため、その数はかなり大きくする必要があります。Foo

ツリーをたどる必要があるため、アクセスはかなり遅くなります。ノードとリーフのデータ形式は多少異なります。ただし、非常に拡張可能です (任意の次元)。

2) データは 3 次元であるため、「真の 3 次元」で保存できます。

Data {
  Coords : { "x" : 121, "y" : 991, "z" : 12 },
  ActualData : { /* Serialized Foo */ }
}

タプルで複合インデックスを使用すると、 「すべてを選択してから並べ替える」{x, y, z}などの操作を除いて、次元スライスが非常にうまくサポートされます。このアプローチにはかなりのオーバーヘッドが伴い、おそらくカスタム (デ) シリアライザーが必要になります。C++ ドライバーはわかりませんが、C# では非常に簡単に実装できます。z = 13x

これにより、ジャグ配列も十分にサポートされます。

2a) 2) のオーバーヘッドが必要ない場合は、座標を 1 つのlong. これは、MongoDB が地理空間インデックスに対して行うgeohashingに似ています。

座標のスライスのクエリはビット マスク操作であり、残念ながらクエリではまだサポートされていません ($bit更新でのみ機能します)。ただし、投票することはできます。

たぶん、あなたの目的のためにジオハッシュを悪用することもできますが、それはむしろ実験的なものです.

于 2011-12-11T11:20:34.867 に答える