Amazon DocumentDB: wie funktioniert es

Amazon DocumentDB (mit MongoDB-Kompatibilität) ist ein vollständig verwalteter MongoDB-compatible Datenbankdienst. Mit Amazon DocumentDB können Sie denselben Anwendungscode ausführen und dieselben Treiber und Tools verwenden, die Sie mit MongoDB verwenden. Amazon DocumentDB ist mit MongoDB 3.6, 4.0, 5.0 und 8.0 kompatibel.

Amazon DocumentDB-Versionen

Anmerkung

Die Nummerierung von Nebenversionen gilt für Amazon DocumentDB 5.0 und höher. Amazon DocumentDB 3.6 und 4.0 verwenden nur Hauptversionen mit Engine-Patches.

Ab Amazon DocumentDB 5.0 verwendet die Engine-Version ein vierstufiges Nummerierungsschema: major.major.minor.patch.

• Hauptversion — Identifiziert durch die ersten beiden Nummern der Version (z. B. 5.0). Die Hauptversion steht für den MongoDB-Kompatibilitätsgrad. Hauptversionen führen neue Funktionen, Leistungsverbesserungen und MongoDB-Kompatibilitätsupdates ein. Für das Upgrade zwischen Hauptversionen (z. B. von 4.0 auf 5.0) ist ein Hauptversions-Upgrade (MVU) erforderlich. Weitere Informationen finden Sie unter Direktes Upgrade der Hauptversion von Amazon DocumentDB.

• Nebenversion — Identifiziert durch die dritte Versionsnummer (z. B. 1 in 5.0.1). Nebenversionen enthalten Verbesserungen wie neue Funktionen, Sicherheitsupdates und Bugfixes innerhalb derselben Hauptversion. Sie können manuell auf eine neue Nebenversion aktualisieren. Weitere Informationen finden Sie unter Upgrade der Nebenversion von Amazon DocumentDB.

• Patch-Version — Engine-Patches werden innerhalb einer Nebenversion angewendet und enthalten wichtige Sicherheits- und Bugfixes. Die Patch-Version wird anhand der Engine-Patch-Version (z. B.3.0.17983) nachverfolgt, die Sie überprüfen können, indem Sie Folgendes ausführendb.runCommand({getEngineVersion: 1}). Patches werden während des Wartungsfensters Ihres Clusters angewendet. Weitere Informationen finden Sie unter Wartung von Amazon DocumentDB.

Wenn Sie einen neuen Cluster erstellen, können Sie jede verfügbare Engine-Version angeben. Informationen zu verfügbaren Versionen und Supportdaten finden Sie unterUnterstützungstermine der Amazon DocumentDB DocumentDB-Engine-Version.

Wenn Sie Amazon DocumentDB verwenden, erstellen Sie zunächst einen Cluster. Ein DB-Cluster besteht aus null oder mehreren Datenbank-Instances und einem Cluster-Volume, das die Daten für diese Instances verwaltet. Ein Amazon DocumentDB-Cluster-Volume ist ein virtuelles Datenbank-Speicher-Volume, das sich über mehrere Availability Zones erstreckt. Jede Availability Zone verfügt über eine Kopie der Cluster-Daten.

Ein Amazon DocumentDB-Cluster besteht aus zwei Komponenten:

• Cluster-Volume — Verwendet einen Cloud-nativen Speicherservice, um Daten auf sechs Arten über drei Availability Zones zu replizieren und so einen äußerst langlebigen und verfügbaren Speicher bereitzustellen. Ein Amazon DocumentDB-Cluster hat genau ein Cluster-Volume, auf dem bis zu 256 TiB an Daten für Engine-Version 8.0 und höher gespeichert werden können (128 TiB für frühere Engine-Versionen).

• Instances — Stellen die Rechenleistung für die Datenbank bereit und schreiben Daten auf das Cluster-Speicher-Volume und lesen Daten von diesem. Ein Amazon DocumentDB-Cluster kann 0—16 Instances haben.

Instances erfüllen eine von zwei Rollen:

• Primäre Instanz — Unterstützt Lese- und Schreibvorgänge und führt alle Datenänderungen am Cluster-Volume durch. Jeder Amazon DocumentDB-Cluster hat eine primäre Instance.

• Replica-Instance — Unterstützt nur Lesevorgänge. Ein Amazon DocumentDB-Cluster kann zusätzlich zur primären Instance bis zu 15 Replikate haben. Die Verwendung mehrerer Replikate ermöglicht es Ihnen, die Leseauslastungen zu verteilen. Darüber hinaus erhöhen Sie durch die Platzierung von Replikaten in separaten Availability Zones auch die Cluster-Verfügbarkeit.

Das folgende Diagramm veranschaulicht die Beziehung zwischen dem Cluster-Volume, der primären Instance und den Replikaten in einem Amazon DocumentDB-Cluster:

Cluster-Instances müssen nicht von derselben Instance-Klasse sein. Sie können beliebig bereitgestellt und beendet werden. Mit dieser Architektur können Sie die Rechenkapazität Ihres Clusters unabhängig von seiner Storage-Funktionalität skalieren.

