Funktionale Vorteile von Amazon DocumentDB Funktionelle Unterschiede wurden aktualisiert Funktionale Unterschiede zu MongoDB

Funktionale Unterschiede: Amazon DocumentDB und MongoDB

Im Folgenden sind die funktionalen Unterschiede zwischen Amazon DocumentDB (mit MongoDB-Kompatibilität) und MongoDB aufgeführt.

Themen

Funktionale Vorteile von Amazon DocumentDB
Funktionelle Unterschiede wurden aktualisiert
Funktionale Unterschiede zu MongoDB

Funktionale Vorteile von Amazon DocumentDB

Implizite Transaktionen

In Amazon DocumentDB garantieren alle CRUD Anweisungen (findAndModify,update,insert,delete) Atomarität und Konsistenz, selbst bei Vorgängen, die mehrere Dokumente ändern. Mit der Einführung von Amazon DocumentDB 4.0 werden jetzt explizite Transaktionen unterstützt, die ACID Eigenschaften für Vorgänge mit mehreren Anweisungen und mehreren Sammlungen bereitstellen. Weitere Informationen zur Verwendung von Transaktionen in Amazon DocumentDB finden Sie unterTransaktionen in Amazon DocumentDB.

Im Folgenden finden Sie Beispiele für Operationen in Amazon DocumentDB, bei denen mehrere Dokumente geändert werden, die sowohl atomares als auch konsistentes Verhalten erfüllen.


db.miles.update(
    { "credit_card": { $eq: true } },
    { $mul: { "flight_miles.$[]": NumberInt(2) } },
    { multi: true }
)


db.miles.updateMany(
    { "credit_card": { $eq: true } }, 
    { $mul: { "flight_miles.$[]": NumberInt(2) } }
)


db.runCommand({
  update: "miles",
  updates: [
    {
      q: { "credit_card": { $eq: true } },
      u: { $mul: { "flight_miles.$[]": NumberInt(2) } },
      multi: true
    }
  ]
})


db.products.deleteMany({
  "cost": { $gt: 30.00 }
})


db.runCommand({
  delete: "products",
  deletes: [{ q: { "cost": { $gt: 30.00 } }, limit: 0 }]
})

Die einzelnen Operationen, aus denen die Massenoperationen bestehen, wie updateMany und deleteMany, sind atomar, aber die Gesamtheit der Massenoperation ist nicht atomar. Zum Beispiel ist die Gesamtheit der insertMany-Operation atomar, wenn die einzelnen Einfügeoperationen erfolgreich ohne Fehler ausgeführt werden. Wenn bei einer insertMany Operation ein Fehler auftritt, wird jede einzelne Insert-Anweisung innerhalb der insertMany Operation als atomare Operation ausgeführt. Wenn Sie ACID Eigenschaften für deleteMany Operationen insertManyupdateMany, und benötigen, wird empfohlen, eine Transaktion zu verwenden.

Funktionelle Unterschiede wurden aktualisiert

Amazon DocumentDB verbessert weiterhin die Kompatibilität mit MongoDB, indem es von den Funktionen, die unsere Kunden uns in Auftrag gegeben haben, abweicht. Dieser Abschnitt enthält die funktionalen Unterschiede, die wir in Amazon DocumentDB entfernt haben, um unseren Kunden Migrationen und die Erstellung von Anwendungen zu erleichtern.

Array-Indizierung

Seit dem 23. April 2020 unterstützt Amazon DocumentDB jetzt die Möglichkeit, Arrays zu indizieren, die größer als 2.048 Byte sind. Das Limit für ein einzelnes Element in einem Array bleibt weiterhin bei 2.048 Byte, was mit MongoDB konsistent ist.

Beim Erstellen eines neuen Index sind keine Maßnahmen erforderlich, um die Vorteile der verbesserten Funktionalität zu nutzen. Wenn Sie über einen vorhandenen Index verfügen, können Sie die verbesserte Funktionalität nutzen, indem Sie den Index löschen und anschließend neu erstellen. Die aktuelle Index-Version mit den verbesserten Fähigkeiten lautet "v" : 3.

Anmerkung

