Abfrageplaner v3

Planner Version 3 in Amazon DocumentDB 8.0 unterstützt 21 Aggregationsstufen, darunter 6 neue Stufen. Planner V3 bietet integrierte Unterstützung für verschiedene Befehle. Es bietet eine bis zu 2-fache Gesamtleistungsverbesserung gegenüber Planner v2 in Amazon DocumentDB 5.0. Alle neuen Funktionen und Operatoren in Amazon DocumentDB 8.0 sind mit Planner v3 kompatibel. Zu den neuen Aggregationsstufen in Amazon DocumentDB 8.0, die von Planner v3 unterstützt werden, gehören $replaceWith, $vectorSearch, $merge, $set, $unset, $bucket. Planner v3 unterstützt auch neue Funktionen und Operatoren in Amazon DocumentDB 8.0, darunter Collation, Views, $merge, $pow, $rand, $dateTrunc, $date, $date. ToParts FromParts

Voraussetzungen

Die folgenden Voraussetzungen gelten für die Planner-Version 3.0:

• Planner Version 3.0 ist überall dort verfügbar AWS-Regionen , wo Engine-Version 8.0 verfügbar ist.

• Planner Version 3.0 ist der Standard-Abfrageplaner, wenn Engine-Version 8.0 ausgewählt ist.

Auswahl der Planner-Version 3.0 als Standard-Abfrageplaner

Wenn Sie Ihren Standard-Abfrageplaner in Amazon DocumentDB 8.0 geändert haben und zu Planner v3 zurückkehren müssen, können Sie dies über die Konsole oder CLI tun:

• Folgen Sie den Schritten unterÄnderung der Amazon DocumentDB-Cluster-Parameter, um die Parametergruppe Ihres Clusters zu ändern.

• Ändern Sie den Wert für den Parameter mit dem Titel „PlannerVersion“ auf 3.0, was auf die Planerversion 3.0 hinweist.

• Wählen Sie Sofort anwenden (wenn Sie Beim Neustart anwenden auswählen, wird die Auswahl bis zum nächsten Neustart des Clusters unwirksam).

Bewährte Methoden

Verwenden Sie bei der Anwendung von Planner Version 3.0 die folgenden bewährten Methoden, um die erwarteten Ergebnisse zu erzielen:

• Wählen Sie in einem globalen Cluster den gleichen plannerVersion Wert (1,0 oder 2,0 oder 3,0) in den Cluster-Parametergruppen für beide Regionen aus. Beachten Sie, dass die Auswahl unterschiedlicher Planerversionen in primären und sekundären Regionen zu einem inkonsistenten Abfrageverhalten und einer inkonsistenten Leistung führen kann.

• Die Aktualisierung auf Planner-Version 3.0 während eines geplanten Wartungsfensters oder in Zeiten mit reduziertem Verkehrsaufkommen ist am wenigsten störend, da es zu erhöhten Fehlerraten kommen kann, wenn die Planner-Version geändert wird, während Workloads aktiv ausgeführt werden.

Einschränkungen

Die folgenden Einschränkungen gelten für Planner Version 3.0:

• Planner-Version 3.0 wird in elastischen Clustern nicht unterstützt. Diese werden auf Planner-Version 1.0 zurückgreifen.

• Während Planner v1 die Verwendung von 'PlanHint' ermöglicht, um sicherzustellen, dass ein bestimmter Abfrageplan vom Abfrageoptimierer ausgewählt wird, erlaubt Planner v3 die Verwendung von 'PlanHint' nicht und stützt sich auf interne Optimierungen, um den besten Plan für die angegebene Abfrage auszuwählen.

Verbesserungen an aggregierten und unterschiedlichen Operatoren

Planner Version 3.0 führt Verbesserungen in allen $aggregate-Stufen und beim $distinct-Befehl ein. Im Folgenden sind einige der bemerkenswertesten Verbesserungen aufgeführt..

• Der Planer verschiebt $match-Phasen, wenn möglich, früher in der Pipeline, wodurch die Anzahl der Dokumente reduziert wird, die in den nachfolgenden Phasen verarbeitet werden.

  //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 } }
  ])

