Häufig gestellte Fragen zu Amazon DocumentDB (mit MongoDB-Kompatibilität)

Beim Schreiben in den Speicher persistiert Amazon DocumentDB nur ein Schreibvorschau-Protokoll und muss keine Synchronisation der vollständigen Pufferseiten schreiben. Als Ergebnis dieser Optimierung, die die Haltbarkeit nicht beeinträchtigt, sind Amazon DocumentDB-Schreibvorgänge typischerweise schneller als bei gewöhnlichen Datenbanken. Amazon-DocumentDB-Cluster können mehrere Millionen Lesezugriffe pro Sekunde mit bis zu 15 Lesereplikaten verarbeiten.

Aktuelle Informationen zu Regionen und Preisen finden Sie auf der Amazon-DocumentDB-Preisseite.

Ja, Sie können Amazon DocumentDB mit der 1-monatigen kostenlosen Testversion kostenlos testen. Wenn Sie Amazon DocumentDB noch nicht verwendet haben, haben Sie Anspruch auf eine einmonatige kostenlose Testversion. Ihr Unternehmen erhält 30 Tage lang kostenlos 750 Stunden t3.medium-Instance-Nutzung pro Monat, 30 Millionen IOs, 5 GB Speicher und 5 GB Backup-Speicher. Sobald Ihre einmonatige kostenlose Testversion abläuft oder Ihre Nutzung das kostenlose Kontingent überschreitet, können Sie Ihren Cluster herunterfahren, um Gebühren zu vermeiden, oder ihn zu unseren standardmäßigen On-Demand-Tarifen weiter betreiben. Weitere Informationen finden Sie auf der Seite zur kostenlosen Testversion von DocumentDB.

Amazon DocumentDB I/O-Optimized ist die ideale Wahl, wenn Sie vorhersehbare Kosten benötigen oder I/O-intensive Anwendungen haben. Wenn Sie davon ausgehen, dass Ihre I/O-Kosten 25 % Ihrer gesamten Amazon-DocumentDB-Datenbankkosten übersteigen werden, bietet diese Option ein besseres Preis-Leistungs-Verhältnis. Weitere Informationen, einschließlich der ersten Schritte, finden Sie in unserer Dokumentation zu Amazon DocumentDB I/O-Optimized.

Sie können Ihre vorhandenen Datenbank-Cluster einmal alle 30 Tage auf Amazon DocumentDB I/O-Optimized umstellen. Sie können jederzeit zu den Standardspeicherkonfigurationen von Amazon DocumentDB zurückkehren.

Ja, die Gebühren für die E/A-Vorgänge, die für die regionsübergreifende Datenreplikation erforderlich sind, fallen weiterhin an. Amazon DocumentDB I/O-Optimized erhebt keine Gebühren für E/A-Lese- und Schreibvorgänge, was sich von der Datenreplikation unterscheidet. Weitere Informationen finden Sie in unserer Dokumentation zu Amazon DocumentDB I/O-Optimized.

Elastische Cluster von Amazon DocumentDB ermöglicht es Ihnen, Ihre Dokumentendatenbank elastisch zu skalieren, um Millionen von Schreib- und Lesevorgängen mit Petabyte an Speicherkapazität zu verarbeiten. Elastische Cluster vereinfachen die Interaktion von Kunden mit Amazon DocumentDB, indem die zugrunde liegende Infrastruktur automatisch verwaltet wird und Instances nicht mehr erstellt, entfernt, aktualisiert oder skaliert werden müssen.

Sie können einen elastischen Cluster mithilfe der Amazon DocumentDB API, des SDK, der CLI, CloudFormation (CFN) oder der AWS-Konsole erstellen. Geben Sie bei der Bereitstellung Ihres Clusters an, wie viele Shards und wie viel Rechenleistung pro Shard Ihre Workload benötigt. Sobald Sie Ihren Cluster erstellt haben, können Sie die elastische Skalierbarkeit der elastischen Cluster nutzen. Jetzt können Sie eine Verbindung mit dem Cluster der elastischen Cluster herstellen und Daten aus Ihrer Anwendung lesen oder schreiben. Elastische Cluster sind elastisch. Abhängig von den Anforderungen Ihrer Workload können Sie Rechenleistung hinzufügen oder entfernen, indem Sie Ihre Shard-Anzahl und/oder Rechenleistung pro Shard mithilfe der AWS-Konsole, API, CLI oder SDK ändern. Elastische Cluster stellen die zugrunde liegende Infrastruktur automatisch bereit bzw. nehmen sie ab und gleichen Ihre Daten aus.

