さまざまな状況でクエリの効率を最大化するための理想的なドキュメント構造について疑問に思っていましたが、質問したいことがあります。この特定の種類のケースでMongoDBがメモリ内でどのように動作するかを実際に知らないことは、私から本当に生まれています。架空のシナリオを紹介します。
フォロワーとフォロワーのTwitterスタイルのシステムを想像してみてください。明らかに大雑把に見てみると、主なオプションは次のように見えます。
各ユーザードキュメントで、フォローしている他のユーザーのすべてのドキュメントへの参照を含む「フォロワー」配列。フォロワーは、他のユーザーの「user.followers」配列で現在のユーザーを見つけることによって見つけられます。主な欠点は、Followee検索の潜在的なクエリオーバーヘッドであるように見えます。また、「user.followers」のコンテンツ専用のクエリの場合、MongoDBはユーザーのドキュメントの必須フィールドにアクセスするだけですか、それともユーザードキュメント全体が見つかり、そこから必須フィールドの値が検索され、これがキャッシュされます/大規模なユーザーベースでのクエリが大幅に多くのメモリを必要とするような方法で保存されていますか？
各ユーザードキュメントに、「フォロワー」と「フォロワー」の両方を保存して、それぞれにすばやくアクセスできるようにします。これには明らかに、ユーザーBに続くユーザーAのエントリがそれぞれのフィールドの両方のユーザードキュメントに存在し、fromからの削除には、もう一方の一致する削除が必要であるという意味で、重複データの欠点があります。技術的には、これは単純な削除で潜在的な障害のポイント数を2倍にすることを検討している可能性があります。そして、MongoDBは、削除が発生したときにメモリに保存されたデータの「スイスチーイング」と言われることでまだ苦しんでいます。したがって、1つではなく2つのフィールドから削除すると、そのメモリホールの問題の影響が2倍になりますか？
1のユーザードキュメントと同様の方法でクエリされた、ユーザーのフォロワーを保存するための個別のコレクション-アクセスされるデータはフォロワーのみであることが明らかであるため、ユーザードキュメントに各ユーザーに関連する他のデータがかなり多く含まれている場合は、そのデータにアクセスします。これはリレーショナルデータベースのような感じがするようですが、原則として必ずしもひどいアプローチではないことはわかっていますが、モンゴのアーキテクチャでは、言及されている他のアプローチの1つ（または私が検討していないアプローチ）の方が優れていることは明らかです。学びたい！
誰かがこれについて何か考えを持っているか、私がどこかで非常に関連性があり明白なドキュメントページを見逃したことを私に伝えたい場合、または私がただ愚かであると私に伝えたい場合（理由の説明で考えてください; ））私はあなたから聞いてみたいです！