問題タブ [mongodb-indexes]

2.2のMongoShardキーのドキュメントを読んでいたところ、少し混乱しました。

すべてのシャードコレクションには、シャードキーで始まるインデックスが必要です。まだドキュメントが含まれておらず、そのようなインデックスがないコレクションをシャードすると、shardCollectionはシャードキーにインデックスを作成します。コレクションにすでにドキュメントが含まれている場合は、shardCollectionを使用する前に適切なインデックスを作成する必要があります。

バージョン2.2で変更：シャードキーのインデックスは、シャードキーと同一である必要はなくなりました。このインデックスは、以前のようにシャードキー自体のインデックスにすることも、シャードキーがインデックスのプレフィックスである複合インデックスにすることもできます。このインデックスをマルチキーインデックスにすることはできません。

フィールド{zipcode：1}を使用してシャーディングされたpeopleという名前のコレクションがあり、これをフィールド{zipcode：1、username：1}のインデックスに置き換えたい場合は、次のようにします。

{zipcode：1、username：1}にインデックスを作成します：db.people.ensureIndex（{zipcode：1、username：1}）; MongoDBがインデックスの作成を完了したら、既存のインデックスを{zipcode：1}に安全にドロップできます。db.people.dropIndex（{zipcode：1}）; 警告シャードキーのインデックスをマルチキーインデックスにすることはできません。上記のように、{zipcode：1、username：1}のインデックスは、usernameフィールドに配列値がない場合にのみzipcodeのインデックスを置き換えることができます。

シャードキーの最後の適切なインデックスを削除した場合は、シャードキーだけにインデックスを再作成して回復します。

シャードキーとインデックスについていくつか質問があります。

i）ドキュメントから、2.2より前にマルチキーインデックスがサポートされていたようです。その場合、複合インデックスはマルチキーインデックスとどのように異なりますか？

ii）[a]シャードキーで始まるインデックスと[b]プレフィックスとしてシャードキーを持つインデックスの違いは何ですか？

iii）シャードキーのインデックスがマルチキーインデックスであってはならないという警告事項は何ですか？db.people.ensureIndex（{zipcode：1、username：1}はマルチキーインデックスではありませんか？

質問:tsフィールド: (タイムスタンプ) によってインデックス付けされた非常に大きなコレクションがあります。

最後の 5 つのエントリを取得したい。私が驚いたのは、クエリがインデックスを使用していないため、非常に遅いことです。

ただし、または他のフィールドだけでソートすると、ts必要に応じてインデックスが使用されます。

これは MongoDB のバグですか、これは実際に文書化された機能ですか、それとも何か間違っていますか?

追加情報：

MongoDB ドキュメントから

複数のフィールドに複合インデックスがある場合は、それを使用して、フィールドの最初のサブセットに対してクエリを実行できます。したがって、a、b、cにインデックスがある場合は、[a] [a、b] [a、b、c]でクエリを使用できます

このフィールドを持つドキュメントがあるとしましょう

1. ユーザーID
2. 名前
3. 国
4. エクストラフィールド

私のインデックスの順序は [UserID,Name,Country] です

したがって、次のようなクエリがある場合

このクエリは最初の 3 つのパラメータにインデックスを使用し、次にインデックスなしで ExtraField を検索しますか?

はいの場合、このクエリでも同じですか

Mongoのドキュメントを検索しようとしましたが、一意のインデックスに対するクエリが非一意のインデックスに対するクエリよりも高速になるかどうかについての詳細を実際に見つけることができません (同じデータが与えられた場合)

したがって、ユニークインデックスは選択性が高く、パフォーマンスが優れていることがわかります。しかし、連結が一意である 2 つのフィールドがある場合、一意でない複合インデックスは、一意の複合インデックスよりもパフォーマンスが低下しますか?

一意性を検証する必要があるため、一意のインデックスによって挿入が遅くなる可能性があると想定しています。しかし、一意のインデックスによる読み取りパフォーマンスの向上は、本当に価値があるのでしょうか?