Elastische Cluster verwendet Sharding, um Daten über das verteilte Speichersystem von Amazon DocumentDB zu partitionieren. Sharding, auch bekannt als Partitionierung, teilt große Datensätze in kleine Datensätze über mehrere Knoten auf und ermöglicht es Kunden, ihre Datenbank über die vertikalen Skalierungsgrenzen einer einzelnen Datenbank hinaus zu skalieren. Elastische Cluster nutzen die Trennung von Datenverarbeitung und Speicherung in Amazon DocumentDB. Anstatt Sammlungen neu zu partitionieren, indem kleine Datenblöcke zwischen Rechenknoten verschoben werden, können elastische Cluster Daten effizient innerhalb des verteilten Speichersystems kopieren.

Elastische Cluster unterstützen die Hash-basierte Partitionierung.

Mit elastischen Clustern können Sie Ihre Workload auf Amazon DocumentDB problemlos nach oben oder nach unten skalieren, in der Regel mit wenig bis gar keinen Anwendungsausfallzeiten oder Leistungseinbußen, unabhängig von der Datengröße. Ein ähnlicher Vorgang auf MongoDB würde die Anwendungsleistung beeinträchtigen und Stunden und in einigen Fällen Tage dauern. Elastische Cluster bieten darüber hinaus differenzierte Verwaltungsfunktionen, wie z. B. Backups ohne Beeinträchtigung und schnelle zeitpunktgenaue Wiederherstellung. Dies ermöglicht es den Kunden, sich mehr auf ihre Anwendungen als auf die Verwaltung ihrer Datenbank zu konzentrieren.

Nein. Sie müssen keine Änderungen an Ihrer Anwendung vornehmen, um elastische Cluster zu verwenden.

Nein, in naher Zukunft können Sie den AWS Database Migration Service (DMS) nutzen, um Daten von einem bestehenden Amazon-DocumentDB-Cluster zu einem Elastic-Clusters-Cluster zu migrieren.

Die Auswahl eines optimalen Shard-Schlüssels für elastische Cluster unterscheidet sich nicht von anderen Datenbanken. Ein hervorragender Shard-Schlüssel zeichnet sich durch zwei Eigenschaften aus: hohe Frequenz und hohe Kardinalität. Wenn Ihre Anwendung beispielsweise user_orders in DocumentDB speichert, müssen Sie die Daten in der Regel durch den Benutzer abrufen. Daher möchten Sie, dass sich alle Bestellungen, die sich auf einen bestimmten Benutzer beziehen, in einem Shard befinden. In diesem Fall wäre user_id ein guter Shard-Schlüssel. Lesen Sie weitere Informationen. 

• Elastische Cluster: Ein Amazon-DocumentDB-Cluster, mit dem Sie den Durchsatz Ihrer Workload auf Millionen von Lese-/Schreibvorgängen pro Sekunde und den Speicherplatz auf Petabyte skalieren können. Ein Cluster für elastische Cluster besteht aus einem oder mehreren Shards für Rechenleistung und einem Speicher-Volume und ist standardmäßig in mehreren Availability Zones hochverfügbar.
• Shard: Ein Shard stellt Rechenleistung für den Cluster für elastische Cluster bereit. Ein Shard hat standardmäßig zwei Knoten, einen Reader/Writer-Knoten und einen Standby-Knoten, der als Failover-Ziel verwendet wird. Sie können über höchstens 32 Shards verfügen und jeder Shard kann höchstens über 64 vCPUs verfügen.
• Shard-Schlüssel: Der Shard-Schlüssel ist ein optionales Feld in Ihren JSON-Dokumenten, die elastische Cluster zur Verteilung des Lese- und Schreibverkehrs auf den übereinstimmenden Shard verwenden. Es wird empfohlen, einen Schlüssel mit vielen eindeutigen Werten auszuwählen. Ein guter Shard-Schlüssel verteilt Ihre Daten gleichmäßig auf die zugrunde liegenden Shards, wodurch Ihre Workload den besten Durchsatz und die beste Leistung erhält. 
• Sharded-Sammlung: Eine Sammlung, deren Daten über einen Cluster für elastische Cluster verteilt sind.

Elastische Cluster lassen sich mit anderen AWS-Services auf die gleiche Weise integrieren, wie es DocumentDB heute tut. Erstens können Sie den AWS Database Migration Service (DMS) verwenden, um von MongoDB und anderen relationalen Datenbanken auf elastische Cluster zu migrieren. Zweitens können Sie den Zustand und die Leistung Ihres Clusters für elastische Cluster mithilfe von Amazon CloudWatch überwachen. Drittens können Sie die Authentifizierung und Autorisierung über AWS-IAM-Benutzer und -Rollen einrichten und AWS VPC für sichere reine VPC-Verbindungen verwenden. Zuletzt können Sie AWS Glue verwenden, um Daten von/zu anderen AWS Services wie S3, Redshift und OpenSearch zu importieren und zu exportieren.

Ja. Sie können Ihre vorhandenen Sharded-Workloads von MongoDB auf elastische Cluster migrieren. Sie können entweder den AWS Database Migration Service oder native MongoDB-Tools wie mongodump und mongorestore verwenden, um Ihre MongoDB-Workload auf elastische Cluster zu migrieren. Elastische Cluster unterstützt auch die häufig verwendeten APIs von MongoDB, wie z. B. shardCollection(), was Ihnen die Flexibilität gibt, vorhandene Tools und Skripte mit Amazon DocumentDB wiederzuverwenden.

