Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Pianificatore di query v3
La versione 3 di Planner in Amazon DocumentDB 8.0 supporta 21 fasi di aggregazione, incluse 6 nuove fasi. Planner V3 è dotato di supporto integrato per comandi distinti. Offre un miglioramento complessivo delle prestazioni fino a 2 volte rispetto a Planner v2 in Amazon DocumentDB 5.0. Tutte le nuove funzionalità e gli operatori di Amazon DocumentDB 8.0 sono compatibili con Planner v3. Le nuove fasi di aggregazione in Amazon DocumentDB 8.0 supportate da Planner v3 includono $replaceWith, $vectorSearch, $merge, $set, $unset, $bucket. Planner v3 supporta anche nuove funzionalità e operatori in Amazon DocumentDB 8.0, tra cui Collation, Views, $merge, $pow, $rand, $DateTrunc, $date, $date. ToParts FromParts
Argomenti
Prerequisiti
I seguenti prerequisiti si applicano alla versione 3.0 di Planner:
La versione 3.0 di Planner è disponibile Regioni AWS ovunque sia disponibile la versione 8.0 del motore.
La versione 3.0 di Planner è il pianificatore di query predefinito quando è selezionata la versione 8.0 del motore.
Selezione della versione 3.0 di Planner come pianificatore di query predefinito
Se hai modificato il pianificatore di query predefinito in Amazon DocumentDB 8.0 e devi tornare al planner v3, puoi farlo dalla console o dalla CLI:
Segui i passaggi indicati per modificare il gruppo di parametri del Modifica dei parametri del cluster Amazon DocumentDB cluster.
Per il parametro denominato 'plannerVersion', modifica il valore in 3.0, indicando la versione 3.0 di planner.
Seleziona Applica immediatamente (selezionando Applica al riavvio la selezione sarà inefficace fino al successivo riavvio del cluster).
Best practice
Per ottenere i risultati previsti, utilizza le seguenti best practice quando applichi la versione 3.0 di Planner:
In un cluster globale, seleziona lo stesso
plannerVersionvalore (1.0 o 2.0 o 3.0) nei gruppi di parametri del cluster per entrambe le regioni. Tieni presente che la selezione di versioni diverse del planner nelle regioni primarie e secondarie può causare comportamenti e prestazioni delle query incoerenti.L'aggiornamento alla versione 3.0 di Planner durante una finestra di manutenzione programmata o durante i periodi di traffico ridotto sarà il meno problematico, poiché potrebbe verificarsi un aumento dei tassi di errore se la versione del pianificatore viene modificata quando i carichi di lavoro sono in esecuzione attiva.
Limitazioni
Le seguenti limitazioni si applicano alla versione 3.0 di Planner:
La versione 3.0 di Planner non è supportata nei cluster elastici, che torneranno alla versione 1.0 di Planner.
Mentre Planner v1 consente l'uso di «PlanHint» per garantire che un piano di query specifico venga selezionato dall'ottimizzatore di query, Planner v3 non consente l'uso di «PlanHint» e si basa su ottimizzazioni interne per scegliere il piano migliore per la determinata query.
Miglioramenti agli operatori aggregati e distinti
La versione 3.0 di Planner introduce miglioramenti nelle fasi $aggregate e nel comando $distinct. Di seguito sono riportati alcuni dei miglioramenti più degni di nota.
Quando possibile, il planner sposta $match nelle fasi precedenti della pipeline, riducendo il numero di documenti elaborati nelle fasi successive.
//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 } } ])Il planner combina automaticamente le fasi $lookup e $unwind quando operano sullo stesso campo, riducendo l'elaborazione intermedia dei dati e migliorando le prestazioni.
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 stagesLa versione 3.0 di Planner introduce una nuova strategia di esecuzione di Distinct Scan che migliora significativamente le prestazioni per operazioni distinte su indici a bassa cardinalità.
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" } } } }
Pianifica i filtri della cache
La versione 3.0 di Planner supporta i filtri della cache del piano, chiamati anche filtri di indice, che consentono di limitare il set di indici che il planner considera per una specifica forma di query. I filtri vengono impostati con un comando del database e applicati sul server, quindi se si verifica una regressione delle query è possibile attenuarla senza modificare il codice dell'applicazione.
La versione 3.0 di Planner applica i filtri della cache del piano a più comandi rispetto alla versione 2.0 di Planner:
Il
distinctcomando richiede la versione 3.0 di Planner.Il
aggregatecomando richiede la versione 3.0 del planner e Amazon DocumentDB 8.0.2. Un filtro si applica quando la pipeline legge la raccolta attraverso una fase principale.$matchUn filtro impostato sulla raccolta esterna di una
$lookupo$graphLookupfase determina l'indice utilizzato per scansionare quella raccolta esterna. Ciò richiede anche la versione 3.0 di Planner e Amazon DocumentDB 8.0.2.
Per ulteriori informazioni sul riferimento ai comandi, sulle forme di query supportate, sugli esempi funzionanti e su come i filtri interagiscono con i suggerimenti, consulta. Pianifica i filtri della cache
Potenziali differenze di comportamento tra le versioni 1.0, 3.0 e MongoDB di Planner
In alcuni casi limite, è possibile che la versione 3.0 di Planner produca risultati leggermente diversi dalla versione 1.0 di Planner. Questa sezione illustra alcuni esempi di queste possibilità.