以下のようなドメインオブジェクトモデルがあります...

各プロファイルには多くのソーシャル プロファイルを含めることができます。各ソーシャル プロファイルには、特定のソーシャル プロファイル (ソーシャル プロファイルは Facebook などのソーシャル ネットワークを表します) を介してプロファイルに関連する多くの興味があります。

2 つの質問があります。埋め込まれたドキュメントのインタレストでいくつかのフィールドを個別にインデックス化できますか? 埋め込まれたドキュメント インタレストで複合インデックスを作成できますか?

私のモデルの複雑さは、2 である埋め込みドキュメントの深いレベルであり、そのドキュメントへのパスは配列を介していると思います...

メタデータ注釈を介して春の方法で行うことはできますか? 私のモデルが間違っていると思われる場合は、私がmongoの初心者であることをお知らせくださいありがとう

aとbの2 つのフィールドがあり、ここでbはaよりもかなり高い選択性を持っています。

ここで、 aとbの両方に対してのみクエリを実行する場合(どちらか一方のフィールドを単独でクエリすることはありません)、次の 2 つのインデックスのどちらが優れているか、またその理由は次のとおりです。

1. {a: 1, b : 1}
2. {b: 1, a : 1}

Explain はほぼ同じ結果を返すようですが、選択性の高いフィールドを最初に配置する必要があることをどこかで読みました。なぜそれが理にかなっているのかわからない。

この質問のコメントでは、ソート操作用のインデックスを作成する方法を知っています。Mongodbインデックスはどのように機能しますか？

1. aしかし、 ＆bにジョイントインデックスを作成すると、単純なインデックスとどのように異なるのかを知りたいのですが。

2. そして、なぜ私たちはただ見つけることで利益を得るのでしょうかa、しかし私たちが見つけた場合b、私たちはそれから何の利益も得られませんか？ジョイントインデックスが連結a＆bのようなものであるかどうか、それでプレフィックスのためにそれから利益を得るでしょうか？

複合インデックスから得られる利点は何ですか。つまり、コレクションがあり、その中に2つのフィールドsaykey1と。をインデックス付けする必要があるとしkey2ます。key1複合インデックス{ ：1、key2：1}を持つこととはどのように異なりますか。2つの別々のインデックスを持つことの問題は何ですか。mongodbは、クエリを満たすために2つ以上のインデックスを使用できません。

MongoDB での配列 (マルチキー) インデックス作成について調べていますが、ドキュメントをあまり見つけることができなかった次の質問があります。

サブドキュメントの配列のインデックス

したがって、次のような配列フィールドがあるとします。

私は個別に（両方を一緒にではなく）のみ照会しfield.aてfield.cいます。次の選択肢から選択できると思います。

1. db.Collection.ensureIndex({field : 1});
2. db.Collection.ensureIndex({field.a : 1}); db.Collection.ensureIndex({field.c : 1});

つまり、配列全体のインデックス。または埋め込みフィールドの 2 つのインデックス。今私の質問は次のとおりです。

• オプション 1 で配列全体のインデックスをどのように視覚化しますか (それは有用ですか)? そのようなインデックスはどのようなクエリに役立ちますか?
• 私が説明したクエリの状況を考えると、上記の 2 つのオプションのどちらが優れていますか? また、その理由は何ですか?

MongoDBの既存のインデックスを削除せずに変更できますか？ドキュメントにはそれについて何も表示されていません。

文字列フィールドに一意でないインデックスがあります。コレクションは約600万のドキュメントです。レプリカセットです。

インデックスを削除して新しいインデックスを追加できることはわかっています。しかし、2つの理由で問題があります。

1）インデックスが存在しない場合、一部のクエリは非常に遅くなります。2）（私のプロジェクトに）新しいインデックスを追加すると、DBに非常に高い負荷がかかり、Webサイトの速度が明らかに低下します。