Bei Produktions-Clustern kann das Entfernen des Index Auswirkungen auf Ihre Anwendungsleistung haben. Wir empfehlen Ihnen, bei Änderungen an einem Produktionssystem zunächst Tests durchzuführen und dann mit Bedacht weiter vorzugehen. Darüber hinaus hängt die Zeit, die für die Neuerstellung des Index benötigt wird, von der Gesamtdatengröße der Sammlung ab.

Mit folgendem Befehl können Sie die Version Ihrer Indizes abfragen.


db.collection.getIndexes()

Die Ausgabe dieser Operation sieht in etwa folgendermaßen aus. In dieser Ausgabe ist die Indexversion "v" : 3, die die aktuellste Indexversion ist.


[
    {
        "v" : 3,
        "key" : {
        "_id" : 1
        },
        "name" : "_id_",
        "ns" : "test.test"
    }
]

Indizes mit mehreren Schlüsseln

Seit dem 23. April 2020 unterstützt Amazon DocumentDB jetzt die Möglichkeit, einen zusammengesetzten Index mit mehreren Schlüsseln im selben Array zu erstellen.

Anmerkung

Mit folgendem Befehl können Sie die Version Ihrer Indizes abfragen.


db.collection.getIndexes()

Die Ausgabe dieser Operation sieht in etwa folgendermaßen aus. In dieser Ausgabe ist die Indexversion "v" : 3, die die aktuellste Indexversion ist.


[
    {
        "v" : 3,
        "key" : {
            "_id" : 1
        },
        "name" : "_id_",
        "ns" : "test.test"
    }
]

Nullzeichen in Zeichenketten

Seit dem 22. Juni 2020 unterstützt Amazon DocumentDB jetzt Nullzeichen ('\0') in Zeichenketten.

Rollenbasierte Zugriffskontrolle

Seit dem 26. März 2020 unterstützt Amazon DocumentDB die rollenbasierte Zugriffskontrolle (RBAC) für integrierte Rollen. Weitere Informationen hierzu finden Sie unter Rollenbasierte Zugriffssteuerung.

`$regex`Indizierung

Seit dem 22. Juni 2020 unterstützt Amazon DocumentDB nun die Möglichkeit für $regex Betreiber, einen Index zu verwenden.

Um einen Index mit dem $regex-Operator zu nutzen, müssen Sie den hint()-Befehl verwenden. Bei der Verwendung von hint() müssen Sie den Namen des Feldes angeben, auf dem Sie $regex anwenden möchten. Wenn Sie beispielsweise einen Index für Feld product mit dem Indexnamen p_1 haben, nutzt db.foo.find({product: /^x.*/}).hint({product:1}) den p_1-Index, aber db.foo.find({product: /^x.*/}).hint(“p_1”) nutzt den Index nicht. Sie können mit dem explain()-Befehl überprüfen, ob ein Index ausgewählt wird, oder indem Sie den Profiler zum Protokollieren langsamer Abfragen verwenden. Beispiel, db.foo.find({product: /^x.*/}).hint(“p_1”).explain().

Anmerkung

Die hint()-Methode kann nur mit jeweils einem Index verwendet werden.

Die Verwendung eines Index für eine $regex-Abfrage ist für regex-Abfragen optimiert, die ein Präfix verwenden und bei denen die regex-Optionen I, m oder o nicht angegeben werden.

Wenn Sie einen Index mit $regex verwenden, wird empfohlen, einen Index für hoch selektive Felder zu erstellen, bei denen die Anzahl der doppelten Werte weniger als 1 % der Gesamtzahl der Dokumente in der Sammlung beträgt. Wenn Ihre Sammlung beispielsweise 100.000 Dokumente enthält, erstellen Sie Indizes nur für Felder, in denen derselbe Wert 1.000 Mal oder weniger vorkommt.

Projektion für verschachtelte Dokumente

Es gibt einen funktionellen Unterschied zwischen Amazon DocumentDB und MongoDB in Version 3.6, der in Amazon DocumentDB 4.0 behoben wurde, aber in Amazon DocumentDB 3.6 weiterhin nicht unterstützt wird. $project

Amazon DocumentDB 3.6 berücksichtigt bei der Anwendung einer Projektion nur das erste Feld in einem verschachtelten Dokument, wohingegen MongoDB 3.6 Unterdokumente analysiert und die Projektion auch auf jedes Unterdokument anwendet.

