web-dev-qa-db-ja.com

_idインデックスはいつ使用されますか?

MongoDBが__id_インデックスを使用するのはいつですか

Index IntroductionAnalyze Query Performance 、および Query Plans では、それについて具体的な情報は見つかりませんでした。

.sort({_id: -1})を介したクエリの最後で__id_で並べ替えると、.explain()は明示的にインデックスの使用を示します。ただし、すべてのCOLLSCAN操作で暗黙的に使用されている可能性があります。

それは、__id_による並べ替え/クエリ時にのみアクセスされる通常のインデックスだけですか、それとも.explain()では表示されない非表示の用途がありますか?

4
serv-inc

.sort({_ id:-1})を介したクエリの最後で_idでソートする場合、.explain()はインデックスの使用を明示的に示します。ただし、すべてのCOLLSCAN操作で暗黙的に使用されている可能性があります。

COLLSCAN操作はコレクションスキャンです。これは、インデックスが使用されておらず、コレクションが 自然順序 で反復されていることを示します。

クエリに条件がなく、__id_による並べ替えを要求した場合、__id_インデックスが期待される順序で結果を返すための最良の候補になります。 MongoDB 3.0では、これがCOLLSCANではなくIXSCANとして示されることを期待しています。

_idで並べ替え/クエリを実行するときにのみアクセスされるのは、通常のインデックスだけですか?

ご想像のとおり、__id_インデックスは通常のインデックスであり、__id_によるクエリまたは並べ替えの際にクエリプランナーによって選択される候補です。

.explain()で表示されない非表示の用途がありますか

explain() results は、関連するクエリ計画情報を表示しますが、デフォルトでは、成功した計画の概要のみが含まれます。 .explain(true)を使用すると、より詳細な情報(評価された候補プランなど)を表示できます。

MongoDB 3.0のexplain()には、実際には3つの冗長モードがあります。

  • queryPlanner:デフォルト
  • executionStats:受賞プランの詳細
  • allPlansExecution(別名true):すべての計画に関する情報

__id_インデックスの使用法は他にもいくつかありますが、完全には隠されていませんが、明確ではない場合があります。

  • レプリケーションには一意の__id_インデックスが必要です(歴史的メモ:MongoDB 2.2より前のバージョンでは、__id_インデックスなしでキャップされたコレクションを作成および複製することが可能でした)。

  • a snapshot cursor コレクションを__id_の順序で反復して、クエリがドキュメントを複数回返さないようにします。

3
Stennie

MongoDBでは、コレクションに格納されたドキュメントには、主キーとして機能する一意の_idフィールドが必要です。 MongoDBは、_idフィールドが指定されていない場合、_idフィールドのデフォルト値としてObjectIdsを使用します。つまり、ドキュメントに最上位の_idフィールドが含まれていない場合、MongoDBドライバーはObjectIdを保持する_idフィールドを追加します。さらに、mongodが_idフィールドを含まない挿入するドキュメントを受け取った場合、mongodはObjectIdを保持する_idフィールドを追加します。

ObjectId is a 12-byte BSON type, constructed using:

a 4-byte value representing the seconds since the Unix Epoch,
a 3-byte machine identifier,
a 2-byte process id, and
a 3-byte counter, starting with a random value.

MongoDBクライアントは、一意のObjectIdを持つ_idフィールドを追加する必要があります。 _idフィールドにObjectIdを使用すると、次の追加の利点があります。

  • Mongoシェルでは、getTimestamp()メソッドを使用して、ObjectIdの作成時間にアクセスできます。
  • ObjectId値を格納する_idフィールドでの並べ替えは、作成時間による並べ替えとほぼ同じです。

代替案-以下は、_idの値を格納するための一般的なオプションです。

  • ObjectIdを使用します。
  • 可能な場合は、自然な一意の識別子を使用します。これにより、スペースが節約され、追加のインデックスが回避されます。
  • 自動インクリメント番号を生成します。自動インクリメントシーケンスフィールドの作成を参照してください。
  • アプリケーションコードでUUIDを生成します。コレクションおよび_idインデックスにUUID値をより効率的に格納するには、UUIDをBSON BinDataタイプの値として格納します。
  • BinDataタイプのインデックスキーは、バイナリサブタイプの値が0〜7または128〜135の範囲にあり、バイト配列の長さが0、1、2、3の場合に、インデックスに効率的に格納されます。 、4、5、6、7、8、10、12、14、16、20、24、または32。
  • ドライバーのBSON UUID機能を使用してUUIDを生成します。ドライバーの実装では、UUIDシリアル化ロジックと非シリアル化ロジックが異なる方法で実装される場合があり、他のドライバーと完全に互換性がない場合があることに注意してください。 UUIDの相互運用性については、ドライバーのドキュメントを参照してください。

詳細については MongoDBを参照

3
Hitesh Mundra