Es gibt ein unteres Speicherplatzlimit von 10 GB. Basierend auf der Nutzung Ihres Clusters wächst Ihr Amazon-DocumentDB-Speicher automatisch in 10-GB-Schritten auf bis zu 128 TiB, ohne dass dies Auswirkungen auf die Leistung hat. Mit den elastischen Clustern von Amazon DocumentDB wächst der Speicher automatisch in 10-GB-Schritten auf bis zu 4 PiB. In beiden Fällen besteht keine Notwendigkeit, Speicher im Voraus bereitzustellen.

Amazon DocumentDB wird in zwei Dimensionen skaliert: Speicher und Datenverarbeitung. Der Speicher von Amazon DocumentDB skaliert automatisch von 10 GB auf 128 TiB in instanzbasierten Clustern und bis zu 4 PiB für Amazon DocumentDB Elastic Clusters. Die Rechenkapazität von Amazon DocumentDB kann durch die Erstellung größerer Instances und horizontal (für einen höheren Lesedurchsatz) durch Hinzufügen zusätzlicher Replikat-Instances zum Cluster skaliert werden.

A: Sie können die Ihrer Instance zugewiesenen Rechenressourcen über die AWS-Managementkonsole skalieren, indem Sie die gewünschte Instance auswählen und auf die Schaltfläche „Modify“ klicken. Speicher- und CPU-Ressourcen können durch eine Änderung der Instance-Klasse modifiziert werden.

Alle gewünschten Änderungen der Instance-Klasse erfolgen während des von Ihnen festgelegten Wartungszeitfensters. Alternativ können Sie einen „Sofort anwenden“-Schalter setzen, um die angeforderte Skalierung sofort durchzuführen. Beide Optionen wirken sich ein paar Minuten lang auf die Verfügbarkeit aus, solange die Skalierung durchgeführt wird. Beachten Sie, dass in diesem Fall alle anderen noch ausstehenden Systemänderungen ebenfalls durchgeführt werden.

In Amazon DocumentDB-Clustern sind automatisierte Sicherungen immer aktiviert. Die einfache Datenbank-Backup-Funktion von Amazon DocumentDB ermöglicht eine zeitpunktbezogene Wiederherstellung für Ihre Cluster. Sie können Ihr Sicherungsfenster für zeitpunktbezogene Wiederherstellungen auf bis zu 35 Tage erweitern. Backups wirken sich nicht auf die Leistung der Datenbank aus.

Ja. Manuelle Snapshots können über das Sicherungszeitfenster hinaus beibehalten werden und es gibt keine Leistungseinbußen beim Anlegen von Snapshots. Beachten Sie, dass für die Datenwiederherstellung aus Cluster-Snapshots die Erstellung eines neuen Clusters erforderlich ist.

Amazon DocumentDB macht Ihre Daten automatisch über drei Availability Zones (AZs) in einer Region hinweg dauerhaft und versucht automatisch, Ihre Instance in einer fehlerfreien AZ ohne Datenverlust wiederherzustellen. Im unwahrscheinlichen Fall, dass Ihre Daten im Amazon-DocumentDB-Speicher nicht verfügbar sind, können Sie von einem Cluster-Snapshot wiederherstellen oder einen zeitpunktbezogenen Wiederherstellungsvorgang in einem neuen Cluster durchführen. Beachten Sie, dass der späteste wiederherstellbare Zeitpunkt bei einer zeitpunktbezogenen Wiederherstellung bis zu fünf Minuten zurückliegt.

Sie können vor dem Löschen Ihrer Instance einen abschließenden Snapshot erstellen. In diesem Fall können Sie diesen Snapshot zum Wiederherstellen der gelöschten Instance zu einem späteren Zeitpunkt nutzen. Amazon DocumentDB behält diesen letzten vom Benutzer erstellten Snapshot zusammen mit allen anderen manuell erstellten Snapshots bei, nachdem die Instance gelöscht wurde. Nach dem Löschen der Instance werden nur Snapshots beibehalten (d. h. automatisierte Sicherungen für zeitpunktbezogene Wiederherstellung werden nicht beibehalten).

A: Wenn Sie Ihr AWS-Konto löschen, werden alle im Konto enthaltenen automatisierten Sicherungen und Snapshot-Sicherungen gelöscht.