Beispiel: Wenn die Projektion ist“a.b.c”: 1, dann funktioniert das Verhalten sowohl in Amazon DocumentDB als auch in MongoDB erwartungsgemäß. Wenn die Projektion jedoch {a:{b:{c:1}}} dann ist, wendet Amazon DocumentDB 3.6 die Projektion nur auf an a und nicht auf b oderc. In Amazon DocumentDB 4.0 {a:{b:{c:1}}} wird die Projektion auf ab, und c angewendet.

Funktionale Unterschiede zu MongoDB

Themen

$vectorSearch-Operator
OpCountersCommand
Admin-Datenbanken und Sammlungen
cursormaxTimeMS
explain()
Einschränkungen bei Feldnamen
Indexe werden erstellt
Suche mit leerem Schlüssel im Pfad
MongoDBAPIs, Operationen und Datentypen
mongodumpund mongorestore Dienstprogramme
Reihenfolge der Ergebnisse
Wiederholbare Schreibvorgänge
Sparse-Index
$elemMatchVerwendung innerhalb eines Ausdrucks $all
$ne,,$nin, $nor$not$exists, und $elemMatch Indizierung
$lookup

`$vectorSearch`-Operator

Amazon DocumentDB unterstützt nicht $vectorSearch als unabhängiger Betreiber. Stattdessen unterstützen wir vectorSearch innerhalb des $search Betreibers. Weitere Informationen finden Sie unter Vektorsuche für Amazon DocumentDB.

`OpCountersCommand`

Das OpCountersCommand Verhalten von Amazon DocumentDB unterscheidet sich wie folgt von MongoDB: opcounters.command

MongoDB opcounters.command zählt alle Befehle außer Einfügen, Aktualisieren und Löschen, während Amazon DocumentDB den Befehl OpCountersCommand ebenfalls ausschließt. find
Amazon DocumentDB zählt einige interne Befehle zu. OpCountersCommand

Admin-Datenbanken und Sammlungen

Amazon DocumentDB unterstützt weder die Admin- oder lokale Datenbank noch MongoDB system.* bzw. startup_log Sammlungen.

`cursormaxTimeMS`

cursor.maxTimeMSSetzt in Amazon DocumentDB den Zähler für jede getMore Anfrage zurück. Wenn also ein Wert von 3000 MS angegeben maxTimeMS ist, die Abfrage 2800 MS und jede nachfolgende getMore Anforderung 300 MS benötigt, wird der Cursor kein Timeout haben. Für den Cursor wird nur ein Timeout ausgeführt, wenn eine einzelne Operation, entweder die Abfrage oder eine einzelne getMore Anfrage, länger dauert als angegeben. maxTimeMS Außerdem läuft der Sweeper, der die Cursor-Ausführungszeit überprüft, mit einer Granularität von fünf (5) Minuten.

explain()

Amazon DocumentDB emuliert MongoDB 4.0 API auf einer speziell entwickelten Datenbank-Engine, die ein verteiltes, fehlertolerantes, selbstheilendes Speichersystem verwendet. Daher explain() können sich die Abfragepläne und die Ausgabe von zwischen Amazon DocumentDB und MongoDB unterscheiden. Kunden, die die Kontrolle über ihren Abfrageplan wünschen, können den $hint-Operator verwenden, um die Auswahl eines bevorzugten Indexes zu erzwingen.

Einschränkungen bei Feldnamen

Amazon DocumentDB unterstützt keine Punkte „.“ in einem Dokumentfeldnamen, zum Beispieldb.foo.insert({‘x.1’:1}).

Amazon DocumentDB unterstützt auch nicht das $-Präfix in Feldnamen.

Versuchen Sie beispielsweise den folgenden Befehl in Amazon DocumentDB oder MongoDB:


rs0:PRIMARY< db.foo.insert({"a":{"$a":1}})

MongoDB gibt Folgendes zurück:


WriteResult({ "nInserted" : 1 })

Amazon DocumentDB gibt einen Fehler zurück:


WriteResult({
"nInserted" : 0,
"writeError" : {
"code" : 2,
"errmsg" : "Document can't have $ prefix field names: $a"
}
})

Anmerkung

