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

Beim Schreiben in den Speicher persistiert HAQM 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 HAQM DocumentDB-Schreibvorgänge typischerweise schneller als bei gewöhnlichen Datenbanken. HAQM-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 HAQM-DocumentDB-Preisseite.

Ja, Sie können HAQM DocumentDB mit der 1-monatigen kostenlosen Testversion kostenlos testen. Wenn Sie HAQM 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.

HAQM 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 HAQM-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 HAQM DocumentDB I/O-Optimized.

Sie können Ihre vorhandenen Datenbank-Cluster einmal alle 30 Tage auf HAQM DocumentDB I/O-Optimized umstellen. Sie können jederzeit zu den Standardspeicherkonfigurationen von HAQM 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. HAQM 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 HAQM DocumentDB I/O-Optimized.

Elastische Cluster von HAQM 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 HAQM 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 HAQM 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 HAQM 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 HAQM 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 HAQM 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 HAQM-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 HAQM-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 HAQM 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 HAQM DocumentDB wiederzuverwenden.

Es gibt ein unteres Speicherplatzlimit von 10 GB. Basierend auf der Nutzung Ihres Clusters wächst Ihr HAQM-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 HAQM 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.

HAQM DocumentDB wird in zwei Dimensionen skaliert: Speicher und Datenverarbeitung. Der Speicher von HAQM DocumentDB skaliert automatisch von 10 GB auf 128 TiB in instanzbasierten Clustern und bis zu 4 PiB für HAQM DocumentDB Elastic Clusters. Die Rechenkapazität von HAQM 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 HAQM DocumentDB-Clustern sind automatisierte Sicherungen immer aktiviert. Die einfache Datenbank-Backup-Funktion von HAQM 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.

HAQM 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 HAQM-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. HAQM 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. HAQM 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 HAQM DocumentDB-Snapshots zugreifen.

Ja. Sie können verschlüsselte HAQM-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, HAQM 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. HAQM DocumentDB behält diesen letzten vom Benutzer erstellten Snapshot zusammen mit allen anderen manuell erstellten Snapshots bei, nachdem der Cluster gelöscht wurde.

HAQM 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. HAQM 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 HAQM DocumentDB repariert sich außerdem selbst. Datenblocks und Datenträger werden laufend auf Fehler untersucht und automatisch repariert.

Im Gegensatz zu anderen Datenbanken muss HAQM 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. HAQM 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.

HAQM 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 HAQM DocumentDB-Replikate sichtbar.

• Feature: HAQM-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 HAQM 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 HAQM 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 HAQM DocumentDB die Replica mit der niedrigeren Priorität.

A: HAQM 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 HAQM DocumentDB-Replicas hinzufügen. HAQM DocumentDB-Replicas nutzen denselben zugrunde liegenden Speicher wie die primäre Instance. Jedes HAQM 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 HAQM DocumentDB wird sie bei einem Ausfall einer Instance automatisch in die Failover-Primärauswahl einbeziehen.

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

• Wenn Sie eine HAQM DocumentDB-Replica in derselben oder einer anderen Availability Zone haben, wechselt HAQM 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 HAQM DocumentDB-Replica (d. h. über ein einzelnes Instance-Cluster), versucht HAQM 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: HAQM DocumentDB erkennt Probleme bei Ihrer primären Instance automatisch und beginnt mit dem Routen Ihres Schreib-/Lesedatenverkehrs zu einer HAQM DocumentDB-Replica-Instance. Dieses Failover ist im Durchschnitt innerhalb von 30 Sekunden abgeschlossen. Außerdem wird der Lesedatenverkehr Ihrer HAQM DocumentDB-Replica-Instances kurz unterbrochen.

A: Da HAQM 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 HAQM-DocumentDB-Cluster müssen in einer VPC erstellt werden. Mit HAQM 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 HAQM DocumentDB-Cluster.

HAQM 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 HAQM DocumentDB.

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

Ja. HAQM 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 HAQM 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 HAQM DocumentDB finden Sie unter Verschlüsselung von HAQM-DocumentDB-Daten im Ruhezustand.

Derzeit wird die Verschlüsselung eines bestehenden unverschlüsselten HAQM DocumentDB-Clusters nicht unterstützt. Zum Verwenden der HAQM 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.

HAQM 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. HAQM 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 HAQM DocumentDB 3.6- oder 4.0-Cluster mithilfe der AWS-Konsole, des Software Development Kit (SDK) oder der Befehlszeilenschnittstelle (CLI) auf HAQM 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 HAQM 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 HAQM 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 HAQM DocumentDB verwenden, um Ihre Clusterdaten zu Testzwecken zu klonen. Abhängig von der Komplexität Ihrer HAQM DocumentDB-Implementierung können Sie sich an unseren Datenbanklösungsarchitekten wenden, um zusätzliche Hilfe zu erhalten.

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