Ja. Amazon DocumentDB bietet Ihnen die Möglichkeit, Snapshots Ihres Clusters zu erstellen, die Sie später zum Wiederherstellen eines Clusters verwenden können. Sie können einen Snapshot für ein anderes AWS-Konto freigeben und der Besitzer des Empfängerkontos kann Ihren Snapshot verwenden, um einen Cluster wiederherzustellen, die Ihre Daten enthält. Sie können Ihre Snapshots sogar öffentlich zugänglich machen, sodass jeder einen Cluster mit Ihren (öffentlichen) Daten wiederherstellen kann. Sie können diese Funktion nutzen, um Daten zwischen Ihren unterschiedlichen Umgebungen (Produktion, Entwicklung/Tests, Staging usw.) zu teilen, die unterschiedliche AWS-Konten nutzen, sowie Sicherungen all Ihrer Daten in einem getrennten Konto aufzubewahren, falls einmal in Ihr AWS-Konto eingebrochen werden sollte.

Die Freigabe von Snapshots für verschiedene Konten ist kostenlos. Möglicherweise werden Ihnen aber die Snapshots selbst sowie die Cluster, die Sie über freigegebene Snapshots wiederherstellen, in Rechnung gestellt.

A: Die Freigabe von automatischen Cluster-Snapshots wird nicht unterstützt. Um einen automatischen Snapshot freizugeben, müssen Sie manuell eine Kopie des Snapshots erstellen und diese dann freigeben.

A: Nein. Nur Konten, die sich in derselben Region wie das freigebende Konto befinden, können auf Ihre freigegebenen Amazon DocumentDB-Snapshots zugreifen.

Ja. Sie können verschlüsselte Amazon-DocumentDB-Snapshots freigeben. Der Empfänger des gemeinsamen Snapshots muss Zugriff auf den KMS-Schlüssel haben, mit dem der Snapshot verschlüsselt wurde.

A: Nein, Amazon DocumentDB-Snapshots können nur innerhalb des Services verwendet werden.

Sie können vor dem Löschen Ihres Clusters einen abschließenden Snapshot erstellen. In diesem Fall können Sie diesen Snapshot zum Wiederherstellen des gelöschten Clusters zu einem späteren Zeitpunkt nutzen. Amazon DocumentDB behält diesen letzten vom Benutzer erstellten Snapshot zusammen mit allen anderen manuell erstellten Snapshots bei, nachdem der Cluster gelöscht wurde.

Amazon DocumentDB unterteilt Ihr Speichervolumen automatisch in 10-GB-Segmente, die über mehrere Festplatten verteilt sind. Jeder 10 GB große Block Ihres Speicher-Volumes wird auf sechs Arten über drei Availability Zones (AZs) repliziert. Amazon DocumentDB ist so konzipiert, dass es transparent den Verlust von bis zu zwei Kopien der Daten ohne Beeinträchtigung der Schreibverfügbarkeit und bis zu drei Kopien ohne Beeinträchtigung der Verfügbarkeit der Leseverfügbarkeit verarbeiten kann. Das Speicher-Volume von Amazon DocumentDB repariert sich außerdem selbst. Datenblocks und Datenträger werden laufend auf Fehler untersucht und automatisch repariert.

Im Gegensatz zu anderen Datenbanken muss Amazon DocumentDB nach einem Datenbankabsturz das Redo-Protokoll vom letzten Datenbank-Checkpoint (in der Regel fünf Minuten) nicht erneut abspielen und bestätigen, dass alle Änderungen übernommen wurden, bevor die Datenbank wieder für den Betrieb zur Verfügung steht. Das reduziert in den meisten Fällen die Dauer des Neustarts auf weniger als 60 Sekunden. Amazon DocumentDB löst den Cache der Datenbank vom Datenbankprozess und macht diesen sofort zum Zeitpunkt des Neustarts verfügbar. Das verhindert eine Drosselung des Zugriffs bis zur Neuauffüllung des Cache zur Vermeidung von Brownouts.

Amazon DocumentDB unterstützt Lesereplikate, die dasselbe zugrunde liegende Speicher-Volume wie die primäre Instance nutzen. Durch die primäre Instance ausgeführte Updates sind in allen Amazon DocumentDB-Replikate sichtbar.

• Feature: Amazon-DocumentDB-Lesereplikate
• Anzahl der Replikate: Bis zu 15
• Replikationstyp: Asynchron (normalerweise Millisekunden)
• Auswirkungen auf die Leistung der primären Instance: Gering
• Fungiert als Failover-Ziel: Ja (kein Datenverlust)
• Automatisiertes Failover: Ja

Ja, Sie können Ihre Daten mit dem Feature für globale Cluster über Regionen hinweg replizieren. Globale Cluster erstrecken sich über mehrere AWS-Regionen. Globale Cluster replizieren Ihre Daten auf Cluster in bis zu fünf Regionen mit geringen bis keinen Auswirkungen auf die Leistung. Globale Cluster bieten Notfallwiederherstellung nach regionsweiten Ausfällen und ermöglicht globale Lesevorgänge mit niedriger Latenz. In unserem Blog-Beitrag finden Sie weitere Informationen.