Wenn Ihre Anwendung Daten in die Primär-Instance schreibt, schreibt diese die Daten dauerhaft in das Cluster-Volume. Anschließend repliziert es den Status dieses Schreibvorgangs (nicht die Daten) auf jedes aktive Replikat. Amazon DocumentDB-Replikate sind nicht an der Verarbeitung von Schreibvorgängen beteiligt, weshalb Amazon DocumentDB-Replikate für die Skalierung von Lesevorgängen von Vorteil sind. Lesevorgänge aus Amazon DocumentDB-Replikaten sind letztlich konsistent, wobei die Replikatverzögerung minimal ist — in der Regel weniger als 100 Millisekunden, nachdem die primäre Instance die Daten geschrieben hat. Lesezugriffe von den Replikaten werden garantiert in der Reihenfolge gelesen, in der sie auf die primäre Instance geschrieben wurden. Die Replikationsverzögerung hängt von der Rate der Datenänderung ab. Perioden mit hoher Schreibaktivität können die Replikationsverzögerung erhöhen. Weitere Informationen finden Sie in den ReplicationLag-Metriken unter Amazon DocumentDB-Metriken.

Amazon DocumentDB-Endpunkte

Amazon DocumentDB bietet mehrere Verbindungsoptionen für eine Vielzahl von Anwendungsfällen. Um eine Verbindung zu einer Instance in einem Amazon DocumentDB-Cluster herzustellen, geben Sie den Endpunkt der Instance an. Ein Endpunkt ist eine Host-Adresse und eine Portnummer, getrennt durch einen Doppelpunkt.

Stellen Sie mithilfe des Cluster-Endpunkts im Replikat-Set-Modus eine Verbindung zu Ihrem Cluster her (sieheVerbindung zu Amazon DocumentDB als Replikatsatz herstellen). Verwenden Sie diesen Ansatz, es sei denn, Sie müssen eine Verbindung zum Reader-Endpunkt oder einem Instance-Endpunkt herstellen. Um Anforderungen an Ihre Replikate weiterzuleiten, wählen Sie eine Treibereinstellung für die Leseeinstellung aus, die die Leseskalierung maximiert und gleichzeitig die Anforderungen für die Lesekonsistenz Ihrer Anwendung erfüllt. Die Leseeinstellung secondaryPreferred ermöglicht Replica-Lesevorgänge, sodass die primäre Instance produktiver sein kann.

Die folgenden Endpunkte sind in einem Amazon DocumentDB-Cluster verfügbar.

Cluster-Endpunkt

Der Cluster-Endpunkt verbindet sich mit der aktuellen primären Instance Ihres Clusters. Der Cluster-Endpunkt kann für Lese- und Schreibvorgänge verwendet werden. Ein Amazon DocumentDB-Cluster hat genau einen Cluster-Endpunkt.

Der Cluster-Endpunkt bietet Failover-Support für Lese-/Schreibverbindungen zum Cluster. Wenn die aktuelle primäre Instance Ihres Clusters ausfällt und Ihr Cluster mindestens eine aktive Read Replica hat, leitet der Cluster-Endpunkt Verbindungsanforderungen automatisch an eine neue primäre Instance weiter. Wenn Sie eine Verbindung zu Ihrem Amazon DocumentDB-Cluster herstellen, verwenden Sie den Cluster-Endpunkt im Replikat-Set-Modus (siehe). Verbindung zu Amazon DocumentDB als Replikatsatz herstellen

Im Folgenden finden Sie ein Beispiel für einen Amazon DocumentDB-Cluster-Endpunkt:

sample-cluster.cluster-123456789012.us-east-1.docdb.amazonaws.com:27017

Im Folgenden finden Sie ein Beispiel für eine Verbindungszeichenfolge für diesen Cluster-Endpunkt:

mongodb://username:[e-mail]:27017

Informationen zum Suchen der Endpunkte eines Clusters finden Sie unter Die Endpunkte eines Clusters finden.

Leser-Endpunkt

Der Reader-Endpunkt agiert als Load-Balancer für schreibgeschützte Verbindungen für alle verfügbaren Replikate in Ihrem Cluster. Ein Cluster-Reader-Endpunkt fungiert als Cluster-Endpunkt, wenn Sie eine Verbindung über den replicaSet Modus herstellen. Das heißt, in der Verbindungszeichenfolge lautet der Parameter für das Replikatset. &replicaSet=rs0 In diesem Fall können Sie Schreibvorgänge auf dem Primärserver ausführen. Wenn Sie jedoch eine Verbindung zum Cluster herstellen, indem Sie angebendirectConnection=true, dass der Versuch, einen Schreibvorgang über eine Verbindung zum Reader-Endpunkt durchzuführen, zu einem Fehler führt. Ein Amazon DocumentDB-Cluster hat genau einen Reader-Endpunkt.

Wenn der Cluster nur eine (primäre) Instance enthält, verbindet sich der Reader-Endpunkt mit der primären Instance. Wenn Sie Ihrem Amazon DocumentDB-Cluster eine Replica-Instance hinzufügen, öffnet der Reader-Endpunkt schreibgeschützte Verbindungen zum neuen Replikat, nachdem es aktiv ist.

Im Folgenden finden Sie ein Beispiel für einen Reader-Endpunkt für einen Amazon DocumentDB-Cluster:

sample-cluster.cluster-ro-123456789012.us-east-1.docdb.amazonaws.com:27017

Im Folgenden finden Sie ein Beispiel für eine Verbindungszeichenfolge unter Verwendung eines Reader-Endpunkts:

mongodb://username:[e-mail]:27017 

