Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Perencana kueri v3
Planner Versi 3 di Amazon DocumentDB 8.0 mendukung 21 tahap agregasi, termasuk 6 tahap baru. Planner V3 hadir dengan dukungan bawaan untuk perintah yang berbeda. Ini menawarkan peningkatan kinerja hingga 2x secara keseluruhan dibandingkan Planner v2 di Amazon DocumentDB 5.0. Semua fitur dan operator baru di Amazon DocumentDB 8.0 kompatibel dengan Planner v3. Tahapan agregasi baru di Amazon DocumentDB 8.0 yang didukung oleh Planner v3 termasuk $replaceWith, $vectorSearch, $merge, $set, $unset, $bucket. Planner v3 juga mendukung fitur dan operator baru di Amazon DocumentDB 8.0 termasuk Collation, Views, $merge, $pow, $rand, $dateTrunc, $, $. dateToParts dateFromParts
Topik
Prasyarat
Prasyarat berikut berlaku untuk perencana versi 3.0:
Planner versi 3.0 tersedia di semua wilayah di mana engine versi 8.0 tersedia.
Perencana versi 3.0 adalah perencana kueri default ketika engine versi 8.0 dipilih.
Memilih perencana versi 3.0 sebagai perencana kueri default
Jika Anda mengubah perencana kueri default di Amazon DocumentDB 8.0, dan perlu kembali ke planner v3, Anda dapat melakukannya dari konsol atau CLI:
Ikuti langkah-langkah Memodifikasi parameter cluster Amazon DocumentDB untuk memodifikasi grup parameter cluster Anda.
Untuk parameter berjudul 'PlannerVersion', ubah nilainya menjadi 3.0 yang menunjukkan perencana versi 3.0.
Pilih Terapkan segera (memilih Terapkan saat reboot akan membuat pilihan tidak efektif hingga reboot cluster berikutnya).
Praktik terbaik
Untuk hasil yang diharapkan, gunakan praktik terbaik berikut saat menerapkan perencana versi 3.0:
Di cluster global, pilih
plannerVersionnilai yang sama (1.0 atau 2.0 atau 3.0) di grup parameter cluster untuk kedua wilayah. Perhatikan bahwa memilih versi perencana yang berbeda di wilayah primer dan sekunder dapat menyebabkan perilaku dan kinerja kueri yang tidak konsisten.Memperbarui ke perencana versi 3.0 selama jendela pemeliharaan terjadwal atau selama periode lalu lintas yang dikurangi akan menjadi yang paling tidak mengganggu, karena mungkin ada peningkatan tingkat kesalahan jika versi perencana diubah saat beban kerja aktif berjalan.
Batasan
Batasan berikut berlaku untuk perencana versi 3.0:
Planner versi 3.0 tidak didukung dalam cluster elastis, yang akan kembali ke versi perencana 1.0.
Sementara Planner v1 memungkinkan penggunaan 'PlanHint' untuk memastikan bahwa rencana kueri tertentu dipilih oleh pengoptimal kueri, Planner v3 tidak mengizinkan penggunaan 'planHint' dan bergantung pada pengoptimalan internal untuk memilih paket terbaik untuk kueri yang diberikan.
Perbaikan aggregate dan distinct Operator
Planner versi 3.0 memperkenalkan peningkatan di seluruh tahapan $agregat, dan perintah $distinct. Berikut ini adalah beberapa perbaikan yang paling penting..
Perencana memindahkan tahap $match lebih awal di pipeline bila memungkinkan, mengurangi jumlah dokumen yang diproses oleh tahap berikutnya.
//Planner v1 db.orders.aggregate([ { $project: { customerId: 1, orderDate: 1, totalAmount: 1 } }, { $match: { customerId: { $gt: 1000 } } } ]) // Planner v3 pulls up the match since customerId exists in original documents // Optimized internally as: db.orders.aggregate([ { $match: { customerId: { $gt: 1000 } } }, // Pulled up before project { $project: { customerId: 1, orderDate: 1, totalAmount: 1 } } ])Perencana secara otomatis menggabungkan tahap $lookup dan $unwind ketika mereka beroperasi di bidang yang sama, mengurangi pemrosesan data perantara dan meningkatkan kinerja.
Example query: //Planner v1 db.orders.aggregate([ { $lookup: { from: "products", localField: "productId", foreignField: "_id", as: "productInfo" } }, { $unwind: "$productInfo" }, { $project: { orderDate: 1, "productInfo.name": 1, "productInfo.price": 1 } } ]) // Planner version 3.0 optimizes this internally by coalescing the $lookup and $unwind stagesPlanner versi 3.0 memperkenalkan strategi eksekusi Distinct Scan baru yang secara signifikan meningkatkan kinerja untuk operasi yang berbeda pada indeks kardinalitas rendah.
Example query: //// If there is a low cardinality index on "category", you may see a query plan like below db.explain().products.distinct("category") "queryPlanner" : { "plannerVersion" : 3, "namespace" : "db.products", "winningPlan" : { "stage" : "AGGREGATE", "inputStage" : { "stage" : "DISTINCT_SCAN", "inputStage" : { "stage" : "IXONLYSCAN", "indexName" : "category_1", "direction" : "forward" } } } }
Potensi perbedaan perilaku antara perencana versi 1.0, 3.0, dan MongoDB
Dalam beberapa kasus tepi, ada kemungkinan bahwa perencana versi 3.0 dapat menghasilkan hasil yang sedikit berbeda dari perencana versi 1.0. Bagian ini membahas beberapa contoh kemungkinan ini.