Für diesen funktionalen Unterschied gibt es eine Ausnahme. Die folgenden Feldnamen, die mit dem Präfix $ beginnen, wurden auf die Whitelist gesetzt und können erfolgreich in Amazon DocumentDB verwendet werden: $id, $ref und $db.

Indexe werden erstellt

Amazon DocumentDB lässt zu, dass jeweils nur ein Index für eine Sammlung erstellt wird. Entweder im Vordergrund oder im Hintergrund. Wenn Vorgänge wie createIndex() oder dropIndex() für dieselbe Sammlung auftreten, wenn gerade ein Index erstellt wird,, schlägt der neu versuchte Vorgang fehl.

Standardmäßig werden Indexerstellungen in Amazon DocumentDB und MongoDB Version 4.0 im Hintergrund ausgeführt. MongoDB Version 4.2 und höher ignoriert die Option zum Erstellen des Hintergrundindexes, wenn sie für createIndexes oder ihre Shell-Helfer createIndex() und angegeben wurde. createIndexes()

Bei einem Time to Live (TTL) -Index laufen Dokumente ab, nachdem die Indexerstellung abgeschlossen ist.

Suche mit leerem Schlüssel im Pfad

Wenn Sie mit einem Schlüssel suchen, der eine leere Zeichenfolge als Teil des Pfads enthält (z. B.x..b)x., und das Objekt einen leeren Zeichenkettenschlüsselpfad (z. B.{"x" : [ { "" : 10 }, { "b" : 20 } ]}) innerhalb eines Arrays hat, gibt Amazon DocumentDB andere Ergebnisse zurück, als wenn Sie dieselbe Suche in MongoDB ausführen würden.

In MongoDB funktioniert die Suche nach einem leeren Schlüsselpfad innerhalb eines Arrays wie erwartet, wenn sich der leere Zeichenkettenschlüssel nicht am Ende der Pfadsuche befindet. Wenn sich der leere Zeichenkettenschlüssel jedoch am Ende der Pfadsuche befindet, schaut er nicht in das Array hinein.

In Amazon DocumentDB wird jedoch nur das erste Element innerhalb des Arrays gelesen, da eine leere Zeichenfolge in eine leere Zeichenfolge getArrayIndexFromKeyString konvertiert wird0, sodass die Suche nach Zeichenkettenschlüsseln wie die Suche nach einem Array-Index behandelt wird.

MongoDBAPIs, Operationen und Datentypen

Amazon DocumentDB ist mit MongoDB 3.6 und 4.0 kompatibel. APIs Eine up-to-date Liste der unterstützten Funktionen finden Sie unter. Unterstützte MongoDBAPIs, Operationen und Datentypen in Amazon DocumentDB

`mongodump`und `mongorestore` Dienstprogramme

Amazon DocumentDB unterstützt keine Admin-Datenbank und speichert die Admin-Datenbank daher nicht und stellt sie auch nicht wieder her, wenn Sie die Dienstprogramme mongodump oder mongorestore verwenden. Wenn Sie mit Amazon DocumentDB eine neue Datenbank erstellenmongorestore, müssen Sie zusätzlich zum Wiederherstellungsvorgang auch die Benutzerrollen neu erstellen.

Anmerkung

Wir empfehlen MongoDB Database Tools bis einschließlich Version 100.6.1 für Amazon DocumentDB. Sie können hier auf die Downloads der MongoDB Database Tools zugreifen.

Reihenfolge der Ergebnisse

Amazon DocumentDB garantiert nicht die implizite Sortierreihenfolge von Ergebnismengen. Um die Reihenfolge einer Ergebnismenge zu gewährleisten, geben Sie mit sort() explizit eine Sortierreihenfolge an.

Das folgende Beispiel sortiert die Artikel in der Inventur in absteigender Reihenfolge basierend auf dem Bestandsfeld.


db.inventory.find().sort({ stock: -1 })

Bei Verwendung der $sort Aggregationsphase wird die Sortierreihenfolge nicht beibehalten, es sei denn, die $sort Phase ist die letzte Phase in der Aggregationspipeline. Wenn die $sort Aggregationsphase in Kombination mit der Aggregationsphase verwendet wird, wird die $group Aggregationsphase nur auf die $sort Akkumulatoren und angewendet. $first $last In Amazon DocumentDB 4.0 wurde Unterstützung für $push die Beibehaltung der Sortierreihenfolge aus der vorherigen $sort Phase hinzugefügt.