Der Reader-Endpunkt verteilt nur die Last der Read-only-Verbindungen – nicht die der Leseanforderungen. Wenn einige Reader-Endpunktverbindungen stärker genutzt werden als andere, sind Ihre Leseanforderungen möglicherweise nicht gleichmäßig zwischen Instances im Cluster verteilt. Es wird empfohlen, dass Sie zum Verteilen von Anforderungen eine Verbindung zum Clusterendpunkt als Replikatsatz herstellen und die Lesevorstellungsoption secondaryPreferred nutzen.

Informationen zum Suchen der Endpunkte eines Clusters finden Sie unter Die Endpunkte eines Clusters finden.

Instance-Endpunkt

Ein Instance-Endpunkt verbindet sich mit einer bestimmten Instance innerhalb Ihres Clusters. Der Instance-Endpunkt für die aktuelle Primär-Instance kann für Lese- und Schreibvorgänge verwendet werden. Der Versuch, Schreiboperationen auf einen Instance-Endpunkt für ein Lesereplikat durchzuführen, führt jedoch zu einem Fehler. Ein Amazon DocumentDB-Cluster hat einen Instance-Endpunkt pro aktiver Instance.

Ein Instance-Endpunkt bietet für Szenarien, in denen der Cluster-Endpunkt oder der Lese-Endpunkt möglicherweise nicht geeignet ist, direkte Kontrolle über Verbindungen zu einer bestimmten Instance. Ein Beispiel für einen Anwendungsfall ist die Bereitstellung für einen periodischen Read-Only-Analyse-Workload. Sie können eine Replikat-Instance bereitstellen, die größer als üblich ist, sich direkt mit der neuen größeren Instance und ihrem Instance-Endpunkt verbinden, die Analyseabfragen ausführen und die Instance dann beenden. Die Verwendung des Instance-Endpunkts verhindert, dass sich der Analyseverkehr auf andere Cluster-Instances auswirkt.

Im Folgenden finden Sie ein Beispiel für einen Instance-Endpunkt für eine einzelne Instance in einem Amazon DocumentDB-Cluster:

sample-instance.123456789012.us-east-1.docdb.amazonaws.com:27017

Im Folgenden finden Sie ein Beispiel für eine Verbindungszeichenfolge mit diesem Instance-Endpunkt:

mongodb://username:[e-mail]:27017 

Anmerkung

Die Rolle einer Instance als "Primär" oder "Replikat" kann sich aufgrund eines Failover-Ereignisses ändern. Ihre Anwendungen sollten niemals davon ausgehen, dass ein bestimmter Instance-Endpunkt die primäre Instance ist. Stellen Sie keine Verbindung zu Instance-Endpunkten für Produktionsanwendungen her. Verwenden Sie stattdessen den Cluster-Endpunkt im Replikatsatzmodus (sieheVerbindung zu Amazon DocumentDB als Replikatsatz herstellen). Weitere Informationen zur erweiterten Kontrolle der Instance-Failover-Priorität finden Sie unter Grundlegendes zur Amazon DocumentDB-Cluster-Fehlertoleranz.

Informationen zum Suchen der Endpunkte eines Clusters finden Sie unter Den Endpunkt einer Instanz finden.

Replikat-Set-Modus

Sie können im Replikatsatzmodus eine Verbindung zu Ihrem Amazon DocumentDB-Cluster-Endpunkt herstellen, indem Sie den Namen des Replikatsatzes angeben. rs0 Die Verbindung im Replikatsatzmodus bietet die Möglichkeit, die Optionen Read Concern, Write Concern und Read Preference festzulegen. Weitere Informationen finden Sie unter Lesekonsistenz.

Im Folgenden finden Sie ein Beispiel für eine Verbindungszeichenfolge, die im Replikatsatzmodus verbunden ist:

mongodb://username:[e-mail]:27017/?replicaSet=rs0

Wenn Sie im Replica-Set-Modus eine Verbindung herstellen, wird Ihr Amazon DocumentDB-Cluster Ihren Treibern und Clients als Replikatsatz angezeigt. Instances, die Ihrem Amazon DocumentDB-Cluster hinzugefügt und daraus entfernt wurden, werden automatisch in der Konfiguration des Replikatsatzes wiedergegeben.

Jeder Amazon DocumentDB-Cluster besteht aus einem einzelnen Replikatsatz mit dem Standardnamen. rs0 Der Name des Replikatsatzes kann nicht geändert werden.

Die Verbindung mit dem Cluster-Endpunkt im Replikatsatzmodus ist die empfohlene Methode für den allgemeinen Gebrauch.

Anmerkung

Alle Instances in einem Amazon DocumentDB-Cluster überwachen denselben TCP-Port auf Verbindungen.

TLS-Unterstützung

Weitere Informationen zur Verbindung mit Amazon DocumentDB mithilfe von Transport Layer Security (TLS) finden Sie unterVerschlüsseln von Daten während der Übertragung.

Amazon DocumentDB-Speicher

Amazon DocumentDB-Daten werden auf einem Cluster-Volume gespeichert. Dabei handelt es sich um ein einzelnes, virtuelles Volume, das Solid-State-Laufwerke (SSDs) verwendet. Ein Cluster-Volume besteht aus sechs Kopien Ihrer Daten, die automatisch über mehrere Availability Zones gleichzeitig repliziert werden. AWS-Region Diese Replikation trägt dazu bei, dass Ihre Daten sehr langlebig sind und weniger Datenverlust möglich ist. Sie trägt außerdem dazu bei, dass Ihr Cluster während eines Failovers besser verfügbar ist, da Kopien Ihrer Daten bereits in anderen Availability Zones vorhanden sind. Diese Kopien können weiterhin Datenanfragen an die Instances in Ihrem Amazon DocumentDB-Cluster weiterleiten.

