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.

Funktionale Vorteile von Amazon DocumentDB

Implizite Transaktionen

In Amazon DocumentDB garantieren alle CRUD-Anweisungen (findAndModify,, updateinsert,delete) Atomarität und Konsistenz, selbst bei Vorgängen, bei denen mehrere Dokumente geändert werden. Mit der Einführung von Amazon DocumentDB 4.0 werden nun 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

Im Folgenden finden Sie Beispiele für Operationen in Amazon DocumentDB, die mehrere Dokumente so modifizieren, dass sie sowohl atomaren als auch konsistenten Verhaltensweisen entsprechen.

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. Tritt bei einer insertMany Operation ein Fehler auf, 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.

Die funktionalen Unterschiede wurden aktualisiert

Amazon DocumentDB verbessert weiterhin die Kompatibilität mit MongoDB, indem es ausgehend von den Funktionen, um deren Entwicklung uns unsere Kunden gebeten haben, rückwärts arbeitet. Dieser Abschnitt enthält die funktionalen Unterschiede, die wir in Amazon DocumentDB entfernt haben, um unseren Kunden Migrationen und das Erstellen 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 liegt 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.

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

Multi-key Indizes

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.

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.

Role-based 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 Role-Based Zugriffskontrolle.

$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().

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

In Version 3.6 gibt es einen funktionalen Unterschied mit dem $project Operator zwischen Amazon DocumentDB und MongoDB, der in Amazon DocumentDB 4.0 behoben wurde, aber in Amazon DocumentDB 3.6 weiterhin nicht unterstützt wird.

Amazon DocumentDB 3.6 berücksichtigt beim Anwenden 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 zutrifft“a.b.c”: 1, funktioniert das Verhalten sowohl in Amazon DocumentDB als auch in MongoDB erwartungsgemäß. Wenn die Projektion jedoch {a:{b:{c:1}}} so ist, wendet Amazon DocumentDB 3.6 die Projektion nur auf a und nicht auf oder an. b c In Amazon DocumentDB 4.0 {a:{b:{c:1}}} wird die Projektion auf ab, und angewendet. c

Funktionale Unterschiede zu MongoDB

$VectorSearch-Operator

Amazon DocumentDB wird $vectorSearch als unabhängiger Betreiber nicht unterstützt. 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 weicht wie folgt von dem von MongoDB ab: opcounters.command

Admin-Datenbanken und Sammlungen

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

Cursor MaxTimeMS

cursor.maxTimeMSSetzt in Amazon DocumentDB den Zähler für jede Anfrage zurück. getMore Wenn also 3000 MS angegeben sind, maxTimeMS dauert die Abfrage 2800 MS, und jede nachfolgende getMore Anforderung dauert 300 MS, sodass für den Cursor kein Timeout auftritt. Für den Cursor kommt es nur dann zu einer Zeitüberschreitung, wenn eine einzelne Operation, entweder die Abfrage oder eine einzelne getMore Anforderung, mehr als die angegebene Zeit in Anspruch nimmt. maxTimeMS Außerdem wird der Sweeper, der die Ausführungszeit des Cursors überprüft, mit einer Granularität von fünf (5) Minuten ausgeführt.

explain()

Amazon DocumentDB emuliert die MongoDB-APIs 3.6, 4.0, 5.0 und 8.0 auf einer speziell entwickelten Datenbank-Engine, die ein verteiltes, fehlertolerantes, selbstheilendes Speichersystem verwendet. Daher können sich die Abfragepläne und die Ausgabe von zwischen Amazon DocumentDB und MongoDB unterscheiden. explain() 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 erlaubt zu einem bestimmten Zeitpunkt nur die Erstellung eines Indexes für eine Sammlung. 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 von Indizes im Hintergrund, wenn sie für createIndexes oder seine Shell-Helfer und angegeben wurde. createIndex() createIndexes()

Ein TTL-Index (Time to Live) beginnt mit dem Ablaufen von Dokumenten, 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 } ]}) in einem Array 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 des Arrays wie erwartet, wenn sich der leere Zeichenfolgenschlüssel nicht am Ende der Pfadsuche befindet. Wenn sich der leere Zeichenkettenschlüssel jedoch am Ende der Pfadsuche befindet, wird das Array nicht durchsucht.

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

MongoDB-APIs, Operationen und Datentypen

Amazon DocumentDB ist mit den MongoDB-APIs 3.6, 4.0, 5.0 und 8.0 kompatibel. Die aktuelle Liste der unterstützten Funktionen finden Sie unter Unterstützte MongoDB-APIs, Operationen und Datentypen in Amazon DocumentDB.

Dienstprogramme Mongodump und Mongorestore

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 oder verwenden. mongodump mongorestore Wenn Sie eine neue Datenbank in Amazon DocumentDB mithilfe von Amazon DocumentDB erstellenmongorestore, müssen Sie zusätzlich zum Wiederherstellungsvorgang die Benutzerrollen neu erstellen.

Reihenfolge der Ergebnisse

Amazon DocumentDB garantiert keine 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 Aggregationsstufe wird die Sortierreihenfolge nicht beibehalten, es sei denn, die $sort Phase ist die letzte Phase in der Aggregationspipeline. Wenn die $sort Aggregationsstufe in Kombination mit der Aggregationsstufe verwendet wird, wird die $group Aggregationsstufe nur auf die $sort Akkumulatoren und angewendet. $first $last In Amazon DocumentDB 4.0 wurde die Unterstützung hinzugefügt, um die Sortierreihenfolge aus der vorherigen Phase $push zu berücksichtigen. $sort

Wiederholbare Schreibvorgänge

Ab MongoDB 4.2-kompatiblen Treibern sind wiederholbare Schreibvorgänge standardmäßig aktiviert. Amazon DocumentDB unterstützt derzeit jedoch keine wiederholbaren Schreibversuche. 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 BeispielMongoClient("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://<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 dies weglassen$exists, verwendet Amazon DocumentDB den Index mit geringer Dichte nicht.

Im Folgenden wird ein -Beispiel gezeigt.

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

Bei Indizes mit geringer Dichte und 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.

Verwendung von $elemMatch innerhalb eines $all-Ausdrucks

Amazon DocumentDB unterstützt derzeit nicht die Verwendung des $elemMatch Operators innerhalb eines Ausdrucks. $all 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 ($) und Punkt (.) in Feldnamen

Amazon DocumentDB unterstützt nicht die Abfrage von Feldern mit dem Präfix Dollar ($) in $in, $nin und $all in verschachtelten Objekten. Beispielsweise ist die folgende Abfrage in Amazon DocumentDB nicht gültig:

coll.find({"field": {"$all": [{ "$a": 1 }]}})

$lookup

Amazon DocumentDB unterstützt die Fähigkeit, Gleichheitsübereinstimmungen durchzuführen (z. B. Left Outer Join) und unterstützt auch unkorrelierte Unterabfragen, unterstützt jedoch keine korrelierten Unterabfragen.

Verwendung eines Indexes mit $lookup

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

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

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:

Sie können den Indexierungsalgorithmus, 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-Vorgängen

Einen PlanHint verwenden

Wenn Sie den Abfrageoptimierer zwingen möchten, einen anderen Indizierungsalgorithmus 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. Unten finden Sie ein Beispiel für die Syntax für den Kommentar:

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 Indexierungsalgorithmus zu ändern (d. h.HASH//SORT). NESTED_LOOP

Das folgende Beispiel zeigt, wie Sie executionStats die Ausführungszeit der $lookup Stufe 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. Scans in umgekehrter Reihenfolge ({$natural: -1}) führen zu einemMongoServerError.