View a markdown version of this page

Pianificatore di query v3 - Amazon DocumentDB

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

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 plannerVersion valore (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 stages
  • La 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 distinct comando richiede la versione 3.0 di Planner.

  • Il aggregate comando 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. $match

  • Un filtro impostato sulla raccolta esterna di una $lookup o $graphLookup fase 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à.

Feature Differences
  • In una raccolta vuota o quando le fasi precedenti, ad esempio Match, filtrano tutti i documenti, Planner v1 restituisce il «campo» di output :0. Planner v3 e MongoDB non forniranno alcun output.

  • Con Plannerv1, {"$skip» :n} non salta se ci sono meno di n documenti restituiti dalla fase precedente. Plannerv3 e MongoDB saltano correttamente indipendentemente dal numero di documenti restituiti.

  • Quando una raccolta esterna a cui si fa riferimento in $lookup non esiste, plannerv1 genera un errore. Planner v3 e MongoDB trattano la raccolta esterna come una raccolta vuota ed eseguono $lookup.

    db.coll.aggregate([ {$lookup: {from: "does_not_exist", localField: "a", foreignField: "a", as: "c"}} ])
  • Solo Planner v1 consentirà l'utilizzo di più $search in una pipeline Planner v2/v3 genererà un errore e MongoDB non lo supporta.

    VectorSearch = { "$search": { "vectorSearch": { "vector": [0.2, 0.5, 0.8], "path": "vectorEmbedding", "similarity": "cosine", "k": 2, "efSearch": 1 }}} db.coll.aggregate([VectorSearch, VectorSearch])
  • Solo Planner v3 funziona quando la fase VectorSearch non è la prima fase. In questo caso, MongoDB genererà un errore e Planner v1 non supporta la fase $vectorSearch.

    VectorSearch = { {"$vectorSearch": { "queryVector": [0.2, 0.5, 0.8], "path": "vectorEmbedding", "similarity": "euclidean", "limit": 4, "numCandidates": 100} } db.coll.aggregate([$match:{}, VectorSearch])