Ja. Sie können jeder Instance auf dem Cluster ein Beförderungs-Prioritätskontingent zuweisen. Sollte die primäre Instance ausfallen, befördert Amazon DocumentDB die Replica mit der höchsten Priorität zur neuen primären Instance. Wenn zwei oder mehr Replicas dasselbe Prioritätskontingent haben, befördert Amazon DocumentDB die Replica, die dieselbe Größe wie die primäre Instance hat.

Sie können das Prioritätskontingent für eine Instance jederzeit bearbeiten. Das Bearbeiten eines Prioritätskontingent löst keinen Failover aus.

A: Sie können den Replicas, die Sie nicht zur primären Instance befördern möchten, niedrigere Prioritätskontingente zuweisen. Wenn jedoch die Replicas auf dem Cluster mit höherer Priorität beschädigt oder aus irgendeinem Grund nicht verfügbar sind, befördert Amazon DocumentDB die Replica mit der niedrigeren Priorität.

A: Amazon DocumentDB kann in einer hochverfügbaren Konfiguration bereitgestellt werden, indem Replikations-Instances in mehreren AWS Availability Zones als Failover-Ziele verwendet werden. Im Falle eines Ausfalls einer primären Instance wird eine Replikations-Instance automatisch mit minimaler Betriebsunterbrechung zur neuen primären Instance befördert.

A: Sie können zusätzliche Amazon DocumentDB-Replicas hinzufügen. Amazon DocumentDB-Replicas nutzen denselben zugrunde liegenden Speicher wie die primäre Instance. Jedes Amazon DocumentDB-Replikat kann ohne Datenverlust als primär hochgestuft werden. Damit kann man es bei einem Ausfall der primären Instance zur Verbesserung der Fehlertoleranz verwenden. Um die Verfügbarkeit des Clusters zu erhöhen, erstellen Sie einfach bis 15 Replikate in mehreren AZs, und Amazon DocumentDB wird sie bei einem Ausfall einer Instance automatisch in die Failover-Primärauswahl einbeziehen.

Der Failover wird von Amazon DocumentDB automatisch durchgeführt, sodass Ihre Anwendungen den Datenbankbetrieb schnellstmöglich und ohne Verwaltungsaufwand wieder aufnehmen können.

• Wenn Sie eine Amazon DocumentDB-Replica in derselben oder einer anderen Availability Zone haben, wechselt Amazon DocumentDB den anerkannten Canonical Name Record (CNAME) für Ihre Instance, sodass auf die fehlerfreie Replica verwiesen wird, die dann dadurch zur neuen primären Instance hochgestuft wird. Das gesamte Failover ist in der Regel innerhalb von 30 Sekunden abgeschlossen. 
• Verfügen Sie über keine Amazon DocumentDB-Replica (d. h. über ein einzelnes Instance-Cluster), versucht Amazon DocumentDB zuerst, eine neue Instance in derselben Availability Zone wie die ursprüngliche Instance zu erstellen. Dieser Austausch der ursprünglichen Instance wird nach bestem Bemühen durchgeführt, ist aber nicht immer erfolgreich, z. B. wenn ein Problem vorliegt, das sich allgemein auf die Availability Zone auswirkt. 

Bei Verbindungsunterbrechung muss Ihre Anwendung versuchen, die Verbindung zur Datenbank wiederherzustellen.

A: Amazon DocumentDB erkennt Probleme bei Ihrer primären Instance automatisch und beginnt mit dem Routen Ihres Schreib-/Lesedatenverkehrs zu einer Amazon DocumentDB-Replica-Instance. Dieses Failover ist im Durchschnitt innerhalb von 30 Sekunden abgeschlossen. Außerdem wird der Lesedatenverkehr Ihrer Amazon DocumentDB-Replica-Instances kurz unterbrochen.

A: Da Amazon DocumentDB-Replicas denselben Daten-Volume verwenden wie die primäre Instance, gibt es praktisch keine Verzögerung bei der Replizierung. Wir beobachten normalerweise Verzögerungen im Zehntel-Millisekundenbereich.

Ja. Alle Amazon-DocumentDB-Cluster müssen in einer VPC erstellt werden. Mit Amazon VPC können Sie eine virtuelle Netzwerkarchitektur definieren, die weitgehend einem herkömmlichen Netzwerk entspricht, wie Sie es in Ihrem Rechenzentrum betreiben. Dadurch haben Sie die uneingeschränkte Kontrolle über den Zugriff auf Ihre Amazon DocumentDB-Cluster.

Amazon DocumentDB unterstützt die rollenbasierte Zugriffskontrolle mit integrierten Rollen. RBAC ermöglicht es Ihnen, das Prinzip der geringsten Privilegien durchzusetzen, indem Sie die Aktionen einschränken, zu denen die Benutzer berechtigt sind. Weitere Informationen finden Sie unter Rollenbasierte Zugriffskontrolle von Amazon DocumentDB.