Informationen zur Abrechnung des -Datenspeichers

Amazon DocumentDB erhöht automatisch die Größe eines Cluster-Volumes, wenn die Datenmenge zunimmt. Ein Amazon DocumentDB-Cluster-Volume kann auf eine maximale Größe von 256 TiB für Engine-Version 8.0 und höher anwachsen (128 TiB für frühere Engine-Versionen). Ihnen wird jedoch nur der Speicherplatz in Rechnung gestellt, den Sie in einem Amazon DocumentDB-Cluster-Volume verwenden. Ab Amazon DocumentDB 4.0 verringert sich der insgesamt zugewiesene Speicherplatz um einen vergleichbaren Betrag, wenn Daten entfernt werden, z. B. indem eine Sammlung oder ein Index gelöscht wird. Somit können Sie die Speicherkosten senken, indem Sie Sammlungen, Indizes und Datenbanken löschen, die Sie nicht mehr benötigen. In Amazon DocumentDB Version 3.6 kann das Cluster-Volume Speicherplatz wiederverwenden, der beim Entfernen von Daten frei wird, aber das Volume selbst nimmt nie an Größe ab. Daher werden Sie in Version 3.6 möglicherweise keine Änderung des Speichers feststellen, wenn Sie eine Sammlung oder einen Index löschen, obwohl der freigewordene Speicherplatz wiederverwendet wird.

Anmerkung

Bei Amazon DocumentDB 3.6 basieren die Speicherkosten auf dem Speicherwert „High Water Mark“ (dem Höchstbetrag, der dem Amazon DocumentDB-Cluster zu einem beliebigen Zeitpunkt zugewiesen wurde). Sie können die Kosten kontrollieren, indem Sie ETL-Praktiken vermeiden, bei denen große Mengen an temporären Informationen erzeugt werden oder bei denen große Mengen neuer Daten geladen werden, bevor nicht mehr benötigte ältere Daten entfernt werden. Wenn das Entfernen von Daten aus einem Amazon DocumentDB-Cluster zu einer beträchtlichen Menge an zugewiesenem, aber ungenutztem Speicherplatz führt, erfordert das Zurücksetzen der Hochwassermarke einen logischen Datendump und die Wiederherstellung auf einem neuen Cluster mithilfe eines Tools wie oder. mongodump mongorestore Das Erstellen und Wiederherstellen eines Snapshots führt nicht zur Reduzierung des zugeteilten Speichers, da das physische Layout des zugrunde liegenden Speichers im wiederhergestellten Snapshot unverändert bleibt.

Anmerkung

Bei der Nutzung von Hilfsprogrammen wie mongodump diesen mongorestore fallen I/O Gebühren an, die von der Größe der Daten abhängen, die auf das Speichervolume gelesen und geschrieben werden.

Informationen zur Speicherung und I/O Preisgestaltung von Amazon DocumentDB finden Sie in den häufig gestellten Fragen zu Preisen und Preisen von Amazon DocumentDB (mit MongoDB-Kompatibilität). https://aws.amazon.com/documentdb/faqs/#Pricing

Amazon DocumentDB-Replikation

In einem Amazon DocumentDB-Cluster stellt jede Replikat-Instance einen unabhängigen Endpunkt zur Verfügung. Diese Replikat-Endpunkte bieten Lesezugriff auf die Daten im Cluster-Volume. Mit ihnen können Sie die Leselast für Ihre Daten über mehrere replizierte Instances hinweg skalieren. Sie tragen auch dazu bei, die Leistung beim Lesen von Daten zu verbessern und die Verfügbarkeit der Daten in Ihrem Amazon DocumentDB-Cluster zu erhöhen. Amazon DocumentDB-Repliken sind ebenfalls Failover-Ziele und werden schnell hochgestuft, wenn die primäre Instance für Ihren Amazon DocumentDB-Cluster ausfällt.

Zuverlässigkeit von Amazon DocumentDB

Amazon DocumentDB wurde so konzipiert, dass es zuverlässig, langlebig und fehlertolerant ist. (Um die Verfügbarkeit zu verbessern, sollten Sie Ihren Amazon DocumentDB-Cluster so konfigurieren, dass er über mehrere Replikat-Instances in verschiedenen Availability Zones verfügt.) Amazon DocumentDB enthält mehrere automatische Funktionen, die es zu einer zuverlässigen Datenbanklösung machen.

Automatische Speicherplatzreparatur

Amazon DocumentDB verwaltet mehrere Kopien Ihrer Daten in drei Availability Zones, wodurch die Wahrscheinlichkeit, dass Daten aufgrund eines Speicherausfalls verloren gehen, erheblich reduziert wird. Amazon DocumentDB erkennt automatisch Fehler im Cluster-Volume. Wenn ein Segment eines Cluster-Volumes ausfällt, repariert Amazon DocumentDB das Segment sofort. Es verwendet die Daten der anderen Volumes, aus denen sich das Cluster-Volumen zusammensetzt, um sicherzustellen, dass die Daten im reparierten Segment aktuell sind. Dadurch vermeidet Amazon DocumentDB Datenverluste und reduziert die Notwendigkeit einer Point-in-Time-Wiederherstellung zur Wiederherstellung nach einem Instance-Ausfall.

