私は様々な状況で最大のクエリ効率を得るための理想的なドキュメント構造について疑問を抱きました。この特定のケースでMongoDBがどのようにメモリ内で動作するかを実際には分かっていないのは本当に私の負担です。あなたに仮説的なシナリオを教えてください。ユーザフォロワ/フォロワの最も効率的なクエリのための良いMongoDBドキュメント構造は何ですか？
フォロワーとフォロワのTwitterシステムを想像してみてください。確かにチラッと見た後、メインのオプションがあるように見える：各ユーザー文書で
、彼らは続く他のユーザーのすべての文書への参照を含む「信者」の配列。フォロワーは、他のユーザーの「user.followers」配列内の現在のユーザーを見つけることによって検出されます。主な欠点は、Followee検索の潜在的なクエリオーバーヘッドであるように見えます。また、特に "user.followers"の内容のクエリの場合、MongoDBはユーザーのドキュメントの必須フィールドにアクセスするだけですか、またはユーザーの全ドキュメントが見つかっただけで、そこから必要なフィールド値が検索され、キャッシュ/大規模なユーザーベースでのクエリで大幅に多くのメモリが必要になるような方法で格納されていますか？
各ユーザー文書には、「フォロワー」と「フォロワー」の両方を保存して、それぞれにすばやくアクセスできます。これは明らかに、それぞれのフィールドの両方のユーザー文書にユーザーBに続くユーザーAのエントリーが存在し、fromからの削除が他のユーザー文書と一致する削除を必要とするという意味で、重複データの欠点があります。技術的には、これは単純な削除のための潜在的な失敗のポイントの数を倍増させることを検討している可能性があります。また、MongoDBは、削除が発生したときにメモリに格納されたデータの "スイスチーズ"と言われていることから、2つのフィールドからの削除は、メモリホールの問題の効果を2倍にします。
ユーザーのフォロワーを格納するための別のコレクションで、ユーザードキュメントに同様の方法で1つの質問がありますが、明らかにアクセスされるデータはフォロワーのみです。ユーザードキュメントには、各ユーザーは、そのデータへのアクセスを避けます。これは関係データベースの何かを感じているようですが、原則的にひどいアプローチではないことは分かっていますが、明らかにMongoのアーキテクチャーの下で（あるいは私が考慮していない）学ぶのが大好き！
誰もがこの上の任意の考えを持っているか、私はどこかに非常に関連し、かつ明白なドキュメントのページを逃してきた私に教えたい、あるいは（と思った私は愚かなことだということを教えたい場合なぜあなたの説明、）;）私はあなたから聞くのが大好きです！
どのようなプログラミング言語を使用しますか？それに応じて、基礎をなすドライバーがサポートしているかもしれないし、サポートしていないかもしれない特定の機能があります。私は特にDBRefsについて話しています。 http://docs.mongodb.org/manual/applications/database-references/ –
これは良い点です。ありがとうございます。 PHPとNode.jsが混在していますが、現在は何も使用していない可能性があります。 – tdous