ApsaraDB for MongoDB:Rencana kueri dan replanning kueri

Status entri cache rencana

Entri cache rencana dapat berada dalam salah satu status berikut:

Perilaku cache rencana

Cache rencana disimpan sepenuhnya dalam memori dan tidak bertahan setelah restart. Cache ini dihapus dalam situasi berikut:

• Database MongoDB di-restart.

• Koleksi atau indeks dihapus.

Cache rencana juga memiliki batas ukuran dan mengikuti mekanisme penggantian cache least recently used (LRU). Entri yang lebih jarang diakses akan dikeluarkan dari cache seiring waktu.

Perintah manajemen cache rencana

Anda dapat menjalankan perintah berikut untuk mengelola entri cache rencana untuk koleksi tertentu:

Contoh pengambilan rencana kueri yang di-cache:

db.<collection>.getPlanCache().getPlansByQuery({"query": {"name": "testname"}, "sort": { "name": 1 })

queryHash dan planCacheKey

MongoDB 4.2 dan versi yang lebih baru memperkenalkan queryHash untuk mengidentifikasi bentuk kueri. Setiap bentuk kueri dikaitkan dengan nilai queryHash. MongoDB 4.2 juga memperkenalkan planCacheKey, yang berbeda dari queryHash karena merupakan fungsi dari bentuk kueri dan indeks yang tersedia untuk bentuk tersebut. Jika indeks yang mendukung bentuk kueri dibuat atau dihapus, nilai planCacheKey dapat berubah, tetapi nilai queryHash tetap tidak berubah.

Contoh

Pertimbangkan koleksi dengan indeks dan bentuk kueri berikut:

Indeks:

db.foo.createIndex( { x: 1 } )
db.foo.createIndex( { x: 1, y: 1 } )
db.foo.createIndex( { x: 1, z: 1 }, { partialFilterExpression: { x: { $gt: 10 } } } )

Bentuk kueri:

db.foo.explain().find( { x: { $gt: 5 } } ) // Operasi kueri 1
db.foo.explain().find( { x: { $gt: 20 } } ) // Operasi kueri 2

Indeks ketiga menggunakan ekspresi filter parsial yang mensyaratkan x > 10. Oleh karena itu, indeks ini dapat mendukung operasi kueri 2 (x > 20) tetapi tidak operasi kueri 1 (x > 5). Akibatnya, kedua kueri memiliki nilai planCacheKey yang berbeda. Jika indeks baru {x:1, a:1} dibuat, nilai planCacheKey untuk kedua operasi kueri akan berubah.

Dampak

• Replanning kueri yang sering dapat menurunkan performa kueri.

• Replanning kueri yang berlebihan dapat menyebabkan contention pada mutex lock, sehingga mengakibatkan tingginya utilisasi CPU.

Mengidentifikasi replanning

Anda mungkin menemukan kata kunci "replanned":true dalam log kueri lambat. Kata kunci ini menunjukkan bahwa query planner tidak dapat mempertahankan rencana yang konsisten efisien untuk bentuk kueri tertentu.

Contoh entri log kueri lambat:

"replanned":true,"replanReason":"cached plan was less efficient than expected: expected trial execution to take X works but it took at least 10X works"

Solusi

Solusi berikut diurutkan dari perbaikan jangka panjang yang direkomendasikan hingga mitigasi segera dan langkah darurat terakhir.

db.<collection>.find({a:"ABC"},{b:1,_id:0}).sort({c:1}).hint({ a:1, c:1, b:1} )

// Setel filter indeks.
db.runCommand(
   {
      planCacheSetFilter: "<collection>",
      query: { a: "ABC" },
      projection: { b: 1, _id: 0 },
      sort: { c: 1 },
      indexes: [
         { a: 1, c: 1 , b: 1 }
      ]
   }
)
// Hapus filter indeks yang ada.
db.runCommand(
   {
      planCacheClearFilters: "<collection>"
   }
)