Überlebensfähiges Cache-Warming

Amazon DocumentDB verwaltet seinen Seitencache in einem von der Datenbank getrennten Prozess, sodass der Seitencache unabhängig von der Datenbank überleben kann. Im unwahrscheinlichen Fall eines Datenbankausfalls, bleibt der Seiten-Cache im Arbeitsspeicher. Auf diese Weise wird sichergestellt, dass der Pufferpool beim Neustart der Datenbank mit dem aktuellen Zustand vorbereitet wird.

Wiederherstellung nach einem Ausfall

Amazon DocumentDB ist so konzipiert, dass es sich nach einem Absturz fast augenblicklich erholt und Ihre Anwendungsdaten weiterhin bereitstellt. Amazon DocumentDB führt die Wiederherstellung nach einem Absturz asynchron auf parallelen Threads durch, sodass Ihre Datenbank fast unmittelbar nach einem Absturz geöffnet und verfügbar ist.

Verwaltung der Ressourcen

Amazon DocumentDB schützt Ressourcen für kritische Prozesse wie Zustandsprüfungen. Wenn eine Instance einer hohen Speicherbelastung ausgesetzt ist, drosselt Amazon DocumentDB Anfragen. Einige Operationen werden möglicherweise in die Warteschlange gestellt, bis der Speicherdruck nachlässt. Wenn die Speicherauslastung anhält, kann es zu einem Timeout bei Vorgängen in der Warteschlange kommen.

Überwachen Sie anhand der folgenden CloudWatch Messwerte, ob zu wenig Speicherplatz zur Verfügung steht:LowMemThrottleQueueDepth,,. LowMemThrottleMaxQueueDepth LowMemNumOperationsThrottled LowMemNumOperationsTimedOut Weitere Informationen finden Sie unter Überwachung von Amazon DocumentDB mit CloudWatch.

Wenn Sie eine anhaltende Speicherauslastung feststellen, skalieren Sie Ihre Instance, um zusätzlichen Speicher für Ihre Arbeitslast bereitzustellen.

Präferenzoptionen lesen

Amazon DocumentDB verwendet einen Cloud-nativen Shared Storage-Service, der Daten sechsmal über drei Availability Zones repliziert, um ein hohes Maß an Haltbarkeit zu gewährleisten. Amazon DocumentDB ist nicht darauf angewiesen, Daten auf mehrere Instances zu replizieren, um eine lange Lebensdauer zu gewährleisten. Die Daten Ihres Clusters sind beständig, unabhängig davon, ob sie eine einzelne Instance oder 15 Instances enthalten.

Themen

• Haltbarkeit schreiben

• Isolation lesen

• Lesekonsistenz

• Hohe Verfügbarkeit

• Lesevorgänge skalieren

Haltbarkeit schreiben

Amazon DocumentDB verwendet ein einzigartiges, verteiltes, fehlertolerantes, selbstheilendes Speichersystem. Dieses System repliziert sechs Kopien (V=6) Ihrer Daten in drei AWS Availability Zones, um eine hohe Verfügbarkeit und Beständigkeit zu gewährleisten. Beim Schreiben von Daten stellt Amazon DocumentDB sicher, dass alle Schreibvorgänge dauerhaft auf den meisten Knoten aufgezeichnet werden, bevor der Client den Schreibvorgang bestätigt. Wenn Sie einen MongoDB-Replikatsatz mit drei Knoten verwenden, {w:3, j:true} würde die Verwendung eines Write-Concern of im Vergleich zu Amazon DocumentDB die bestmögliche Konfiguration ergeben.

Schreibvorgänge in einen Amazon DocumentDB-Cluster müssen von der Writer-Instance des Clusters verarbeitet werden. Der Versuch, in einen Reader zu schreiben, führt zu einem Fehler. Ein bestätigter Schreibvorgang von einer Amazon DocumentDB-Primärinstanz ist dauerhaft und kann nicht rückgängig gemacht werden. Amazon DocumentDB ist standardmäßig sehr robust und unterstützt keine Option für nicht dauerhafte Schreibvorgänge. Sie können die Zuverlässigkeitsstufe (d. h. die Option Write Concern) nicht ändern. Amazon DocumentDB ignoriert w=anything und ist effektiv w: 3 und j: true. Sie können es nicht reduzieren.

Da Speicher und Rechenleistung in der Amazon DocumentDB-Architektur getrennt sind, ist ein Cluster mit einer einzigen Instance äußerst robust. Die Zuverlässigkeit wird auf der Speicherschicht geregelt. Daher erreichen ein Amazon DocumentDB-Cluster mit einer einzelnen Instance und ein Cluster mit drei Instances das gleiche Maß an Haltbarkeit. Sie können Ihren Cluster für Ihren speziellen Anwendungsfall konfigurieren und gleichzeitig für eine hohe Datenbeständigkeit sorgen.

Schreibvorgänge in einen Amazon DocumentDB-Cluster sind innerhalb eines einzelnen Dokuments atomar.

Amazon DocumentDB unterstützt wtimeout diese Option nicht und gibt keinen Fehler zurück, wenn ein Wert angegeben wird. Schreibvorgänge in die primäre Amazon DocumentDB-Instance werden garantiert nicht auf unbestimmte Zeit blockiert.

