問題タブ [compound-index]

私はmongodbコレクションを持っています。

p1フィールド、p2、 にインデックスを作成したいと考えていますp3。ドキュメントにp2またはが含まれていない可能性がありますp3。インデックスはどのように作成すればよいですか?

ドキュメントはそれについて少し不明確なようです。

1) 複合インデックスはマルチフィールド SORTING (順序と方向に依存) のパフォーマンスを向上させることを明確に述べています。

2) 複数フィールド MACHも改善すると思わせるフレーズが 1 つあります(SQL の例え: a=1 および b=2 および c<5)

https://docs.mongodb.org/v3.0/tutorial/optimize-query-performance-with-indexes-and-projections/

クエリが複数のフィールドを検索する場合は、複合インデックスを作成します。

並べ替えについては何も言いません。

では、フィールド a、b、c の複合インデックスは、(a=1、b=2、c<5) のようなクエリの 3 つの単一フィールド インデックスよりもマッチング パフォーマンスが優れているのでしょうか?

パラメータがクエリされるのと同じ順序で複合インデックスを作成する必要があります。この順序は、パフォーマンスに関してまったく重要ですか?

sex(99.9% の確率で「男性」または「女性」ですが、文字列 (バイナリではない)) と のインデックスを持つ、地球上のすべての人間のコレクションがあるとしnameます。

sex特定のを持つ特定のすべての人、たとえば"John"nameという名前のすべての「男性」を選択できるようにしたい場合、 first またはfirstを使用して複合インデックスを使用する方がよいでしょうか? なぜだめですか）？sexname

カーディナリティの低いフィールドにインデックスを配置しても意味がないことを 読みました。これは、複合インデックス自体に当てはまりますか?

クエリを使用すると、次のようになります。

distinctobject_typeの数は時間の経過とともに増加します (おそらく最大 10 または 20 を超えない) が、最初は約 2 または 3 から始まります。

同様に、ハッシュ インデックスを調べる価値はありますか?

更新：

ownerそしてtarget大きく成長するでしょう。これは、 (つまりファイル)ownerを「所有」するファイル システムのようなものと考えてください。targetただし、UNIX システムと同様に、ファイルはフォルダー、シンボリック リンク、または通常のファイル (したがって、タイプ) である可能性があります。したがって、 は 3 つしかありませんがobject_type、ownerとのtarget組み合わせは、タイプが均等に分散された数千のエントリを持つことができます。

正常に動作するが遅い次のクエリがありますが、適切にインデックスを付ける方法がわかりません。

次のインデックスで試しました（Thinky.jsを使用）：

そして、それを照会するために、これを試しました：

メッセージ テーブルは次のようになります。

しかし、私はゼロの結果を得ることになります。どんな提案でも大歓迎です！

データベース内にリクエストテーブルがあり、リクエストが処理されていないことを示す「保留中」、ミリ秒単位の有効期限（エポック）を追跡する「有効期限」、「カウント」などのいくつかのフィールドで構成されています。リクエストが発生するたびに 0 までカウントダウンします。

ここで、リクエストの有効期限が切れているか、カウントが 0 に減少し、保留中が true であるすべてのリクエストを検索します。次に、有効期限に基づいて結果を並べ替えます。

このためのインデックスを作成しようとしましたが、explain() コマンドの結果に基づいて、MongoDB がインデックスを使用していないと確信しています。そのようなクエリの複合インデックスとは何かについて何か提案はありますか?

一般的な用語で言えば、クエリは本質的に (A OR B) AND C が C によって並べ替えられます。

これは、Java の Morphia を介して作成したクエリです (MongoDB は初めてです) ->

さまざまなコレクションに何百万ものドキュメントがあります。

私のアプリケーションは、いくつかの増分データを MongoDB に定期的に更新する必要があります。どうすればこれを達成できますか?

増分データのすべてのレコードについて、レコードが存在する場合は新しい値で更新する必要があり、そうでない場合は挿入する必要があります。

上記が私のデータであり、lifnr と bukrs が一意の制約を持つ複合インデックスであると仮定します。既存のものと同じ {lifnr & bukrs} 値を持つ新しいレコードは、古い量を置き換える必要があります。一意の {lifnr & bukrs} の新しいレコードである場合は、それを挿入/追加する必要があります。

アプローチまでご案内します。ありがとう

複数の配列フィールドを持つオブジェクトのコレクションがあります。何かのようなもの：

次のようなクエリを最適化するにはどうすればよいですか?

複合インデックスは、複数の配列フィールドを持つことはできません。配列フィールドからすべてのデータを新しいフィールドにコピーし、searchArrayこの配列のみを含む複合インデックスを追加すると効果がありますか? それは良いアプローチですか？

サブクエリと自己結合を使用した次のクエリがあります。

私はこれに定義された次のインデックスを持っています:

EXPLAIN を使用したクエリを見ると、カバー インデックス idx_bucket を使用したサブクエリは確実に最適化されていますが、自己結合と where 句は最適化されていません。さらに、なぜ と のみが使用され、 が に表示されていると報告patient_sidするattribute_idのused_key_partsですattachment_conditionかlft(rgtこれはどういう意味ですか?)。と 'rgt` はどちらもlft、特別なプロパティを持たない整数として定義されているだけなので、カバー インデックスで使用されないのはなぜですか?

さらに奇妙なのは、私が定義するときです

patient_sidに登録されているだけused_key_parts.さらにからfilteredへ ドロップ!1.60%11.00%

MongoDB 2.4.x インスタンスを 2.6 にアップグレードしようとしています。このプロセスの一環としてdb.upgradeCheckAllDBs()、データがアップグレードに適した状態であることを確認する方法を実行しました。このチェックにより、フィールドにインデックスが定義されているデータベース内のレコードが多数見つかりましたが、キーが 1024 バイトの制限を超えていました。つまり、次の形式のエラーが表示されました。

ドキュメントのfieldフィールドに 1024 バイト (キーの制限) を超える値が含まれていることを示します。

これは簡単に解決できます (上のインデックスを削除するだけですfield) が、複合インデックスについてはどうでしょうか。例: 次のようなインデックスがあるとします。

これは、ドキュメントの長さがフィールドemailとmetaフィールドを合わせて1024 バイトを超えていたことを意味しますか? それとも、フィールドごとに 1024 バイトですか、それとも他の組み合わせですか? つまり、複合インデックスの場合、キーの長さが 1024 バイトの制限を超えていることをどのように判断するのでしょうか?