6

私はこのスキーマを持っています：

article: {
    subject,
    comments: []
}

コメントが8つある場合は、

 article.find({}, {
     comments: {
         $slice: [ -10, 5 ]
     }
 });

また、インデックス0からインデックス4までのコメントを取得します
が、ページングのため、インデックス0からインデックス2までのコメントのみを返します。
（インデックス3からインデックス7への1ページ$スライス[-5、5]、インデックス0からインデックス2への2ページ$スライス[-10、5]）

ここで、別のパラメーター「lastId」を渡して各コメントを比較し、その「_id」<「lastId」を削除する必要がありますが、少しハッキーだと思います。

誰かがこれに対する良い解決策を持っていますか？

4

1 に答える 1

16

したがって、これはバインドされていない配列であり、クエリがより効率的になるため、コメントを個別のドキュメントとして残すようにスキーマを切り替える必要があると言います。説明します。

固定サイズではない配列に埋め込みドキュメントを追加すると、mongoDBはドキュメントの成長に合わせてドキュメントを移動する必要があり、パディングファクターが変更され、断片化が発生します（パディングファクターは、mongodb側からのドキュメントの大きさからの推測です）成長すると、その場合により多くのスペースが事前に割り当てられます）。

また、16MBのprドキュメントに制限されているので、人気のあるスレッドを入手したり、コメントを他のメタデータで拡張したりする場合は、その障壁を打ち破ることができます。大きなドキュメントを取得することも、費用と時間がかかります。

一般に、埋め込まれたドキュメントは、バインドされていない配列でない場合に最適です。したがって、上位10件のコメントのリストを保持することはうまくいきますが、1000件以上のコメントを保持することは良くありません。

下にいくつかの良いプレゼンテーションがあります

http://www.10gen.com/presentations/mongodb-berlin/2012/10-key-performance-indicators http://www.10gen.com/presentations/mongosv-2011/schema-design-by-example

長期的にはもっと役立つスキーマ設計について、もうすぐ作業が増えると思います。正直に言うと一番難しいと思います。リレーショナルモデルとの違いに頭を悩ませるのに少し時間がかかりました。

于 2012-05-03T09:54:18.300 に答える