A: Amazon DocumentDB nutzt die strengen Netzwerk- und Autorisierungsanforderungen von VPCs. Die Authentifizierung und Autorisierung für die Amazon-DocumentDB-Management-APIs erfolgt durch IAM-Benutzer, -Rollen und -Richtlinien. Die Authentifizierung bei einer Amazon DocumentDB-Datenbank erfolgt über Standard-MongoDB-Tools und -Treiber mit Salted Challenge Response Authentication Mechanism (SCRAM), dem Standard-Authentifizierungsmechanismus für MongoDB.

Ja. Amazon DocumentDB ermöglicht Ihnen das Verschlüsseln Ihrer Cluster mit Schlüsseln, die Sie mit dem AWS Key Management Service (KMS) verwalten. Bei einem mit Amazon DocumentDB-Verschlüsselung ausgeführten Cluster werden ruhende Daten im zugrundeliegenden Speicher sowie deren automatische Backups, Snapshots und Replikate im gleichen Cluster verschlüsselt. Die Ver- und Entschlüsselung erfolgt problemlos. Weitere Informationen zur Verwendung von KMS mit Amazon DocumentDB finden Sie unter Verschlüsselung von Amazon-DocumentDB-Daten im Ruhezustand.

Derzeit wird die Verschlüsselung eines bestehenden unverschlüsselten Amazon DocumentDB-Clusters nicht unterstützt. Zum Verwenden der Amazon DocumentDB-Verschlüsselung für einen bestehenden unverschlüsselten Cluster müssen Sie einen neuen Cluster mit aktivierter Verschlüsselung erstellen und Ihre Daten auf diesen Cluster migrieren.

Amazon DocumentDB wurde so konzipiert, dass es die strengsten Sicherheitsstandards erfüllt und Sie in die Lage versetzt, unsere Sicherheitsvorkehrungen auf einfache Weise zu überprüfen und Ihren eigenen rechtlichen, gesetzlichen und Compliance-Verpflichtungen nachzukommen. Amazon DocumentDB wurde auf Übereinstimmung mit PCI DSS,ISO 9001, 27001, 27017 und 27018, SOC 1, 2 und 3 sowie der Zertifikation von Health Information Trust Alliance (HITRUST) Common Security Framework (CSF) überprüft und ist außerdem HIPAA-konform. AWS-Compliance-Berichte können in AWS Artifact heruntergeladen werden.

Mit dem In-place Major Version Upgrade (MVU) können Sie Amazon DocumentDB 3.6- oder 4.0-Cluster mithilfe der AWS-Konsole, des Software Development Kit (SDK) oder der Befehlszeilenschnittstelle (CLI) auf Amazon DocumentDB 5.0 aktualisieren. Mit der integrierten MVU müssen Sie keine neuen Cluster erstellen oder Ihre Endpunkte ändern. In-Place-MVU ist in allen Regionen verfügbar, in denen Amazon DocumentDB 5.0 verfügbar ist. Um mit der In-Place-MVU zu beginnen, lesen Sie bitte die In-Place-MVU-Dokumentation.

Mit In-Place-MVU können Sie Ihre Amazon DocumentDB 3.6- oder 4.0-Cluster nahtlos auf Version 5.0 aktualisieren, ohne eine Sicherung und Wiederherstellung auf einem anderen Cluster durchführen zu müssen und ohne andere Datenmigrationstools zu verwenden. Dadurch verringert sich der Zeit- und Arbeitsaufwand, der mit dem üblichen Upgrade-Prozess verbunden ist, der die Konfiguration der Quell- und Zielendpunkte, die Migration von Indizes und Daten, die Änderung des Anwendungscodes und vieles mehr umfasst.

Sie müssen Ihren Endpunkt in Ihren Anwendungen nach dem Upgrade nicht ändern. Da die Daten im selben Cluster verbleiben, fallen für ein Upgrade mithilfe der Funktion keine zusätzlichen Kosten an.

Ausfallzeiten können je nach Anzahl der Sammlungen, Indizes, Datenbanken und Instances von Cluster zu Cluster variieren. Bevor Sie ein In-Place Major Version Upgrade auf Ihrem Produktionscluster durchführen, empfehlen wir Ihnen dringend, es in einer weniger anspruchsvollen Umgebung laufen zu lassen, um Ausfallzeiten und Leistung zu testen und zu überprüfen, ob Ihre Anwendungen nach dem Upgrade wie erwartet funktionieren.

Sie können auch das Fast-Clone-Feature von Amazon DocumentDB verwenden, um Ihre Clusterdaten zu Testzwecken zu klonen. Abhängig von der Komplexität Ihrer Amazon DocumentDB-Implementierung können Sie sich an unseren Datenbanklösungsarchitekten wenden, um zusätzliche Hilfe zu erhalten.

In-Place-MVU wird nur mit Amazon DocumentDB 3.6 oder 4.0 als Quelle und Version 5.0 als Ziel unterstützt. Es wird nicht für Amazon DocumentDB Global Clusters oder Elastic Clusters oder mit DocumentDB 4.0 als Ziel unterstützt.