Wiederholbare Schreibvorgänge

Beginnend mit MongoDB 4.2-kompatiblen Treibern sind wiederholbare Schreibvorgänge standardmäßig aktiviert. Amazon DocumentDB unterstützt derzeit jedoch keine wiederholbaren Schreibvorgänge. Der funktionale Unterschied wird sich in einer Fehlermeldung ähnlich der folgenden zeigen.


{"ok":0,"errmsg":"Unrecognized field: 'txnNumber'","code":9,"name":"MongoError"}

Wiederholbare Schreibvorgänge können über die Verbindungszeichenfolge (zum Beispiel) MongoClient("mongodb://my.mongodb.cluster/db?retryWrites=false")) oder das Schlüsselwortargument des MongoClient Konstruktors (z. B. MongoClient("mongodb://my.mongodb.cluster/db", retryWrites=False))

Im Folgenden finden Sie ein Python-Beispiel, das wiederholbare Schreibvorgänge in der Verbindungszeichenfolge deaktiviert.


client = pymongo.MongoClient('mongodb://<username>:<password>@docdb-2019-03-17-16-49-12.cluster-ccuszbx3pn5e.us-east-1.docdb.amazonaws.com:27017/?replicaSet=rs0',w='majority',j=True,retryWrites=False)

Sparse-Index

Um einen Sparse-Index zu verwenden, den Sie in einer Abfrage erstellt haben, müssen Sie die $exists-Bedingungen für die Felder verwenden, die der Index abdecken. Wenn Sie ihn weglassen$exists, verwendet Amazon DocumentDB den Sparse-Index nicht.

Im Folgenden wird ein Beispiel gezeigt.


db.inventory.count({ "stock": { $exists: true }})

Für spärliche Indizes mit mehreren Schlüsseln unterstützt Amazon DocumentDB keine eindeutige Schlüsseleinschränkung, wenn die Suche nach einem Dokument zu einer Reihe von Werten führt und nur eine Teilmenge der indizierten Felder fehlt. Beispielsweise wird createIndex({"a.b" : 1 }, { unique : true, sparse :true }) nicht unterstützt, wenn "a" : [ { "b" : 2 }, { "c" : 1 } ] eingegeben wird, da "a.c" im Index gespeichert ist.

`$elemMatch`Verwendung innerhalb eines Ausdrucks `$all`

Amazon DocumentDB unterstützt derzeit nicht die Verwendung des $elemMatch Operators innerhalb eines $all Ausdrucks. Sie können dies umgehen, indem Sie den Operator $and wie folgt mit $elemMatch verwenden.

Ursprüngliche Operation:


db.col.find({
  qty: {
    $all: [
      { "$elemMatch": { part: "xyz", qty: { $lt: 11 } } },
      { "$elemMatch": { num: 40, size: "XL" } }
    ]
  }
})

Aktualisierte Operation:


db.col.find({
  $and: [
    { qty: { "$elemMatch": { part: "xyz", qty: { $lt: 11 } } } },
    { qty: { "$elemMatch": { qty: 40, size: "XL" } } }
  ]
})

`$ne`,,`$nin`, `$nor$not$exists`, und `$elemMatch` Indizierung

Amazon DocumentDB unterstützt derzeit nicht die Möglichkeit, Indizes mit den Operatoren$ne,,$nin, $nor $not$exists, und $distinct zu verwenden. Aus diesem Grund führt die Verwendung dieser Operatoren zu Sammelscans. Wenn Sie vor der Verwendung eines dieser Operatoren einen Filter oder einen Abgleich durchführen, wird die Datenmenge reduziert, die gescannt werden muss, und kann somit die Leistung verbessern.

Amazon DocumentDB hat Unterstützung für Indexscans mit dem $elemMatch Operator in Amazon DocumentDB 5.0 und elastischen Clustern hinzugefügt. Indexscans werden unterstützt, wenn der reine Abfragefilter eine $elemMatch Filterebene hat, aber nicht unterstützt, wenn eine verschachtelte $elemMatch Abfrage enthalten ist.