Isolation lesen

Lesevorgänge aus einer Amazon DocumentDB-Instance geben nur Daten zurück, die vor Beginn der Abfrage dauerhaft sind. Lesezugriffe geben niemals Daten zurück, die nach Beginn der Ausführung der Abfrage geändert wurden. Auch "Dirty-Reads" sind unter keinen Umständen möglich.

Lesekonsistenz

Aus einem Amazon DocumentDB-Cluster gelesene Daten sind dauerhaft und werden nicht zurückgesetzt. Sie können die Lesekonsistenz für Amazon DocumentDB-Lesevorgänge ändern, indem Sie die Lesepräferenz für die Anfrage oder Verbindung angeben. Amazon DocumentDB unterstützt keine Option zum Lesen, die nicht dauerhaft ist.

Lesevorgänge aus der primären Instance eines Amazon DocumentDB-Clusters sind unter normalen Betriebsbedingungen sehr konsistent und weisen eine Lese-nach-Schreib-Konsistenz auf. Tritt zwischen dem Schreiben und dem nachfolgenden Lesen ein Failover-Ereignis auf, kann das System kurzzeitig einen nicht "Strongly Consistent"-Wert zurückgeben. Alle Lesezugriffe auf einer gelesenen Replik sind "Eventually Consistent" und geben die Daten in der gleichen Reihenfolge zurück, oft mit weniger als 100 ms Replikationsverzögerung.

Amazon DocumentDB — Leseeinstellungen

Amazon DocumentDB unterstützt das Festlegen einer Lesepräferenzoption nur, wenn Daten vom Cluster-Endpunkt im Replikatsatzmodus gelesen werden. Das Festlegen einer Lesepräferenzoption wirkt sich darauf aus, wie Ihr MongoDB-Client oder -Treiber Leseanfragen an Instances in Ihrem Amazon DocumentDB-Cluster weiterleitet. Sie können Leseeinstellungen für eine bestimmte Abfrage oder als allgemeine Option in Ihrem MongoDB-Treiber festlegen. (Lesen Sie in der Dokumentation Ihres Clients oder Treibers nach, wie Sie eine Leseeinstellung festlegen können.)

Wenn Ihr Client oder Treiber im Replica-Set-Modus keine Verbindung zu einem Amazon DocumentDB-Cluster-Endpunkt herstellt, ist das Ergebnis der Angabe einer Lesepräferenz undefiniert.

Amazon DocumentDB unterstützt das Festlegen von Tag-Sets als Lesepräferenz nicht.

Unterstützte Optionen für Leseeinstellungen

• primary— Durch die Angabe einer primary Lesepräferenz wird sichergestellt, dass alle Lesevorgänge an die primäre Instanz des Clusters weitergeleitet werden. Wenn die primäre Instance nicht verfügbar ist, schlägt der Lesevorgang fehl. Die Leseeinstellung primary ergibt Lese-After-Write-Konsistenz und eignet sich für Anwendungsfälle, die die Lese-nach-Schreib-Konsistenz über Hochverfügbarkeit und Leseskalierung priorisieren.

  Im folgenden Beispiel wird die Leseeinstellung primary angegeben:

  db.example.find().readPref('primary')

   

• primaryPreferred— Wenn primaryPreferred Sie eine Lesepräferenz angeben, werden Lesevorgänge im Normalbetrieb an die primäre Instance weitergeleitet. Wenn es ein primäres Failover gibt, leitet der Client Anfragen an ein Replikat weiter. Die Leseeinstellung primaryPreferred sorgt für Lese-nach-Schreib-Konsistenz im Normalbetrieb und Eventually Consistent-Lesezugriffe während eines Failoverereignisses. Die Leseeinstellung primaryPreferred ist für Anwendungsfälle geeignet, die die Lese-nach-Schreib-Konsistenz über Hochverfügbarkeit und Leseskalierung priorisieren, jedoch trotzdem eine Hochverfügbarkeit erfordern.

  Im folgenden Beispiel wird die Leseeinstellung primaryPreferred angegeben:

  db.example.find().readPref('primaryPreferred')

   

• secondary— Durch die Angabe einer secondary Lesepräferenz wird sichergestellt, dass Lesevorgänge nur an ein Replikat weitergeleitet werden, niemals an die primäre Instanz. Wenn es in einem Cluster keine Replikat-Instances gibt, schlägt die Leseanforderung fehl. Die Leseeinstellung secondary ergibt Eventually Consistent-Lesezugriffe und ist für Anwendungsfälle geeignet, die den Schreibdurchsatz der primären Instance über die Hochverfügbarkeit und die Lesen-nach-Schreiben-Konsistenz priorisiert.

  Im folgenden Beispiel wird die Leseeinstellung secondary angegeben:

  db.example.find().readPref('secondary')

   

• secondaryPreferred— Durch die Angabe einer secondaryPreferred Lesepräferenz wird sichergestellt, dass Lesevorgänge an ein Lesereplikat weitergeleitet werden, wenn ein oder mehrere Replikate aktiv sind. Wenn es in einem Cluster keine aktiven Replikat-Instances gibt, wird die Leseanforderung an die primäre Instance weitergeleitet. Die Leseeinstellung secondaryPreferred ergibt Eventually Consistent-Lesezugriffe, wenn der Lesezugriff durch ein Read Replica bedient wird. Sie liefert eine Lese-nach-Schreib-Konsistenz, wenn das Lesen von der primären Instance bedient wird (mit Ausnahme von Failover-Ereignissen). Die Leseeinstellung secondaryPreferred ist für Anwendungsfälle geeignet, die Leseskalierung und Hochverfügbarkeit über Lese-nach-Schreib-Konsistenz priorisieren.

  Im folgenden Beispiel wird die Leseeinstellung secondaryPreferred angegeben:

  db.example.find().readPref('secondaryPreferred')

   