HAQM DocumentDB lässt sich in HAQM SageMaker Canvas integrieren, sodass es einfach ist, Modelle für Machine Learning (ML) zu erstellen und Basismodelle mithilfe der in HAQM DocumentDB gespeicherten Daten anzupassen, ohne eine einzige Codezeile schreiben zu müssen. Sie müssen keine benutzerdefinierten Daten und ML-Pipelines mehr zwischen HAQM DocumentDB und SageMaker Canvas entwickeln. Sie können SageMaker Canvas von der HAQM-DocumentDB-Konsole aus starten und vorhandene HAQM-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.

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

Die Vektorsuche für HAQM DocumentDB kombiniert die Flexibilität und die umfassenden Abfragefunktionen einer JSON-basierten Dokumentendatenbank mit der Leistungsfähigkeit der Vektorsuche. Sie können Ihre vorhandenen HAQM-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 HAQM DocumentDB.

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

Die Vektorsuche für HAQM 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 HAQM DocumentDB fallen keine zusätzlichen Kosten an. Wenn Sie Vektoren in HAQM 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 HAQM DocumentDB-Preisen.

HAQM DocumentDB lässt sich in HAQM SageMaker Canvas integrieren, sodass es einfach ist, generative Anwendungen für künstliche Intelligenz (KI) und Machine Learning (ML) mithilfe der in HAQM DocumentDB gespeicherten Daten zu erstellen. Sie müssen keine benutzerdefinierten Daten und ML-Pipelines mehr zwischen HAQM 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 HAQM-DocumentDB-Konsole aus starten und bestehende HAQM-DocumentDB-Datenbanken als Datenquelle hinzufügen.

Diese Null-ETL-Integration mit HAQM OpenSearch Service reduziert die betriebliche Komplexität beim Extrahieren, Transformieren und Laden von Daten aus einer HAQM-DocumentDB-Sammlung in einen von HAQM 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 HAQM DocumentDB nutzen, um eine Vektorsuche in Ihren Dokumentendaten durchzuführen. Die Null-ETL-Integration von HAQM DocumentDB mit HAQM 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 HAQM DocumentDB mit HAQM OpenSearch Service verwendet HAQM OpenSearch Ingestion, um Betriebsdaten nahtlos von HAQM DocumentDB zu HAQM OpenSearch Service zu übertragen. Zu Beginn aktivieren Sie die Change-Stream-Funktionalität in der HAQM-DocumentDB-Sammlung, die repliziert werden muss. Das Null-ETL-Integrations-Feature richtet eine Pipeline von HAQM OpenSearch Ingestion in Ihrem Konto ein, die die Daten automatisch in einen von HAQM OpenSearch Service verwalteten Cluster oder eine Serverless-Sammlung repliziert.

HAQM OpenSearch Ingestion versteht automatisch das Format der Daten in HAQM-DocumentDB-Sammlungen und ordnet die Daten HAQM OpenSearch Service zu, um die leistungsfähigsten Suchergebnisse zu erzielen. Sie können Daten aus mehreren HAQM-DocumentDB-Sammlungen über mehrere Pipelines in einen von HAQM 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 HAQM OpenSearch Service definieren. Nachfolgende Aktualisierungen der DocumentDB-Sammlungen werden ebenfalls ohne manuelles Eingreifen in HAQM OpenSearch Service repliziert.

Diese Null-ETL-Integrazion nutzt die nativen Datentransformationsfunktionen der Pipelines von HAQM 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 HAQM OpenSearch Ingestion verwaltet den Transformationsprozess. Wenn Sie alternativ ganze Daten ohne Anpassung von der Quelle zur Sink verschieben möchten, bietet HAQM OpenSearch Ingestion sofort einsatzbereite Vorlagen, sodass Sie die Integrationen mit nur wenigen Tastenklicks durchführen können.

Um sicherzustellen, dass HAQM OpenSearch Ingestion über die erforderlichen Berechtigungen zum Replizieren von Daten aus HAQM DocumentDB verfügt, erstellt das Null-ETL-Integrations-Feature eine IAM-Rolle mit den erforderlichen Berechtigungen, um Daten aus der HAQM-DocumentDB-Sammlung zu lesen und in eine HAQM-OpenSearch-Domain oder -Sammlung zu schreiben. Diese Rolle wird dann von den HAQM-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 HAQM DocumentDB in den Konsolen-Dashboards von HAQM DocumentDB und OpenSearch Ingestion Pipeline einsehen. Sie können auch Echtzeitprotokolle in HAQM CloudWatch abfragen und mithilfe von HAQM CloudWatch benutzerdefinierte Warnmeldungen einrichten, die ausgelöst werden, wenn benutzerdefinierte Schwellenwerte überschritten werden.