モンゴDBの10種類のインデックスを知っていますか?

なぜインデックスがあるのか
検索が速い!検索が速い!検索が速い!
MongoDBの10種類のインデックス?
索引構文の作成:

db..createIndex( ,  )

我々のrecord Collectionには次のdocumentが存在します.

{
  "_id": ObjectId("570c04a4ad233577f97dc459"),
  "score": 1034,
  "userId": 123,
  "location": { state: "ZH", city: "ChengDu" },
  "addr": [
    {zip: "10036", detail: "     "},
    {zip: "94231", detail: "     701"}
  ]
}

_idインデックス
mongodbは自動的にdocumentの_idフィールドにインデックスを付けるので_idクエリーは_idクエリー
シングルキーインデックス

db.records.createIndex( { score: 1 })

複合インデックス

db.records.createIndex( { userId: 1, score: 1})

多値索引

db.records.createIndex( { "addr.zip": 1 })

空間インデックス
MongoDBは、地理空間インデックスと呼ばれる座標平面クエリーに特別なインデックスを提供します.このクエリには2つの次元が必要なので、パラメータは2 dです.

db.map.ensureIndex({"gps" : "2d"});

gpsキーの値は、2つの要素を含む配列または2つのキーを含む埋め込みドキュメントのペアでなければなりません.

{"gps" : [0,100]}
{"gps" : {"x" : -30 , "y" : 30}}
{"gps" : {"latitude" : -180, "longitude" : 180 }}

キー名は自由にできます.デフォルトでは、地理空間インデックスの仮定値の範囲は-180~180(緯度に便利)です.パラメータを使用してインデックスをカスタマイズすることもできます.たとえば、次の星図などです.

db.star.trek.ensureIndex({"light-years" : "2d"} , {"min" : -1000, "max" : 1000, bits；10}， {collation: {locale: "simple"}});

上のbitsはインデックス精度を指定し、デフォルトでは2 d indexは26ビット精度を使用し、デフォルト範囲-180~180では約60 cm誤差に等しく、最大32ビット精度を設定できます.インデックス精度はクエリー精度に影響を及ぼさず、精度を低下させる利点は、挿入操作の処理コストが低く、スペースが少ないことです.より高い精度の利点は、結果を返すためにインデックスの小さな部分をクエリーすることです.
collation(ソート・ルール)を使用すると、文字列の比較に文字列固有の言語固有のルール(アルファベットやアクセント記号などのルール)を指定できます.
地理空間のクエリーには$nearが必要です.パラメータとして2つのターゲット値の配列が必要です.

db.map.find({"gps" : {"$near" : [40,-73]}}).limit(10);

デフォルトでは100個のドキュメントを調べますが、これ以上必要でない場合は、リソースを節約するために少ない値を設定する必要があります.
また、

db.runCommand({geoNear : "map", near: [40,-73],num : 10})

geoNear方式では、各ドキュメントからクエリーポイントまでの距離が返されます.
長方形と円形のすべての点を検索することもできます.このとき、元の$nearを$geoWithinに変更します.長方形で$boxオプションを使用するには、パラメータは2つの要素の配列で、1つ目の要素は左下隅座標を指定し、2つ目は右上隅座標を指定します.

db.map.find({"gps" : {"$geoWithin " : {"$box" : [[10,20],[15,30]]}}});

円形をクエリーする場合は$centerを使用します.パラメータは円心と半径になります.

db.map.find({"gps" : {"$geoWithin " : {"$center" : [[12,25],5]}}});

地理空間クエリーでは、平面ジオメトリを使用するか、球面ジオメトリを使用するか、使用するクエリーとインデックスのタイプに応じて決定できます.2 dsphereインデックスは球面ジオメトリのみをサポートし、2 dインデックスは平面ジオメトリと球面ジオメトリを同時にサポートします.しかし、2 dsphereインデックスで球面ジオメトリを使用するクエリは、より効率的で正確になります.
2dsphere :
https://docs.mongodb.com/manu...
その応用シーンは、近くの美食を探したり、近くの駐車場を探したりするデータです.
全文索引
索引の作成:

db..createIndex({: "text"});

クエリーデータ:

db..find( { $text: { $search: "green" } } );

クエリーとソート:

db..find(
{
 "$text": {
    "$search": "green"
  }
},
{
  "textScore": {
    "$meta": "textScore"
  }
}
).sort({
  "textScore": {
    "$meta": "textScore"
  }
})

ここでtextScoreは、集合内のフィールドではなく、mongodbが検索結果に基づいてそのデータのスコアを計算する(整合度予告、値が大きい)ことに注意してください.
TTLインデックス
この索引は、実際にはライフサイクルを持つインデックスであり、ドキュメントごとにタイムアウト時間を設定することができます.1つのドキュメントが予め設定されたエージングレベルに達すると削除されます.

db.user_session.createIndex({"updated":1},{expireAfterSeconds:60*60*24});

ドキュメントのupdatedフィールドが存在し、その値が日付タイプの場合、サーバ時間がドキュメントのupdatedフィールドの時間より遅いexpireAfterSeconds秒の場合、ドキュメントは削除されます.

db.getCollection('user_session').insert(
  {
    _id: NumberInt(1),
    "updated":new Date(),
     username:'lisi'
  }
);

部分インデックス

db..createIndex(
{'wechat': 1 },
{
  "partialFilterExpression": {
    "wechat": {
      "$exists": true
    }
  }
}
)

上のインデックスは、wechatフィールドが存在するドキュメントをインデックスすることを示します.一部のインデックスは、指定したフィルタ式に一致するインデックスセット内のドキュメントのみで、インデックスの作成とメンテナンスのパフォーマンスコストを削減します.
一部のインデックスは、疎インデックス機能のスーパーセットを提供し、疎インデックスよりも優先的に使用する必要があります.
疎索引

db.addresses.createIndex( { "xmpp_id": 1 }, { sparse: true } )

インデックスなしインデックスにはxmpp_は含まれませんidフィールドのドキュメント.
ハッシュ索引

db.collection.createIndex( { _id: "hashed" })

ハッシュインデックスとは、あるフィールドのhash値に従ってインデックスを作成することを意味し、現在は主にMongoDB Sharded ClusterのHashスライスに使用されている.hashインデックスはフィールドが完全に一致するクエリーのみを満たし、範囲クエリーを満たすことができない
バックグラウンド方式でインデックスを作成

db..createIndex( , {background: true})

インデックスの作成には時間と労力がかかり、多くのリソースを消費する必要があります.{background:true}オプションを使用すると、このプロセスをバックグラウンドで完了させ、リクエストを正常に処理できます.このオプションが含まれていない場合、データベースはインデックス作成中のすべてのリクエストをブロックします.ブロックすると、インデックスがより速く作成され、その間に応答できないことを意味します.バックグラウンドで行っても通常の操作に影響するので、どうでもいい時に選んだほうがいいです.バックグラウンドでインデックスを作成すると、サーバがダウンタイムしないように負荷が増加します.
ただし、4.2リリースでは、すべてのインデックス構築で最適化された構築プロセスが使用され、構築プロセスの開始と終了時にのみ排他ロックが保持されます.残りの構築プロセスでは、インタリーブされた読み書き操作が発生します.この属性を指定すると、MongoDBはこのオプションを無視します.