$elemMatchAbfrageform, die Indexscans in Amazon DocumentDB 5.0 unterstützt:


db.foo.find( { "a": {$elemMatch: { "b": "xyz", "c": "abc"} } })

$elemMatchAbfrageform, die in Amazon DocumentDB 5.0 keine Indexscans unterstützt:


db.foo.find( { "a": {$elemMatch: { "b": {$elemMatch: { "d": "xyz", "e": "abc"} }} } })

`$lookup`

Amazon DocumentDB unterstützt Gleichheitsabgleiche (z. B. Left Outer Join) und unterstützt auch unkorrelierte Unterabfragen, aber keine korrelierten Unterabfragen.

Verwenden eines Indexes mit `$lookup`

Sie können jetzt einen Index mit dem $lookup Stage-Operator verwenden. Je nach Anwendungsfall gibt es mehrere Indexierungsalgorithmen, mit denen Sie die Leistung optimieren können. In diesem Abschnitt werden die verschiedenen Indexierungsalgorithmen für Sie erläutert $lookup und Sie bei der Auswahl des für Ihren Workload am besten geeigneten Algorithmus unterstützt.

Standardmäßig verwendet Amazon DocumentDB den Hash-Algorithmus, wenn allowDiskUse:false es verwendet wird, und Sort Merge, wenn allowDiskUse:true es verwendet wird.

Anmerkung

Die allowDiskUse Option wird derzeit für den find Befehl nicht unterstützt. Die Option wird nur als Teil der Aggregation unterstützt. Wir empfehlen, das Aggregationsframework mit allowDiskUse:true zu verwenden, um große Abfragen zu verarbeiten, die Speicherlimits überschreiten könnten.

In einigen Anwendungsfällen kann es wünschenswert sein, den Abfrageoptimierer zu zwingen, einen anderen Algorithmus zu verwenden. Im Folgenden sind die verschiedenen Indizierungsalgorithmen aufgeführt, die der $lookup Aggregationsoperator verwenden kann:

Verschachtelte Schleife: Ein Plan mit verschachtelter Schleife ist in der Regel für eine Arbeitslast von Vorteil, wenn die ausländische Sammlung weniger als 1 GB groß ist und das Feld in der ausländischen Sammlung über einen Index verfügt. Wenn der Nested-Loop-Algorithmus verwendet wird, zeigt der Explain-Plan die Phase als an. NESTED_LOOP_LOOKUP
Zusammenführung sortieren: Ein Plan zum Zusammenführen von Sortierungen ist in der Regel für eine Arbeitslast von Vorteil, wenn die ausländische Sammlung keinen Index für das bei der Suche verwendete Feld hat und der Arbeitsdatensatz nicht in den Arbeitsspeicher passt. Wenn der Algorithmus zur Sortierung und Zusammenführung verwendet wird, zeigt der Erläuterungsplan die Phase als anSORT_LOOKUP.
Hash: Ein Hash-Plan ist in der Regel für eine Arbeitslast von Vorteil, wenn die ausländische Sammlung weniger als 1 GB groß ist und der Arbeitsdatensatz in den Arbeitsspeicher passt. Wenn der Hash-Algorithmus verwendet wird, zeigt der Explain-Plan die Phase als HASH_LOOKUP an.

Sie können den Indizierungsalgorithmus identifizieren, der für den $lookup Operator verwendet wird, indem Sie in der Abfrage den Befehl explain verwenden. Im Folgenden finden Sie ein Beispiel:


db.localCollection.explain().
aggregate( [ 

   { 
          $lookup: 
                   { 
                              from: "foreignCollection", 
                              localField: "a", 
       foreignField: "b", 
       as: "joined" 
} 
   } 
]

output
{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "test.localCollection",
        "winningPlan" : {
            "stage" : "SUBSCAN",
            "inputStage" : {
                "stage" : "SORT_AGGREGATE",
                "inputStage" : {
                    "stage" : "SORT",
                    "inputStage" : {
                        "stage" : "NESTED_LOOP_LOOKUP",
                        "inputStages" : [
                            {
                                "stage" : "COLLSCAN"
                            },
                            {
                                "stage" : "FETCH",
                                "inputStage" : {
                                    "stage" : "COLLSCAN"
                                }
                            }
                        ]
                    }
                }
            }
        }
    },
    "serverInfo" : {
        "host" : "devbox-test",
        "port" : 27317,
        "version" : "3.6.0"
    },
    "ok" : 1
}

