2

データ構造は次のようになります。

{
 post_title : String,
 post_date  : Date,
 user_id    : ObjectID,
 post_content : String,
 comments   : [
                {
                  comment_date : Date,
                  comment_content : String,
                  user_id : ObjectID
                 }
                ]
}

私が取り組んでいるシステムは、上記と同様の構造を持っています。post_* オブジェクトに含まれるコンテンツはおそらく変更されませんが、コメント セクションのコンテンツは頻繁に更新および編集されます。

上記の構造は単一のドキュメントであるため、単一のコメントを更新または追加するには、ドキュメント全体を読み取り、編集して保存する必要があります。また、post_* コンテンツは長期間キャッシュできますが、コメントはキャッシュできないため、キャッシュが困難になります。

ここでの最善の戦略は何ですか？コメントに独自のコレクションを与える方が良いですか?

クエリ時間に関しては、データベースにアクセスしてコメントを抽出する必要がありますが、コメントを更新または追加すると、ドキュメントのサイズははるかに小さくなります。

4

3 に答える 3

2

Mongo では、配列を読み取らずに追加できます。$pushコマンドを参照してください。キャッシュに関しては役に立ちませんが、更新する前にドキュメントを読む必要がなくなります。

于 2012-04-20T16:40:16.830 に答える
1

考慮すべきもう1つのことは、「コメント」配列がどれだけ大きくなると予想されるかを事前に知っていますか?

各 mongo ドキュメントのサイズ制限は 16 MB です。これが問題になることはめったにありませんが、心に留めておくべきことであり、埋め込み配列にサブドキュメントを「無限に」追加することを避ける理由です。

さらに、Mongo は、ドキュメントが拡大するためのスペースを事前に割り当てます。(詳細については、「パディング ファクター」に関するドキュメントを参照してください: http://www.mongodb.org/display/DOCS/Padding+Factor ) 十分な量の埋め込みドキュメントが配列にプッシュされ、ドキュメントが事前割り当てを超えて大きくなる場合ディスク上のスロットに移動すると、ドキュメント全体をディスク上の別の場所に移動する必要があります。これにより、望ましくない diskIO が発生することがあります。

各ドキュメントに最大数の埋め込みドキュメントがあると予想される場合、一般的な方法は、新しいドキュメントが追加されるときにその配列を事前に設定することです。たとえば、各投稿に 100 個のコメントが含まれると予想される場合、ベスト プラクティスは、「ガベージ」データを含む 100 個の埋め込みドキュメントを含む「コメント」配列を持つ新しい投稿ドキュメントを作成することです。新しいドキュメントが作成されると、ディスク容量が事前に割り当てられ、ガベージ データが削除される可能性があるため、ドキュメントのサイズが大きくなる余地が残されます。

ドキュメント構造を設計する際に、これが追加の検討材料になることを願っています。

于 2012-04-20T19:44:12.720 に答える
1

ネストされたコレクションにコメントを格納する意味は何ですか? DBRef を使用したコメント、または手動で参照する場合でも、別のコレクションを使用することをお勧めします。

ドキュメントのサイズだけが問題ではありません。(これはまったく問題ではないと思います) 一般的なタスクの 1 つ - ユーザーに最後の N 件のコメントを表示します。あなたの構造で行うのはかなり難しいです。

あなたの構造をアプリケーションに使用しましたが、後でスタンドアロン コレクションで書き直さなければなりませんでした

于 2012-04-20T18:22:38.857 に答える