Amazon DocumentDB lässt sich in Amazon SageMaker Canvas integrieren, sodass es einfach ist, Modelle für Machine Learning (ML) zu erstellen und Basismodelle mithilfe der in Amazon DocumentDB gespeicherten Daten anzupassen, ohne eine einzige Codezeile schreiben zu müssen. Sie müssen keine benutzerdefinierten Daten und ML-Pipelines mehr zwischen Amazon DocumentDB und SageMaker Canvas entwickeln. Sie können SageMaker Canvas von der Amazon-DocumentDB-Konsole aus starten und vorhandene Amazon-DocumentDB-Datenbanken als Datenquelle hinzufügen, um mit der Erstellung Ihrer Machine-Learning-Modelle zu beginnen. Sie können Ihre Daten in DocumentDB in SageMaker Canvas verwenden, um Modelle zu erstellen, um Kundenabwanderung vorherzusagen, Betrug zu erkennen, Wartungsausfälle vorherzusagen, Finanzkennzahlen und Verkäufe zu prognostizieren, Inventar zu optimieren, Inhalte zusammenzufassen und Inhalte zu generieren.

Die Vektorsuche ist eine Methode, die beim Machine Learning (ML) verwendet wird, um ähnliche Datenpunkte wie einen bestimmten Datenpunkt zu finden, indem ihre Vektordarstellungen mithilfe von Entfernungs- oder Ähnlichkeitsmetriken verglichen werden. Je näher die beiden Vektoren im Vektorraum liegen, desto ähnlicher werden die zugrundeliegenden Elemente angesehen. Diese Technik hilft dabei, die Bedeutung oder Semantik der Daten zu erfassen. Dieser Ansatz ist in verschiedenen Anwendungen nützlich, z. B. in Empfehlungssystemen, der Verarbeitung natürlicher Sprache und der Bilderkennung.

Amazon SageMaker Canvas bietet eine Schnittstelle ohne Code zum Erstellen von Machine-Learning-Modellen unter Verwendung von Daten aus verschiedenen Datenquellen, einschließlich Amazon DocumentDB. Ihre Nutzung von SageMaker Canvas und die daraus resultierenden I/Os, wenn SageMaker Canvas Daten aus Ihrer Amazon-DocumentDB-Instance liest, werden Ihnen in Rechnung gestellt. Für die Verwendung von DocumentDB als Datenquelle in Amazon SageMaker Canvas fallen keine zusätzlichen Gebühren an. Besuchen Sie die Preisseite von Amazon DocumentDB und die Preisseite von SageMaker Canvas, um mehr zu erfahren.

Die Vektorsuche für Amazon DocumentDB kombiniert die Flexibilität und die umfassenden Abfragefunktionen einer JSON-basierten Dokumentendatenbank mit der Leistungsfähigkeit der Vektorsuche. Sie können Ihre vorhandenen Amazon-DocumentDB-Daten oder eine flexible Dokumentendatenstruktur verwenden, um Anwendungsfälle für Machine Learning und generative KI zu erstellen, z. B. semantische Suchanfragen, Produktempfehlungen, Personalisierung, Chatbots, Betrugserkennung und Anomalieerkennung. Weitere Informationen finden Sie in der Dokumentation zur Vektorsuche in Amazon DocumentDB.

Die Vektorsuche für Amazon DocumentDB ist in instancebasierten Clustern von Amazon DocumentDB 5.0 verfügbar.

Die Vektorsuche für Amazon DocumentDB ermöglicht die Verwendung der semantischen Suche, sodass Sie die Bedeutung, den Kontext und die Absicht Ihrer Daten erfassen können. Die Stichwortsuche findet das Dokument anhand des tatsächlichen Textes oder vordefinierter Synonymzuordnungen. In einer herkömmlichen E-Commerce-Anwendung könnte ein rotes Kleid beispielsweise Produkte zurückgeben, deren Beschreibung die Wörter „Rot“ und „Kleid“ enthält. Die semantische Suche ruft Ergebnisse mit Kleidern in verschiedenen Rottönen ab, was die Benutzererfahrung verbessern kann.  

Für die Verwendung der Vektorsuche für Amazon DocumentDB fallen keine zusätzlichen Kosten an. Wenn Sie Vektoren in Amazon DocumentDB speichern, indexieren und suchen, fallen die üblichen Rechen-, I/O-, Speicher- und Sicherungsgebühren an. Weitere Informationen finden Sie auf der Seite mit den Amazon DocumentDB-Preisen.

