私はそれを処理するためのより良い方法を探しています。ドキュメント内の配列を使用して、すべてのコメントと投票を保存するように設計したドキュメント (画像とテキスト情報も保存する確認など)。私が懸念している問題は、ドキュメントのサイズ制限 (これまでのところ 16 Mb) に関するものです。ドキュメントが多くのコメントを保持し、特に内部配列に投票する場合、サイズ制限に達して壊れる可能性が非常に高くなります。一方で、この戦略を維持して、より高速なクエリも確保できます。
どうすればいいですか？リレーショナル DB が好きで、この種の情報やさまざまなコレクションやドキュメントを保持していますか? そうしないと、検索速度が低下します。そうでない場合は、安全で壊れないようにします。
それはすべて、データをどのように使用するかによって異なります。1 つのブログ投稿に対して膨大な数のコメントを受け取った場合、その投稿をクエリして、すべてのコメントを取得したいと本当に思いますか?
ブログ投稿を表示する実際の Web ページでは、実際にそのようなことはありません。最初のいくつかのコメントが表示され、それらをスクロールするか、[さらに表示] をクリックすると、さらに多くのコメントが取得されます。それはおそらく最高の（ハイブリッド）モデルです。ブログ投稿を最初に表示するときに必要なものはブログ投稿ドキュメントに保存しますが、後で照会できるその他すべてのものは、すべてのコメントが属する投稿を参照する別のコレクションに保存します。次に、1 回のインデックス付き読み取りで追加のコメントを取得できます (おそらく、post_id と投稿日でインデックスを作成しますか?)。また、「バケッティング」手法を使用して、コメントを投稿と時間のチャンクごとにグループ化して保存し、「コメントの次のページ」ドキュメント全体を取得できるようにすることもできます。
検索速度を下げるのではなく、これを正しく設計すれば、基本ドキュメントの検索と読み取りの速度が向上し、ネットワーク帯域幅も大幅に節約できます。