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 delle prestazioni complessive fino a due volte superiore 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 \$1replaceWith, \$1vectorSearch, \$1merge, \$1set, \$1unset, \$1bucket. Planner v3 supporta anche nuove funzionalità e operatori in Amazon DocumentDB 8.0, tra cui Collation, Views, \$1merge, \$1pow, \$1rand, \$1dateTrunC, \$1, \$1. dateToParts dateFromParts
**Topics**
+ [Prerequisiti](#nqp-prerequisites)
+ [Selezione della versione 3.0 del planner come pianificatore di query predefinito](#second-concept-chapter)
+ [Best practice](#nqp-best-practices)
+ [Limitazioni](#nqp-limitations)
+ [Miglioramenti agli operatori `aggregate` `distinct`](#operator-improvements)
+ [Potenziali differenze di comportamento tra la versione 1.0, 3.0 e MongoDB di Planner](#planner-behavior-differences)
## Prerequisiti
I seguenti prerequisiti si applicano alla versione 3.0 di Planner:
+ La versione 3.0 di Planner è disponibile in tutte le regioni in cui è disponibile la versione del motore 8.0.
+ La versione 3.0 di Planner è il pianificatore di query predefinito quando è selezionata la versione del motore 8.0.
## Selezione della versione 3.0 del planner come pianificatore di query predefinito
Se hai modificato il tuo 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_parameter_groups-parameters.md) cluster.
+ Per il parametro intitolato 'PlannerVersion', modifica il valore su 3.0, che indica la versione 3.0 del planner.
+ Seleziona **Applica immediatamente** (selezionando **Applica al riavvio** la selezione verrà resa inefficace fino al successivo riavvio del cluster).
## Best practice
Per i risultati previsti, utilizza le seguenti best practice quando applichi la versione 3.0 di Planner:
+ In un cluster globale, selezionate 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 aree primarie e secondarie può causare prestazioni e comportamenti di interrogazione incoerenti.
+ L'aggiornamento alla versione 3.0 di Planner durante una finestra di manutenzione programmata o durante periodi di traffico ridotto sarà la soluzione meno problematica, in quanto potrebbe verificarsi un aumento dei tassi di errore se la versione del planner 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 ritorneranno alla versione 1.0 di Planner.
+ Sebbene Planner v1 consenta l'uso di «PlanHint» per garantire che un piano di query specifico venga selezionato dall'ottimizzatore delle query, Planner v3 non consente l'uso di «PlanHint» e si basa su ottimizzazioni interne per scegliere il piano migliore per una determinata query.
## Miglioramenti agli operatori `aggregate` `distinct`
La versione 3.0 di Planner introduce miglioramenti nelle fasi \$1aggregate e nel comando \$1distinct. Di seguito sono riportati alcuni dei miglioramenti più importanti.
+ Quando possibile, il planner sposta le fasi di \$1match nelle fasi iniziali 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 \$1lookup e \$1unwind 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 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"
}
}
}
}
```
## Potenziali differenze di comportamento tra la versione 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 fasi precedenti come match filtrano tutti i documenti, Planner v1 fornisce l'output «field» :0. Planner v3 e MongoDB non forniranno alcun output.
+ Con Plannerv1, \$1"\$1skip» :n\$1 non salta se ci sono meno di n documenti restituiti nella fase precedente. Plannerv3 e MongoDB saltano correttamente indipendentemente dal numero di documenti restituiti.
+ Quando una raccolta esterna a cui si fa riferimento in \$1lookup non esiste, plannerv1 genera un errore. Planner v3 e MongoDB trattano la raccolta esterna come una raccolta vuota ed eseguono \$1lookup.
```
db.coll.aggregate([
{$lookup: {from: "does_not_exist", localField: "a", foreignField: "a", as: "c"}}
])
```
+ Solo Planner v1 consentirà l'utilizzo di più \$1search 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 \$1VectorSearch.
```
VectorSearch = { {"$vectorSearch": {
"queryVector": [0.2, 0.5, 0.8],
"path": "vectorEmbedding",
"similarity": "euclidean",
"limit": 4,
"numCandidates": 100} }
db.coll.aggregate([$match:{}, VectorSearch])
```
------