@halty は良い指摘をしていますが、完全に同意するわけではありません。コメントが少ない場合は、まとめられたデザインが適切であり、上で述べたことは非常に優れています。しかし、コメントが多すぎると問題が発生します。最も重要なのは、次の 2 つの基本的な開始点です。 1. ハードディスクが遅すぎます。 2. データがメモリ上に存在する限り問題はありません。

1. 見つける
   データが非常に大きい場合、メモリ マップされたファイルはメモリに保存されるため、大量のデータをディスク上で読み取る必要がありますが、必要なのはその一部だけです。主な問題は、OS がページングする可能性があることです。他のデータをハードディスクにコピーします。記事をリストするだけではメモリは効率的に使用されません。
2. 挿入
   ディスク ファイル上でドキュメントが何度も長くなり続けると、これは良いことではありません。新しいデータが追加されると、たとえば新しいコメントが追加されると、ドキュメントが大きくなり、元の場所に収まらなくなるため、新しい場所を見つける必要があり、以前の穴が再利用されます。しかし、問題は、ドキュメントの場所が変更されると、それに関連するすべてのインデックスも変更する必要があることです。コメントを投稿したユーザーの名前など、配列にインデックスがある場合、更新されたインデックスは配列の長さと線形に関係します。
3. サイズ
   この点については、上記の人が的確な指摘をしていました。 16MBの制限。

まとめると、コメントが多すぎるとパフォーマンスに影響します。

要約すると、スキーマ設計を考慮する必要があります

1. データ規模、頻繁にアクセスされるデータがメモリ内にある限り、アクセスに問題はありません。上記の最初のfindで述べたメモリ使用量の不足は、実際には大きな問題ではありません。人気記事のコメントは常に多くの人に読まれるので、記憶に残しておくと良いでしょう。ドキュメントが長くなり続ける場合、MongoDB はドキュメントを割り当てるときに、より多くのディスク領域を自動的に割り当てます。
2. アクセスパターンと互換性があります。 Twitter のデータでは、記事やコメントを読むのに比べてコメントを書くのは少なすぎます。平均ツイートは 5K/秒、読み取りタイムラインは 60 回です。読み取りリクエストがメモリ内で満たされる限り。 MongoDB を使用すると、追加のキャッシュが不要になります。インタビューが本当に大規模であっても、記事が多すぎても、言うのは簡単です。その日は、MongoDB のシャーディングが役に立つでしょう。
3. 開発が簡単 製品のコストは、マシンのハードウェアやネットワークのコストだけでなく、さらに重要なことに、プログラマーの開発コスト、そして給与が非常に高いため...したがって、高速で便利で、そしてそれを記述することも非常に重要です。間違いは起こりにくいですよね？これは、MongoDB ドキュメント モデルの柔軟性が広く賞賛される理由の説明になります。

そうは言っても、これらのアプリケーションのほとんどは 100 を超えるコメントを持たないと思います。このとき、1 つのドキュメントに数百のコメントがあれば問題はありませんが、問題はそれです。トピック所有者の個人情報は問題ありません。作者様の応募がこの数字を超えてくれる事を願います…

まず、コメント数が多いと記事一覧ページへのクエリが非効率にならないか確認してください。クエリ結果セット内のドキュメントがフィールド データの一部のみを返すように指定できます (フィールド データの一部のみを含むドキュメントを更新して保存すると、エラーが発生する可能性があることに注意してください)。ネットワーク帯域幅の節約に優れており、簡単に実行できます。

さらに、現在、mongodb には 1 つのドキュメントのサイズに制限があります。コメントが多すぎると、ドキュメントのデフォルトのサイズ制限を超える可能性があります。この時点で、コメントを削除する必要があります。