Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Funktionale Unterschiede: Amazon DocumentDB und MongoDB Im Folgenden sind die funktionalen Unterschiede zwischen Amazon DocumentDB (mit MongoDB-Kompatibilität) und MongoDB aufgeführt. **Topics** + [Funktionale Vorteile von Amazon DocumentDB](#functional-differences.functional-benefits) + [Funktionelle Unterschiede wurden aktualisiert](#functional-differences.updated-functional-differences) + [Funktionale Unterschiede zu MongoDB](#functional-differences.with-mongodb) ## Funktionale Vorteile von Amazon DocumentDB ### Implizite Transaktionen In Amazon DocumentDB garantieren alle CRUD-Anweisungen (`findAndModify`,, `update``insert`,`delete`) Atomarität und Konsistenz, selbst für Operationen, die mehrere Dokumente ändern. Mit der Einführung von Amazon DocumentDB 4.0 werden jetzt explizite Transaktionen unterstützt, die ACID-Eigenschaften für Operationen mit mehreren Anweisungen und mehreren Sammlungen bereitstellen. Weitere Informationen zur Verwendung von Transaktionen in Amazon DocumentDB finden Sie unter[Transaktionen in Amazon DocumentDB](transactions.md). 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 `insertMany``updateMany`, und `deleteMany` -Operationen 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. **Topics** + [Array-Indizierung](#functional-differences.array-indexing) + [Indizes mit mehreren Schlüsseln](#functional-differences.multi-key-indexes) + [Nullzeichen in Zeichenketten](#functional-differences.strings) + [Rollenbasierte Zugriffskontrolle](#functional-differences.role_based_access_control) + [`$regex`Indizierung](#functional-differences.regex-indexing) + [Projektion für verschachtelte Dokumente](#functional-differences.nested-docs) ### 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. 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" } ] ``` ### 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](role_based_access_control.md). ### `$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` oder`c`. In Amazon DocumentDB 4.0 `{a:{b:{c:1}}}` wird die Projektion auf `a``b`, und `c` angewendet. ## Funktionale Unterschiede zu MongoDB **Topics** + [`$vectorSearch`-Operator](#functional-differences.vector-search) + [`OpCountersCommand`](#functional-differences.op-counter) + [Admin-Datenbanken und Sammlungen](#functional-differences.admin-databases) + [`cursormaxTimeMS`](#functional-differences.cursormaxTimeMS) + [explain()](#functional-differences.explain) + [Der Index wird erstellt](#functional-differences.background-indexes) + [Suche mit leerem Schlüssel im Pfad](#functional-differences.lookup-empty) + [MongoDB APIs, Operationen und Datentypen](#functional-differences.mongo-apis) + [`mongodump`und `mongorestore` Dienstprogramme](#functional-differences.mongodump-mongorestore) + [Reihenfolge der Ergebnisse](#functional-differences.result-ordering) + [Wiederholbare Schreibvorgänge](#functional-differences.retryable-writes) + [Sparse Index](#functional-differences.sparse-index) + [`$elemMatch`Verwendung innerhalb eines Ausdrucks `$all`](#functional-differences.elemMatch) + [Dollar (\$1) und Punkt (.) in Feldnamen](#functional-differences-dollardot) + [`$lookup`](#functional-differences.lookup) + [`$natural`und umgekehrte Sortierung](#functional-differences.natural) ### `$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](vector-search.md). ### `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.maxTimeMS`Setzt 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 3.6, 4.0, 5.0 und 8.0 APIs 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. ### Der Index wird 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 Index-Builds in Amazon DocumentDB und MongoDB Version 4.0 im Vordergrund ausgeführt. MongoDB Version 4.2 und höher ignoriert die Option zum Erstellen des Hintergrundindexes, wenn sie für createIndexes oder seine Shell-Helfer und angegeben wurde. `createIndex()` `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 wird`0`, sodass die Suche nach Zeichenkettenschlüsseln wie die Suche nach einem Array-Index behandelt wird. ### MongoDB APIs, Operationen und Datentypen Amazon DocumentDB ist mit MongoDB 3.6, 4.0, 5.0 und 8.0 kompatibel. APIs Eine up-to-date Liste der unterstützten Funktionen finden Sie unter. [Unterstützte MongoDB APIs, Operationen und Datentypen in Amazon DocumentDB](mongo-apis.md) ### `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 erstellen`mongorestore`, 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](https://www.mongodb.com/download-center/database-tools/releases/archive) 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 Ab 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 (z. B.`MongoClient("mongodb://my.mongodb.cluster/db?retryWrites=false")`) oder das Schlüsselwortargument des MongoClient Konstruktors (z. B.) deaktiviert werden. `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://:@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" } } } ] }) ``` ### Dollar (\$1) und Punkt (.) in Feldnamen Amazon DocumentDB unterstützt nicht die Abfrage von Feldern mit dem Präfix Dollar (\$1) in \$1in, \$1nin und \$1all in verschachtelten Objekten. Die folgende Abfrage ist beispielsweise in Amazon DocumentDB nicht gültig: ``` coll.find({"field": {"$all": [{ "$a": 1 }]}}) ``` ### `$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 an`SORT_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 an`HASH_LOOKUP`. Sie können den Indizierungsalgorithmus, der für den `$lookup` Operator verwendet wird, `explain` anhand der Abfrage identifizieren. 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](profiling.md) #### 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 : "", lookupStage : { planHint : "SORT" | "HASH" | "NESTED_LOOP" } } ``` Im Folgenden finden Sie ein Beispiel für die Verwendung von`planHint`, 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\" }}" ``` ### `$natural`und umgekehrte Sortierung Amazon DocumentDB unterstützt nur `$natural` Forward-Collection-Scans. Rückwärtige Sammelscans (`{$natural: -1}`) führen zu einem`MongoServerError`.