Als Alternative zur Verwendung der explain() Methode können Sie den Profiler verwenden, um den Algorithmus zu überprüfen, der bei Ihrer Verwendung des $lookup Operators verwendet wird. Weitere Informationen zum Profiler finden Sie unter. Profilierung von Amazon DocumentDB DocumentDB-Vorgängen

Verwenden eines `planHint`

Wenn Sie den Abfrageoptimierer zwingen möchten, einen anderen Indexierungsalgorithmus mit zu verwenden$lookup, können Sie einen verwenden. planHint Verwenden Sie dazu den Kommentar in den Optionen der Aggregationsphase, um einen anderen Plan zu erzwingen. Im Folgenden finden Sie ein Beispiel für die Syntax des Kommentars:


comment : {
    comment :  “<string>”,
    lookupStage : { planHint : “SORT” | “HASH” | "NESTED_LOOP" }
}

Im Folgenden finden Sie ein Beispiel für die Verwendung vonplanHint, um den Abfrageoptimierer zur Verwendung des HASH Indexierungsalgorithmus zu zwingen:


db.foo.aggregate(
  [                           
    {   
        $lookup:
        {   
            from: "foo",
            localField: "_id",
            foreignField: "_id",
            as: "joined"
        },
    }
  ],
  {
    comment : "{ \\"lookupStage\\" : { \\"planHint\\": \\"HASH\\" }}"

Um zu testen, welcher Algorithmus für Ihre Arbeitslast am besten geeignet ist, können Sie den executionStats Parameter der explain Methode verwenden, um die Ausführungszeit der $lookup Phase zu messen und gleichzeitig den Indizierungsalgorithmus zu ändern (d. h.HASH//SORT). NESTED_LOOP

Das folgende Beispiel zeigt, wie Sie executionStats die Ausführungszeit der $lookup Phase mithilfe des SORT Algorithmus messen können.


db.foo.explain(“executionStats”).aggregate(
  [    
    {   
        $lookup:
        {   
            from: "foo",
            localField: "_id",
            foreignField: "_id",
            as: "joined"
        },
    }
  ],
  {
    comment : "{ \\"lookupStage\\" : { \\"planHint\": \\"SORT\\" }}"

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Bewährte Methoden

Unterstützte MongoDBAPIs, Operationen und Datentypen

Funktionale Unterschiede: Amazon DocumentDB und MongoDB

Themen

Funktionale Vorteile von Amazon DocumentDB

Implizite Transaktionen

Funktionelle Unterschiede wurden aktualisiert

Themen

Array-Indizierung

Anmerkung

Indizes mit mehreren Schlüsseln

Anmerkung

Nullzeichen in Zeichenketten

Rollenbasierte Zugriffskontrolle

$regexIndizierung

Anmerkung

Projektion für verschachtelte Dokumente

Funktionale Unterschiede zu MongoDB

Themen

$vectorSearch-Operator

OpCountersCommand

Admin-Datenbanken und Sammlungen

cursormaxTimeMS

explain()

Einschränkungen bei Feldnamen

Anmerkung

Indexe werden erstellt

Suche mit leerem Schlüssel im Pfad

MongoDBAPIs, Operationen und Datentypen

mongodumpund mongorestore Dienstprogramme

Anmerkung

Reihenfolge der Ergebnisse

Wiederholbare Schreibvorgänge

Sparse-Index

$elemMatchVerwendung innerhalb eines Ausdrucks $all

$ne,,$nin, $nor$not$exists, und $elemMatch Indizierung

$lookup

Verwenden eines Indexes mit $lookup

Anmerkung

Verwenden eines planHint

`$regex`Indizierung

`$vectorSearch`-Operator

`OpCountersCommand`

`cursormaxTimeMS`

`mongodump`und `mongorestore` Dienstprogramme

`$elemMatch`Verwendung innerhalb eines Ausdrucks `$all`

`$ne`,,`$nin`, `$nor$not$exists`, und `$elemMatch` Indizierung

`$lookup`

Verwenden eines Indexes mit `$lookup`

Verwenden eines `planHint`