• nearest— Die Angabe einer nearest Lesepräferenz leitet Lesevorgänge ausschließlich auf der Grundlage der gemessenen Latenz zwischen dem Client und allen Instances im Amazon DocumentDB-Cluster weiter. Die Leseeinstellung nearest ergibt Eventually Consistent-Lesezugriffe, wenn der Lesezugriff durch ein Read Replica bedient wird. Sie liefert eine Lese-nach-Schreib-Konsistenz, wenn das Lesen von der primären Instance bedient wird (mit Ausnahme von Failover-Ereignissen). Die Leseeinstellung nearest ist für Anwendungsfälle geeignet, die das Erreichen einer möglichst geringen Leselatenz und die Hochverfügbarkeit über die Lese-zu-Schreib-Konsistenz und Leseskalierung priorisieren.

  Im folgenden Beispiel wird die Leseeinstellung nearest angegeben:

  db.example.find().readPref('nearest')

Hohe Verfügbarkeit

Amazon DocumentDB unterstützt hochverfügbare Cluster-Konfigurationen, indem Repliken als Failover-Ziele für die primäre Instance verwendet werden. Wenn die primäre Instance ausfällt, wird eine Amazon DocumentDB-Replica als neue primäre Instance hochgestuft. Dabei gibt es eine kurze Unterbrechung, in der Lese- und Schreibanforderungen an die primäre Instance mit einer Ausnahme fehlschlagen.

Wenn Ihr Amazon DocumentDB-Cluster keine Replikate enthält, wird die primäre Instance bei einem Ausfall neu erstellt. Da das Heraufstufen eines Amazon DocumentDB-Replikats viel schneller ist als das Neuerstellen der primären Instance, erstellen Sie eine oder mehrere Amazon DocumentDB-Repliken als Failover-Ziele.

Replikate, die als Failover-Ziele verwendet werden sollen, sollten dieselbe DB-Instance-Klasse haben wie die primäre Instance. Sie sollten von der primären Instance in verschiedenen Availability Zones bereitgestellt werden. Sie können steuern, welche Replikate als Failover-Ziele bevorzugt werden. Bewährte Methoden zur Konfiguration von Amazon DocumentDB für hohe Verfügbarkeit finden Sie unter. Grundlegendes zur Amazon DocumentDB-Cluster-Fehlertoleranz

Lesevorgänge skalieren

Amazon DocumentDB-Repliken eignen sich ideal für die Skalierung von Lesevorgängen. Sie sind in Ihrem Cluster-Volume vollständig auf Lesevorgänge ausgerichtet, d. h. Replikate verarbeiten keine Schreibvorgänge. Die Datenreplikation geschieht innerhalb des Cluster-Volumes und nicht zwischen Instances. Deshalb sind die Replikat-Ressourcen auf die Verarbeitung von Abfragen ausgelegt und nicht auf das Schreiben und Replizieren von Daten.

Wenn Ihre Anwendung mehr Lesekapazität benötigt, können Sie Ihrem Cluster schnell (in der Regel in weniger als zehn Minuten) eine Replik hinzufügen. Wenn Ihr Lesekapazitätsbedarf sinkt, können Sie nicht benötigte Replikate entfernen. Bei Amazon DocumentDB-Repliken zahlen Sie nur für die Lesekapazität, die Sie benötigen.

Amazon DocumentDB unterstützt die clientseitige Leseskalierung durch die Verwendung von Read Preference-Optionen. Weitere Informationen finden Sie unter Amazon DocumentDB — Leseeinstellungen.

TTL löscht

Löschungen aus einem TTL-Indexbereich über einen Hintergrundprozess erfolgen nach dem Best-Effort-Prinzip und können nicht für einen bestimmten Zeitrahmen garantiert werden. Faktoren wie Instance-Größe, Instance-Ressourcenauslastung, Dokumentgröße und Gesamtdurchsatz können sich auf den Zeitpunkt einer TTL-Löschung auswirken.

Wenn der TTL-Monitor Ihre Dokumente löscht, entstehen bei jeder Löschung E/A-Kosten, was den Rechnungsbetrag erhöht. Wenn der Durchsatz und die TTL-Löschraten steigen, sollten Sie aufgrund der erhöhten I/O-Nutzung mit einer Erhöhung Ihrer Rechnung rechnen.

Wenn Sie einen TTL-Index für eine vorhandene Sammlung erstellen, müssen Sie alle abgelaufenen Dokumente löschen, bevor Sie den Index erstellen. Die aktuelle TTL-Implementierung ist für das Löschen eines kleinen Bruchteils der Dokumente in der Sammlung optimiert. Dies ist typisch, wenn TTL für die Sammlung von Anfang an aktiviert war. Dies kann zu höheren IOPS als nötig führen, wenn eine große Anzahl von Dokumenten auf einmal gelöscht werden muss.