• Der Planer kombiniert automatisch die Schritte $lookup und $unwind, wenn sie dasselbe Feld bearbeiten. Dadurch werden zwischengeschaltete Datenverarbeitungsvorgänge reduziert und die Leistung verbessert.

  
                   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
               

• In Planner Version 3.0 wird eine neue Strategie zur Ausführung von Distinct Scans eingeführt, die die Leistung bei unterschiedlichen Operationen mit Indizes mit niedriger Kardinalität erheblich verbessert.

  
                   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"
                          }
                  }
          }
  }
  
               

Cache-Filter planen

Planner Version 3.0 unterstützt Plan-Cache-Filter, auch Indexfilter genannt, mit denen Sie die Gruppe von Indizes einschränken können, die der Planer für eine bestimmte Abfrageform berücksichtigt. Filter werden mit einem Datenbankbefehl festgelegt und auf den Server angewendet. Wenn Sie also eine Abfrageregression feststellen, können Sie diese abmildern, ohne Ihren Anwendungscode zu ändern.

Planner Version 3.0 wendet Plan-Cache-Filter auf mehr Befehle an als Planner Version 2.0:

• Für den distinct Befehl ist Planner Version 3.0 erforderlich.

• Für den aggregate Befehl sind Planner Version 3.0 und Amazon DocumentDB 8.0.2 erforderlich. Ein Filter wird angewendet, wenn die Pipeline die Sammlung durch eine führende $match Phase liest.

• Ein Filter, der für die ausländische Sammlung einer $lookup $graphLookup OR-Stufe gesetzt wird, steuert den Index, der zum Scannen dieser fremden Sammlung verwendet wird. Dazu sind auch Planner Version 3.0 und Amazon DocumentDB 8.0.2 erforderlich.

Weitere Informationen zur Befehlsreferenz, zu unterstützten Abfrageformen, funktionierenden Beispielen und zur Interaktion von Filtern mit Hinweisen finden Sie unter. Cache-Filter planen

Mögliche Verhaltensunterschiede zwischen Planner-Version 1.0, 3.0 und MongoDB

In einigen Randfällen ist es möglich, dass Planner-Version 3.0 Ergebnisse liefert, die leicht von der Planer-Version 1.0 abweichen. In diesem Abschnitt werden einige Beispiele für diese Möglichkeiten vorgestellt.

Feature Differences

• Bei einer leeren Sammlung oder wenn frühere Stufen wie Match alle Dokumente filtern, gibt Planner v1 die Ausgabe „field“ :0 aus. Planner v3 und MongoDB geben keine Ausgaben aus.

• Bei Plannerv1 überspringt {"$skip“ :n} nicht, wenn in der vorherigen Phase weniger als n Dokumente zurückgegeben wurden. Plannerv3 und MongoDB überspringen korrekt, unabhängig von der Anzahl der zurückgegebenen Dokumente.

• Wenn eine ausländische Sammlung, auf die in $lookup verwiesen wird, nicht existiert, gibt plannerv1 einen Fehler aus. Planner v3 und MongoDB behandeln die ausländische Sammlung als leere Sammlung und führen $lookup durch.

  db.coll.aggregate([
      {$lookup: {from: "does_not_exist", localField: "a", foreignField: "a", as: "c"}}
  ])
  

• Nur Planner v1 erlaubt die Verwendung mehrerer $search in einer Pipeline. Planner v2/v3 gibt einen Fehler aus und MongoDB unterstützt ihn nicht.

  VectorSearch = { "$search": { "vectorSearch": {
     "vector": [0.2, 0.5, 0.8], 
     "path": "vectorEmbedding", 
     "similarity": "cosine", 
     "k": 2, 
     "efSearch": 1  
     }}}
  db.coll.aggregate([VectorSearch, VectorSearch])
  

• Nur Planner v3 funktioniert, wenn die VectorSearch-Stufe nicht die erste Stufe ist. In diesem Fall gibt MongoDB einen Fehler aus und Planner v1 unterstützt die $VectorSearch-Stufe nicht.

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