Amazon DocumentDB lässt sich in Amazon SageMaker Canvas integrieren, sodass es einfach ist, generative Anwendungen für künstliche Intelligenz (KI) und Machine Learning (ML) mithilfe der in Amazon DocumentDB gespeicherten Daten zu erstellen. Sie müssen keine benutzerdefinierten Daten und ML-Pipelines mehr zwischen Amazon DocumentDB und SageMaker Canvas entwickeln. Durch die Integration in die Konsole entfällt der undifferenzierte Aufwand für die Verbindung und den Zugriff auf Daten, um die ML-Entwicklung mit einer Low-Code-No-Code-Erfahrung (LCNC) zu beschleunigen. Sie können SageMaker Canvas von der Amazon-DocumentDB-Konsole aus starten und bestehende Amazon-DocumentDB-Datenbanken als Datenquelle hinzufügen.

Diese Null-ETL-Integration mit Amazon OpenSearch Service reduziert die betriebliche Komplexität beim Extrahieren, Transformieren und Laden von Daten aus einer Amazon-DocumentDB-Sammlung in einen von Amazon OpenSearch verwalteten Cluster oder in eine Serverless-Sammlung. Mit dieser Integration müssen Sie keine Datenpipelines mehr erstellen oder verwalten oder Daten transformieren.

Wenn Sie MongoDB-APIs verwenden möchten, sollten Sie die nativen Datenbankfunktionen in Amazon DocumentDB nutzen, um eine Vektorsuche in Ihren Dokumentendaten durchzuführen. Die Null-ETL-Integration von Amazon DocumentDB mit Amazon OpenSearch Service eignet sich gut für die sammlungsübergreifende Suche sowie für die Speicherung und Indizierung von Vektoren mit mehr als 2 000 Dimensionen.

Die Null-ETL-Integration von Amazon DocumentDB mit Amazon OpenSearch Service verwendet Amazon OpenSearch Ingestion, um Betriebsdaten nahtlos von Amazon DocumentDB zu Amazon OpenSearch Service zu übertragen. Zu Beginn aktivieren Sie die Change-Stream-Funktionalität in der Amazon-DocumentDB-Sammlung, die repliziert werden muss. Das Null-ETL-Integrations-Feature richtet eine Pipeline von Amazon OpenSearch Ingestion in Ihrem Konto ein, die die Daten automatisch in einen von Amazon OpenSearch Service verwalteten Cluster oder eine Serverless-Sammlung repliziert.

Amazon OpenSearch Ingestion versteht automatisch das Format der Daten in Amazon-DocumentDB-Sammlungen und ordnet die Daten Amazon OpenSearch Service zu, um die leistungsfähigsten Suchergebnisse zu erzielen. Sie können Daten aus mehreren Amazon-DocumentDB-Sammlungen über mehrere Pipelines in einen von Amazon OpenSearch verwalteten Cluster oder eine Serverless-Sammlung synchronisieren, um ganzheitliche Einblicke in mehrere Anwendungen zu erhalten. Optional können Sie benutzerdefinierte Datenprozessoren angeben, wenn Sie die Aufnahmekonfiguration in Amazon OpenSearch Service definieren. Nachfolgende Aktualisierungen der DocumentDB-Sammlungen werden ebenfalls ohne manuelles Eingreifen in Amazon OpenSearch Service repliziert.

Diese Null-ETL-Integrazion nutzt die nativen Datentransformationsfunktionen der Pipelines von Amazon OpenSearch Ingestion, um die Daten zu aggregieren und zu filtern, während sie übertragen werden.

Sie können auch eine benutzerdefinierte Transformationslogik schreiben, wenn Sie maßgeschneiderte Transformationsfunktionen wünschen, und Amazon OpenSearch Ingestion verwaltet den Transformationsprozess. Wenn Sie alternativ ganze Daten ohne Anpassung von der Quelle zur Sink verschieben möchten, bietet Amazon OpenSearch Ingestion sofort einsatzbereite Vorlagen, sodass Sie die Integrationen mit nur wenigen Tastenklicks durchführen können.

Um sicherzustellen, dass Amazon OpenSearch Ingestion über die erforderlichen Berechtigungen zum Replizieren von Daten aus Amazon DocumentDB verfügt, erstellt das Null-ETL-Integrations-Feature eine IAM-Rolle mit den erforderlichen Berechtigungen, um Daten aus der Amazon-DocumentDB-Sammlung zu lesen und in eine Amazon-OpenSearch-Domain oder -Sammlung zu schreiben. Diese Rolle wird dann von den Amazon-OpenSearch-Ingestion-Pipelines übernommen, um sicherzustellen, dass beim Verschieben der Daten von der Quelle zum Ziel immer die richtige Sicherheitslage eingehalten wird.

Sie können alle Metriken zu Ihrer Null-ETL-Integration mit Amazon DocumentDB in den Konsolen-Dashboards von Amazon DocumentDB und OpenSearch Ingestion Pipeline einsehen. Sie können auch Echtzeitprotokolle in Amazon CloudWatch abfragen und mithilfe von Amazon CloudWatch benutzerdefinierte Warnmeldungen einrichten, die ausgelöst werden, wenn benutzerdefinierte Schwellenwerte überschritten werden.