Wenn Sie keinen TTL-Index zum Löschen von Dokumenten erstellen möchten, können Sie Dokumente stattdessen nach Zeit in Sammlungen unterteilen und diese Sammlungen einfach löschen, wenn die Dokumente nicht mehr benötigt werden. Beispiel: Sie können eine Sammlung pro Woche erstellen und diese löschen, ohne dass IO-Kosten anfallen. Dies kann erheblich kostengünstiger sein als die Verwendung eines TTL-Index.

Abrechnungsfähige Ressourcen

Identifizierung fakturierbarer Amazon DocumentDB-Ressourcen

Als vollständig verwalteter Datenbankservice erhebt Amazon DocumentDB Gebühren für Instances, Speicher I/Os, Backups und Datenübertragung. Weitere Informationen finden Sie unter Preise für Amazon DocumentDB (mit MongoDB-Kompatibilität).

Um abrechnungsfähige Ressourcen in Ihrem Konto zu ermitteln und die Ressourcen möglicherweise zu löschen, können Sie das oder verwenden. AWS-Managementkonsole AWS CLI

Verwendung der AWS-Managementkonsole

Mithilfe von können Sie die AWS-Managementkonsole Amazon DocumentDB-Cluster, -Instances und -Snapshots ermitteln, die Sie für eine bestimmte Zeit bereitgestellt haben. AWS-Region

So ermitteln Sie Cluster, Instances und Snapshots:

1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon DocumentDB-Konsole unter. https://console.aws.amazon.com/docdb

2. Um kostenpflichtige Ressourcen in einer anderen Region als Ihrer Standardregion zu finden, wählen Sie in der oberen rechten Ecke des Bildschirms die Region aus, nach der AWS-Region Sie suchen möchten.

   

3. Wählen Sie im Navigationsbereich die Art der kostenpflichtigen Ressource aus: Clusters (Cluster), Instances oder Snapshots.

   

4. Im rechten Bereich werden alle bereitgestellten Cluster, Instances oder Snapshots für die Region aufgelistet. Für Cluster, Instances und Snapshots werden Gebühren berechnet.

Verwendung der AWS CLI

Mithilfe von können Sie die AWS CLI Amazon DocumentDB-Cluster, Instances und Snapshots ermitteln, die Sie für eine bestimmte Zeit bereitgestellt haben. AWS-Region

So ermitteln Sie Cluster und Instances:

Der folgende Code listet Ihre gesamten Cluster und Instances für die angegebene Region auf. Wenn Sie nach Clustern und Instances in Ihrer Standardregion suchen möchten, können Sie den Parameter --region weglassen.

Beispiel

Für Linux, macOS oder Unix:

aws docdb describe-db-clusters \
    --region us-east-1 \
    --query 'DBClusters[?Engine==`docdb`]' | \
       grep -e "DBClusterIdentifier" -e "DBInstanceIdentifier"

Für Windows:

aws docdb describe-db-clusters ^
    --region us-east-1 ^
    --query 'DBClusters[?Engine==`docdb`]' | ^
       grep -e "DBClusterIdentifier" -e "DBInstanceIdentifier"

Die Ausgabe dieser Operation sieht in etwa folgendermaßen aus.

"DBClusterIdentifier": "docdb-2019-01-09-23-55-38",
        "DBInstanceIdentifier": "docdb-2019-01-09-23-55-38",
        "DBInstanceIdentifier": "docdb-2019-01-09-23-55-382",
"DBClusterIdentifier": "sample-cluster",
"DBClusterIdentifier": "sample-cluster2",

So ermitteln Sie Snapshots:

Der folgende Code listet Ihre gesamten Snapshots für die angegebene Region auf. Wenn Sie in Ihrer Standardregion nach Snapshots suchen möchten, können Sie den Parameter --region weglassen.

Für Linux, macOS oder Unix:

aws docdb describe-db-cluster-snapshots \
  --region us-east-1 \
  --query 'DBClusterSnapshots[?Engine==`docdb`].[DBClusterSnapshotIdentifier,SnapshotType]'

Für Windows:

aws docdb describe-db-cluster-snapshots ^
  --region us-east-1 ^
  --query 'DBClusterSnapshots[?Engine==`docdb`].[DBClusterSnapshotIdentifier,SnapshotType]'

Die Ausgabe dieser Operation sieht in etwa folgendermaßen aus.

[
    [
        "rds:docdb-2019-01-09-23-55-38-2019-02-13-00-06",
        "automated"
    ],
    [
        "test-snap",
        "manual"
    ]
]

Sie müssen nur manual-Snapshots löschen. Automated-Snapshots werden gelöscht, wenn Sie den Cluster löschen.

Löschen unerwünschter fakturierbarer Ressourcen

Um einen Cluster zu löschen, müssen Sie zunächst alle Instances im Cluster löschen.

• Weitere Informationen zum Löschen von Instances finden Sie unter Löschen einer Amazon DocumentDB DocumentDB-Instance.

  Wichtig

  Auch wenn Sie die Instances in einem Cluster löschen, wird Ihnen die mit diesem Cluster verbundene Speicher- und Sicherungsnutzung in Rechnung gestellt. Um alle Kosten zu stoppen, müssen Sie auch Ihren Cluster und manuelle Snapshots löschen.

• Weitere Informationen zum Löschen von Clustern finden Sie unter Löschen eines Amazon DocumentDB-Clusters.

• Weitere Informationen zum Löschen manueller Snapshots finden Sie unter Löschen eines Cluster-Snapshots.