

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Was ist Amazon DocumentDB (mit MongoDB-Kompatibilität)
<a name="what-is"></a>

Amazon DocumentDB (mit MongoDB-Kompatibilität) ist ein schneller, zuverlässiger und vollständig verwalteter Datenbankservice. Amazon DocumentDB macht es einfach, MongoDB-kompatible Datenbanken in der Cloud einzurichten, zu betreiben und zu skalieren. Mit Amazon DocumentDB können Sie denselben Anwendungscode ausführen und dieselben Treiber und Tools verwenden, die Sie mit MongoDB verwenden.

Bevor Sie Amazon DocumentDB verwenden, sollten Sie sich mit den unter beschriebenen Konzepten und Funktionen vertraut machen. [Funktionsweise](how-it-works.md) Anschließend führen Sie die Schritte unter [Leitfaden für die ersten Schritte](get-started-guide.md) aus.

**Topics**
+ [-Übersicht](#overview)
+ [Cluster](#what-is-db-clusters)
+ [Instances](#what-is-db-instances)
+ [Regionen und AZs](#what-is-regions-and-azs)
+ [Preisgestaltung](#docdb-pricing)
+ [Überwachen](#what-is-monitoring)
+ [Schnittstellen](#what-is-interfaces)
+ [Als nächstes](#what-is-next)
+ [Funktionsweise](how-it-works.md)
+ [Was ist eine Dokumentendatenbank?](what-is-document-db.md)

## Überblick über Amazon DocumentDB
<a name="overview"></a>

Im Folgenden sind einige wichtige Funktionen von Amazon DocumentDB aufgeführt:
+ Amazon DocumentDB unterstützt zwei Arten von Clustern: instanzbasierte Cluster und elastische Cluster. Elastic Cluster unterstützen Workloads mit einer Speicherkapazität von Millionen reads/writes pro Sekunde und Petabyte. Weitere Informationen zu elastischen Clustern finden Sie unter. [Verwendung elastischer Amazon DocumentDB-Cluster](docdb-using-elastic-clusters.md) Der folgende Inhalt bezieht sich auf Amazon DocumentDB DocumentDB-Instance-basierte Cluster.
+ Amazon DocumentDB vergrößert automatisch die Größe Ihres Speichervolumens, wenn Ihr Datenbankspeicherbedarf steigt. Ihr Speichervolumen wächst in Schritten von 10 GB bis zu einem Maximum von 128 TiB. Sie müssen in Hinblick auf zukünftiges Wachstum keinen zusätzlichen Speicher für Ihren Cluster bereitstellen.
+ Mit Amazon DocumentDB können Sie den Lesedurchsatz erhöhen, um umfangreiche Anwendungsanfragen zu unterstützen, indem Sie bis zu 15 Replikat-Instances erstellen. Amazon DocumentDB DocumentDB-Replikate nutzen denselben zugrunde liegenden Speicher, wodurch die Kosten gesenkt und Schreibvorgänge an den Replikatknoten vermieden werden. Diese Funktion setzt mehr Rechenleistung für die Bearbeitung von Leseanforderungen frei und reduziert die Replikatverzögerung — oft bis auf einstellige Millisekunden. Sie können Replikate unabhängig von der Größe des Speichervolumens innerhalb von Minuten hinzufügen. Amazon DocumentDB bietet auch einen Leser-Endpunkt, sodass die Anwendung eine Verbindung herstellen kann, ohne dass Replikate nachverfolgt werden müssen, wenn sie hinzugefügt und entfernt werden.
+ Mit Amazon DocumentDB können Sie die Rechen- und Speicherressourcen für jede Ihrer Instances nach oben oder unten skalieren. Skalierungsvorgänge bei der Datenverarbeitung dauern in der Regel nur wenige Minuten.
+ Amazon DocumentDB wird in Amazon Virtual Private Cloud (Amazon VPC) ausgeführt, sodass Sie Ihre Datenbank in Ihrem eigenen virtuellen Netzwerk isolieren können. Sie können auch Firewalleinstellungen so konfigurieren, dass der Netzwerkzugriff auf Ihren Cluster gesteuert wird.
+ Amazon DocumentDB überwacht kontinuierlich den Zustand Ihres Clusters. Bei einem Instance-Ausfall startet Amazon DocumentDB die Instance und die zugehörigen Prozesse automatisch neu. Amazon DocumentDB erfordert keine Wiederholung von Datenbank-Redo-Logs nach einem Absturz, wodurch die Neustartzeiten erheblich reduziert werden. Amazon DocumentDB isoliert außerdem den Datenbank-Cache vom Datenbankprozess, sodass der Cache einen Instance-Neustart übersteht.
+ Bei einem Instance-Ausfall automatisiert Amazon DocumentDB den Failover auf eines von bis zu 15 Amazon DocumentDB DocumentDB-Replikaten, die Sie in anderen Availability Zones erstellen. Wenn keine Replikate bereitgestellt wurden und ein Fehler auftritt, versucht Amazon DocumentDB, automatisch eine neue Amazon DocumentDB DocumentDB-Instance zu erstellen.
+ Die Backup-Funktion in Amazon DocumentDB ermöglicht die point-in-time Wiederherstellung Ihres Clusters. Diese Funktion ermöglicht Ihnen, Ihren Cluster zu jeder Sekunde innerhalb der Aufbewahrungsfrist bis zu den letzten 5 Minuten wiederherzustellen. Sie können den Aufbewahrungszeitraum für automatische Backups auf maximal 35 Tage festlegen. Automatisierte Backups werden im Amazon Simple Storage Service (Amazon S3) gespeichert, der für eine Haltbarkeit von 99,999999999% ausgelegt ist. Amazon DocumentDB-Backups sind automatisch, inkrementell und kontinuierlich und haben keine Auswirkungen auf die Leistung Ihres Clusters.
+ Mit Amazon DocumentDB können Sie Ihre Datenbanken mit Schlüsseln verschlüsseln, die Sie über AWS Key Management Service ()AWS KMS erstellen und kontrollieren. In einem Datenbank-Cluster, der mit Amazon DocumentDB DocumentDB-Verschlüsselung ausgeführt wird, werden Daten, die im Ruhezustand im zugrunde liegenden Speicher gespeichert sind, verschlüsselt. Die automatischen Sicherungen, Snapshots und Replicas im gleichen Cluster werden ebenfalls verschlüsselt.
+ Amazon DocumentDB ist im Rahmen des Federal Risk and Authorization Management Program (FedRAMP) autorisiert. Es verfügt über eine FedRAMP High-Autorisierung für AWS GovCloud (US-) Regionen und eine FedRAMP Moderate-Autorisierung für US-Regionen. AWS East/West Einzelheiten zu den Compliance-Maßnahmen AWS und den Bemühungen zur Einhaltung der Vorschriften finden Sie unter [AWS Services im Umfang](https://aws.amazon.com/compliance/services-in-scope/FedRAMP/) nach Compliance-Programmen.

Wenn Sie mit AWS Services noch nicht vertraut sind, finden Sie in den folgenden Ressourcen weitere Informationen:
+ AWS bietet Dienste für Datenverarbeitung, Datenbanken, Speicherung, Analyse und andere Funktionen. Eine Übersicht über alle AWS Services finden Sie unter [Cloud Computing with Amazon Web Services](https://aws.amazon.com/what-is-aws/).
+ AWS bietet eine Reihe von Datenbankdiensten. Hinweise dazu, welcher Dienst für Ihre Umgebung am besten geeignet ist, finden Sie unter [Datenbanken auf AWS](https://aws.amazon.com/products/databases/).

## Cluster
<a name="what-is-db-clusters"></a>

Ein *Cluster* besteht aus 0 bis 16 Instances und einem Cluster-Speichervolume, das die Daten für diese Instances verwaltet. Alle Schreibvorgänge erfolgen über die primäre Instance. Alle Instances (primäre und Replicas) unterstützen Lesevorgänge. Die Daten des Clusters werden im Cluster-Volume gespeichert, mit Kopien in drei verschiedenen Availability Zones.

![\[Amazon DocumentDB-Cluster, der die primäre Instance in Availability Zone 1 enthält und auf das Cluster-Volume für Replikate in den Zonen 2 und 3 schreibt.\]](http://docs.aws.amazon.com/de_de/documentdb/latest/developerguide/images/how-it-works-01c.png)


Instanzbasierte Amazon DocumentDB 5.0-Cluster unterstützen zwei Speicherkonfigurationen für einen Datenbankcluster: Amazon DocumentDB Standard und Amazon DocumentDB I/O-optimiert. Weitere Informationen finden Sie unter [Amazon DocumentDB-Cluster-Speicherkonfigurationen](db-cluster-storage-configs.md).

## Instances
<a name="what-is-db-instances"></a>

Eine Amazon DocumentDB DocumentDB-Instance ist eine isolierte Datenbankumgebung in der Cloud. Eine Instance kann mehrere von Benutzern erstellte Datenbanken enthalten. Sie können eine Instance mit dem AWS-Managementkonsole oder dem AWS CLI erstellen und ändern.

Die Rechenleistung und die Speicherkapazität einer Instanz werden durch ihre *Instanzklasse* bestimmt. Sie können die Instance auswählen, die Ihren Anforderungen am besten entspricht. Wenn sich Ihre Anforderungen im Laufe der Zeit ändern, können Sie eine andere Instance-Klasse wählen. Spezifikationen für DB-Instance-Klassen finden Sie unter [Spezifikationen der Instanzklasse](db-instance-classes.md#db-instance-class-specs)

Amazon DocumentDB DocumentDB-Instances werden nur in der Amazon VPC-Umgebung ausgeführt. Amazon VPC gibt Ihnen die Kontrolle über Ihre virtuelle Netzwerkumgebung: Sie können Ihren eigenen IP-Adressbereich wählen, Subnetze erstellen und Routing- und Zugriffskontrolllisten konfigurieren ()ACLs.

Bevor Sie Amazon DocumentDB DocumentDB-Instances erstellen können, müssen Sie einen Cluster erstellen, der die Instances enthält.

Nicht alle Instance-Klassen werden in allen Regionen unterstützt. Die folgende Tabelle gibt an, welche Instance-Klassen von in den jeweiligen Regionen unterstützt werden.

**Anmerkung**  
Eine vollständige Liste der Instance-Typen, die von Amazon DocumentDB in jeder Instance-Klasse unterstützt werden, finden Sie unter[Spezifikationen der Instanzklasse](db-instance-classes.md#db-instance-class-specs).


**Unterstützte Instance-Klassen nach Region**  

|  | Instance-Klassen | Region | R8G | R6GD | R6G | R5 | R4 | T4 G | T3 | Serverless | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
| USA Ost (Ohio) | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt | 
| USA Ost (Nord-Virginia) | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt | 
| USA West (Oregon) | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt | 
| Afrika (Kapstadt) |  |  | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| Südamerika (São Paulo) |  | Unterstützt | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| Asien-Pazifik (Hongkong) |  |  | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| Asien-Pazifik (Hyderabad) |  |  | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| Asien-Pazifik (Malaysia) |  |  | Unterstützt |  |  | Unterstützt | Unterstützt |  | 
| Asien-Pazifik (Mumbai) | Unterstützt | Unterstützt | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| Asien-Pazifik (Osaka) |  | Unterstützt | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt |  | 
| Asien-Pazifik (Seoul) | Unterstützt | Unterstützt | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| Asien-Pazifik (Sydney) | Unterstützt | Unterstützt | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| Asien-Pazifik (Jakarta) | Unterstützt | Unterstützt | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt |  | 
| Asien-Pazifik (Melbourne) |  |  | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt |  | 
| Asien-Pazifik (Singapur) | Unterstützt | Unterstützt | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| Asien-Pazifik (Thailand) |  |  | Unterstützt |  |  | Unterstützt | Unterstützt |  | 
| Asien-Pazifik (Tokio) | Unterstützt | Unterstützt | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| Kanada (Zentral) |  | Unterstützt | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| Europa (Frankfurt) | Unterstützt | Unterstützt | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| Europa (Zürich) |  | Unterstützt | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt |  | 
| Europa (Irland) | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt | Unterstützt | 
| Europa (London) |  | Unterstützt | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| Europa (Milan) |  |  | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| Europa (Paris) |  | Unterstützt | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| Europa (Spain) | Unterstützt | Unterstützt | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| Europa (Stockholm) | Unterstützt | Unterstützt | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt |  | 
| Mexiko (Zentral) |  |  | Unterstützt |  |  | Unterstützt | Unterstützt |  | 
| Naher Osten (VAE) |  |  | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| China (Peking) |  | Unterstützt | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| China (Ningxia) |  |  | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| Israel (Tel Aviv) |  |  | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| AWS GovCloud (US-West) | Unterstützt | Unterstützt | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 
| AWS GovCloud (US-Ost) |  | Unterstützt | Unterstützt | Unterstützt |  | Unterstützt | Unterstützt | Unterstützt | 

## Regionen und Availability Zones
<a name="what-is-regions-and-azs"></a>

Regionen und Availability Zones definieren die physischen Standorte und Instances Ihres Clusters.

### Regionen
<a name="what-is-regions"></a>

AWS Cloud-Computing-Ressourcen sind in hochverfügbaren Rechenzentren in verschiedenen Regionen der Welt (z. B. Nordamerika, Europa oder Asien) untergebracht. Jeder Rechenzentrumsstandort wird als *Region* bezeichnet.

Jede AWS Region ist so konzipiert, dass sie vollständig von den anderen AWS Regionen isoliert ist. Innerhalb jeder gibt es mehrere Availability Zones (Verfügbarkeitszonen). Durch das Starten Ihrer Knoten in verschiedenen Availability Zones können Sie eine größtmögliche Fehlertoleranz zu erreichen. Das folgende Diagramm zeigt einen allgemeinen Überblick über die Funktionsweise von AWS Regionen und Availability Zones.

![\[Amazon DocumentDB DocumentDB-Übersicht über AWS Regionen und Availability Zones auf hoher Ebene.\]](http://docs.aws.amazon.com/de_de/documentdb/latest/developerguide/images/docdb-regions-and-azs.png)


### Availability Zones
<a name="what-is-availability-zones"></a>

Jede AWS Region enthält mehrere unterschiedliche Standorte, die als *Availability Zones* bezeichnet werden. Jede Availability Zone wurde so konzipiert, dass sie von Fehlern in anderen Availability Zones isoliert ist und eine kostengünstige Netzwerkverbindung mit geringer Latenz zu anderen Availability Zones in derselben Region bereitstellt. Indem Instances für einen bestimmten Cluster in mehreren Availability Zones gestartet werden, können Sie Ihre Anwendungen vor dem unwahrscheinlichen Fall des Fehlschlagens einer Availability Zone schützen.

Die Amazon DocumentDB DocumentDB-Architektur trennt Speicher und Datenverarbeitung. Für die Speicherebene repliziert Amazon DocumentDB sechs Kopien Ihrer Daten in drei AWS Availability Zones. Wenn Sie beispielsweise einen Amazon DocumentDB-Cluster in einer Region starten, die nur zwei Availability Zones unterstützt, wird Ihr Datenspeicher auf sechs Arten in drei Availability Zones repliziert, aber Ihre Compute-Instances sind nur in zwei Availability Zones verfügbar.

 In der folgenden Tabelle ist die Anzahl der Availability Zones aufgeführt, die Sie in einer bestimmten Umgebung verwenden können AWS-Region , um Recheninstanzen für Ihren Cluster bereitzustellen.


| Name der Region | Region | Availability Zones (Compute) | 
| --- | --- | --- | 
| USA Ost (Ohio) | `us-east-2` | 3 | 
| USA Ost (Nord-Virginia) | `us-east-1` | 6 | 
| USA West (Oregon) | `us-west-2` | 4 | 
| Afrika (Kapstadt) | `af-south-1` | 3 | 
| Südamerika (São Paulo) | `sa-east-1` | 3 | 
| Asien-Pazifik (Hongkong) | `ap-east-1` | 3 | 
| Asien-Pazifik (Hyderabad) | `ap-south-2` | 3 | 
| Asien-Pazifik (Malaysia) | `ap-southeast-5` | 3 | 
| Asien-Pazifik (Mumbai) | `ap-south-1` | 3 | 
| Asien-Pazifik (Osaka) | `ap-northeast-3` | 3 | 
| Asien-Pazifik (Seoul) | `ap-northeast-2` | 4 | 
| Asien-Pazifik (Singapur) | `ap-southeast-1` | 3 | 
| Asien-Pazifik (Sydney) | `ap-southeast-2` | 3 | 
| Asien-Pazifik (Jakarta) | `ap-southeast-3` | 3 | 
| Asien-Pazifik (Melbourne) | `ap-southeast-4` | 3 | 
| Asien-Pazifik (Thailand) | `ap-southeast-7` | 3 | 
| Asien-Pazifik (Tokio) | `ap-northeast-1` | 3 | 
| Kanada (Zentral) | `ca-central-1` | 3 | 
| Region China (Peking) | `cn-north-1` | 3 | 
| China (Ningxia) | `cn-northwest-1` | 3 | 
| Europa (Frankfurt) | `eu-central-1` | 3 | 
| Europa (Zürich) | `eu-central-2` | 3 | 
| Europa (Irland) | `eu-west-1` | 3 | 
| Europa (London) | `eu-west-2` | 3 | 
| Europa (Milan) | `eu-south-1` | 3 | 
| Europa (Paris) | `eu-west-3` | 3 | 
| Europa (Spain) | `eu-south-2` | 3 | 
| Europa (Stockholm) | `eu-north-1` | 3 | 
| Mexiko (Zentral) | `mx-central-1` | 3 | 
| Naher Osten (VAE) | `me-central-1` | 3 | 
| Israel (Tel Aviv) | `il-central-1` | 3 | 
| AWS GovCloud (USA West) | `us-gov-west-1` | 3 | 
| AWS GovCloud (US-Ost) | `us-gov-east-1` | 3 | 

## Amazon DocumentDB — Preise
<a name="docdb-pricing"></a>

Amazon DocumentDB-Cluster werden auf der Grundlage der folgenden Komponenten abgerechnet: 
+ **Instance-Stunden (pro Stunde)** — Basierend auf der Instance-Klasse der Instance (z. B.). `db.r5.xlarge` Die Preise werden auf Stundenbasis aufgeführt, aber Rechnungen werden jetzt auf die Sekunde genau kalkuliert und zeigen die Zeiten im Dezimalformat an. Die Nutzung von Amazon DocumentDB wird in Sekundenschritten mit einer Mindestdauer von 10 Minuten abgerechnet. Weitere Informationen finden Sie unter [Instanzklassen verwalten](db-instance-classes.md). 
+ **I/O-Anfragen (pro 1 Million Anfragen pro Monat)** — Gesamtzahl der I/O Speicheranforderungen, die Sie in einem Abrechnungszeitraum stellen.
+ **Backup-Speicher (pro GiB pro Monat)** — Backup-Speicher ist der Speicher, der automatisierten Datenbank-Backups und allen aktiven Datenbank-Snapshots, die Sie erstellt haben, zugeordnet ist. Wenn Sie die Aufbewahrungszeit Ihrer Backups erhöhen oder zusätzliche Datenbank-Snapshots erstellen, belegt Ihre Datenbank dementsprechend mehr Backup-Speicher. Der Backup-Speicher wird in GB-Monaten abgerechnet, die sekundengenaue Abrechnung wird hier nicht angewandt. Weitere Informationen finden Sie unter [Sichern und Wiederherstellen in Amazon DocumentDB](backup_restore.md). 
+ **Datenübertragung (pro GB)** — Datenübertragung innerhalb und aus Ihrer Instance vom oder ins Internet oder in andere AWS Regionen.

Weitere Informationen finden Sie unter [Amazon DocumentDB DocumentDB-Preise](https://aws.amazon.com/documentdb/pricing/).

### Kostenlose Testversion
<a name="free-trial"></a>

Sie können Amazon DocumentDB mit der einmonatigen kostenlosen Testversion kostenlos testen. Weitere Informationen finden Sie unter Kostenlose Testversion in den [Preisen von Amazon DocumentDB](https://aws.amazon.com/documentdb/pricing/) oder in den häufig gestellten Fragen zur [kostenlosen Amazon DocumentDB-Testversion](https://aws.amazon.com/documentdb/free-trial/).

## Überwachen
<a name="what-is-monitoring"></a>

Es gibt verschiedene Möglichkeiten, die Leistung und den Zustand einer Instance zu überwachen. Sie können den kostenlosen CloudWatch Amazon-Service verwenden, um die Leistung und den Zustand einer Instance zu überwachen. Leistungsdiagramme finden Sie in der Amazon DocumentDB DocumentDB-Konsole. Sie können Amazon DocumentDB DocumentDB-Ereignisse abonnieren, um benachrichtigt zu werden, wenn Änderungen an einer Instance, einem Snapshot, einer Parametergruppe oder einer Sicherheitsgruppe auftreten.

Weitere Informationen finden Sie hier:
+ [Überwachen von Amazon DocumentDB mit CloudWatch](cloud_watch.md)
+ [Protokollieren Amazon DocumentDB DocumentDB-API-Aufrufen mit AWS CloudTrail](logging-with-cloudtrail.md)

## Schnittstellen
<a name="what-is-interfaces"></a>

Es gibt mehrere Möglichkeiten, mit Amazon DocumentDB zu interagieren, einschließlich der AWS-Managementkonsole und der AWS CLI.

### AWS-Managementkonsole
<a name="what-is-console"></a>

Das AWS-Managementkonsole ist eine einfache webbasierte Benutzeroberfläche. Sie können Ihre Cluster und Instances von der Konsole aus verwalten, ohne dass eine Programmierung erforderlich ist. [Um auf die Amazon DocumentDB DocumentDB-Konsole zuzugreifen, melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon DocumentDB DocumentDB-Konsole unter https://console.aws.amazon.com /docdb.](https://console.aws.amazon.com/docdb) 

### AWS CLI
<a name="what-is-cli"></a>

Sie können die AWS Command Line Interface (AWS CLI) verwenden, um Ihre Amazon DocumentDB-Cluster und -Instances zu verwalten. Mit minimaler Konfiguration können Sie beginnen, alle Funktionen der Amazon DocumentDB DocumentDB-Konsole von Ihrem bevorzugten Terminalprogramm aus zu nutzen.
+ Informationen zur AWS CLI Installation [von finden Sie unter Installation der AWS Befehlszeilenschnittstelle](https://docs.aws.amazon.com/cli/latest/userguide/installing.html).
+ Informationen zur Verwendung von AWS CLI für Amazon DocumentDB finden Sie unter [AWS Command Line Interface Reference for Amazon DocumentDB](https://docs.aws.amazon.com/cli/latest/reference/docdb/index.html).

### MongoDB-Treiber
<a name="what-is-mongodb-drivers"></a>

Für die Entwicklung und das Schreiben von Anwendungen für einen Amazon DocumentDB-Cluster können Sie die MongoDB-Treiber auch mit Amazon DocumentDB verwenden. Weitere Informationen finden Sie auf der Registerkarte MongoDB-Shell unter [Verbindung bei aktiviertem TLS herstellen](connect_programmatically.md#connect_programmatically-tls_enabled) oder[Verbindung bei deaktiviertem TLS herstellen](connect_programmatically.md#connect_programmatically-tls_disabled).

## Als nächstes
<a name="what-is-next"></a>

In den vorangegangenen Abschnitten wurden Sie mit den grundlegenden Infrastrukturkomponenten von Amazon DocumentDB vertraut gemacht. Was sollten Sie als nächstes tun? Je nach Ihren Umständen finden Sie einen Einstieg in eines der folgenden Themen:
+ Beginnen Sie mit Amazon DocumentDB, indem Sie einen Cluster und eine Instance mithilfe CloudFormation [Amazon DocumentDB DocumentDB-Schnellstart mit CloudFormation](quick_start_cfn.md) von erstellen.
+ Beginnen Sie mit Amazon DocumentDB, indem Sie einen Cluster und eine Instance anhand der Anweisungen in unserem [Leitfaden für die ersten Schritte](get-started-guide.md) erstellen.
+ Beginnen Sie mit Amazon DocumentDB, indem Sie mithilfe der Anweisungen unter einen elastischen Cluster erstellen. [Erste Schritte mit Amazon DocumentDB Elastic Clusters](elastic-get-started.md)
+ Migrieren Sie Ihre MongoDB-Implementierung zu Amazon DocumentDB, indem Sie die Anleitung unter [Migration zu Amazon DocumentDB](docdb-migration.md)

# Amazon DocumentDB: So funktioniert's
<a name="how-it-works"></a>

Amazon DocumentDB (mit MongoDB-Kompatibilität) ist ein vollständig verwalteter, MongoDB-kompatibler Datenbankservice. 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.

**Topics**
+ [Amazon DocumentDB DocumentDB-Endpunkte](#how-it-works.endpoints)
+ [TLS-Unterstützung](#how-it-works.ssl)
+ [Amazon DocumentDB DocumentDB-Speicher](#how-it-works.storage)
+ [Amazon DocumentDB DocumentDB-Replikation](#how-it-works.replication)
+ [Zuverlässigkeit von Amazon DocumentDB](#how-it-works.reliability)
+ [Lesen Sie die Einstellungsoptionen](#durability-consistency-isolation)
+ [TTL löscht](#how-it-works.ttl-deletes)
+ [Abrechnungsfähige Ressourcen](#billing)

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 Datenbankspeicher-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 hinweg zu replizieren und bietet so äußerst beständigen und verfügbaren Speicher. Ein Amazon DocumentDB-Cluster hat genau ein Cluster-Volume, das bis zu 128 TiB an Daten speichern kann.
+ **Instances** — Stellen die Rechenleistung für die Datenbank bereit, indem sie Daten auf das Cluster-Speichervolume schreiben und Daten aus dem Cluster-Speichervolume lesen. Ein Amazon DocumentDB-Cluster kann 0—16 Instances haben. 

Instances erfüllen eine von zwei Rollen:
+ **Primäre Instance** — 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:

![\[Amazon DocumentDB DocumentDB-Endpunkte, einschließlich der Cluster-, Reader- und Instance-Endpunkte.\]](http://docs.aws.amazon.com/de_de/documentdb/latest/developerguide/images/docdb-endpoint-types.png)


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 DocumentDB-Replikate nehmen nicht an der Verarbeitung von Schreibvorgängen teil, weshalb Amazon DocumentDB DocumentDB-Replikate für die Leseskalierung von Vorteil sind. Lesevorgänge von Amazon DocumentDB DocumentDB-Repliken sind letztlich konsistent mit minimaler Replikatverzögerung — 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](cloud_watch.md#cloud_watch-metrics_list). 

## Amazon DocumentDB DocumentDB-Endpunkte
<a name="how-it-works.endpoints"></a>

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.

Es wird empfohlen, dass Sie mithilfe des Clusterendpunkts und im Replikatsatzmodus eine Verbindung mit dem Cluster herstellen (siehe [Als Replikatsatz eine Verbindung zu Amazon DocumentDB herstellen](connect-to-replica-set.md)), es sei denn, es liegt ein bestimmter Anwendungsfall für die Verbindung mit dem Reader-Endpunkt oder einem Instanceendpunkt vor. 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
<a name="how-it-works.endpoints.cluster"></a>

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, empfehlen wir, dass Sie die Verbindung zu Ihrem Cluster über den Cluster-Endpunkt und im Replikatsatzmodus herstellen (siehe[Als Replikatsatz eine Verbindung zu Amazon DocumentDB herstellen](connect-to-replica-set.md)).

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:password@sample-cluster.cluster-123456789012.us-east-1.docdb.amazonaws.com:27017
```

Informationen zum Suchen der Endpunkte eines Clusters finden Sie unter [Die Endpunkte eines Clusters finden](db-cluster-endpoints-find.md).

### Leser-Endpunkt
<a name="how-it-works.endpoints.reader"></a>

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, d. h. in der Verbindungszeichenfolge lautet der Replikatsatzparameter. `&replicaSet=rs0` In diesem Fall können Sie Schreibvorgänge auf der Primärseite ausführen. Wenn Sie jedoch eine Verbindung zu dem angegebenen Cluster herstellen`directConnection=true`, führt der Versuch, einen Schreibvorgang über eine Verbindung zum Leser-Endpunkt auszuführen, zu einem Fehler. Ein Amazon DocumentDB-Cluster hat genau einen Leser-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 Replikat-Instance hinzufügen, öffnet der Reader-Endpunkt schreibgeschützte Verbindungen zu dem 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:password@sample-cluster.cluster-ro-123456789012.us-east-1.docdb.amazonaws.com: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](db-cluster-endpoints-find.md).

### Instance-Endpunkt
<a name="how-it-works.endpoints.instance"></a>

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 larger-than-normal Replikat-Instance bereitstellen, sich mit ihrem Instance-Endpunkt direkt mit der neuen größeren Instance verbinden, die Analyseabfragen ausführen und dann die Instance 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:password@sample-instance.123456789012.us-east-1.docdb.amazonaws.com: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. Es wird nicht empfohlen, eine Verbindung zu Instance-Endpunkten für Produktionsanwendungen herzustellen. Stattdessen wird empfohlen, dass Sie mithilfe des Clusterendpunkts und im Replikatsatzmodus eine Verbindung zum Cluster herstellen (siehe [Als Replikatsatz eine Verbindung zu Amazon DocumentDB herstellen](connect-to-replica-set.md)). Weitere Informationen zur erweiterten Kontrolle der Instance-Failover-Priorität finden Sie unter [Grundlegendes zur Amazon DocumentDB-Cluster-Fehlertoleranz](db-cluster-fault-tolerance.md). 

Informationen zum Suchen der Endpunkte eines Clusters finden Sie unter [Den Endpunkt einer Instanz finden](db-instance-endpoint-find.md).

### Replikat-Set-Modus
<a name="replica-set-mode"></a>

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](#durability-consistency-isolation.read-consistency).

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

```
mongodb://username:password@sample-cluster.cluster-123456789012.us-east-1.docdb.amazonaws.com:27017/?replicaSet=rs0
```

Wenn Sie eine Verbindung im Replikatgruppenmodus 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
<a name="how-it-works.ssl"></a>

Weitere Informationen zur Verbindung mit Amazon DocumentDB mithilfe von Transport Layer Security (TLS) finden Sie unter[Verschlüsseln von Daten während der Übertragung](security.encryption.ssl.md).

## Amazon DocumentDB DocumentDB-Speicher
<a name="how-it-works.storage"></a>

Amazon DocumentDB DocumentDB-Daten werden in einem *Cluster-Volume* gespeichert, bei dem es sich um ein einzelnes virtuelles Volume handelt, das Solid-State-Laufwerke (SSDs) verwendet. Ein Cluster-Volume besteht aus sechs Kopien Ihrer Daten, die automatisch über mehrere Availability Zones hinweg in einer einzigen 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 bearbeiten. 

### Informationen zur Abrechnung des -Datenspeichers
<a name="how-it-works-storage-billing"></a>

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 128 TiB anwachsen. 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 zugewiesene Speicherplatz um einen vergleichbaren Betrag, wenn Daten entfernt werden, z. B. durch Löschen einer Sammlung oder eines Indexes. Somit können Sie die Speichergebühren 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 Speicherplatzes 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 der Speichergrenze (der Höchstmenge, die dem Amazon DocumentDB-Cluster zu einem beliebigen Zeitpunkt zugewiesen wurde). Sie können die Kosten kontrollieren, indem Sie ETL-Praktiken vermeiden, die große Mengen temporärer Informationen erzeugen oder große Mengen neuer Daten laden, bevor nicht benötigte ältere Daten entfernt werden. Wenn das Entfernen von Daten aus einem Amazon DocumentDB-Cluster dazu führt, dass eine beträchtliche Menge an zugewiesenem, aber ungenutztem Speicherplatz zur Verfügung steht, muss zum Zurücksetzen der Höchstgrenze ein logischer Datendump und eine Wiederherstellung auf einem neuen Cluster mit einem Tool wie oder durchgeführt werden. `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**  
Für die Nutzung von `mongodump` Hilfsprogrammen `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 Amazon DocumentDB-Datenspeicherung und zu den I/O Preisen finden Sie unter [Amazon DocumentDB (mit MongoDB-Kompatibilität) — Preise und Preise](https://aws.amazon.com/documentdb/pricing). FAQs](https://aws.amazon.com/documentdb/faqs/#Pricing)

## Amazon DocumentDB DocumentDB-Replikation
<a name="how-it-works.replication"></a>

In einem Amazon DocumentDB-Cluster macht jede Replikatinstanz einen unabhängigen Endpunkt verfügbar. 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 von Datenlesevorgängen zu verbessern und die Verfügbarkeit der Daten in Ihrem Amazon DocumentDB-Cluster zu erhöhen. Amazon DocumentDB-Replikate sind auch Failover-Ziele und werden schnell hochgestuft, wenn die primäre Instance für Ihren Amazon DocumentDB-Cluster ausfällt. 

## Zuverlässigkeit von Amazon DocumentDB
<a name="how-it-works.reliability"></a>

Amazon DocumentDB ist darauf ausgelegt, zuverlässig, robust und fehlertolerant zu sein. (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 umfasst mehrere automatische Funktionen, die es zu einer zuverlässigen Datenbanklösung machen. 

### Automatische Speicherplatzreparatur
<a name="how-it-works.reliability.storage-auto-repair"></a>

Amazon DocumentDB verwaltet mehrere Kopien Ihrer Daten in drei Availability Zones, wodurch das Risiko eines Datenverlusts aufgrund eines Speicherausfalls 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, nach einem Instance-Ausfall eine point-in-time Wiederherstellung durchzuführen. 

### Überlebensfähiges Cache-Warming
<a name="how-it-works.reliability.survivable-cache-warming"></a>

Amazon DocumentDB verwaltet seinen Seiten-Cache in einem von der Datenbank getrennten Prozess, sodass der Seiten-Cache unabhängig von der Datenbank bestehen 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
<a name="how-it-works.reliability.crash-recovery"></a>

Amazon DocumentDB ist so konzipiert, dass es nach einem Absturz fast sofort wiederhergestellt wird und Ihre Anwendungsdaten weiterhin bereitgestellt werden. Amazon DocumentDB führt die Wiederherstellung nach einem Absturz asynchron auf parallel Threads durch, sodass Ihre Datenbank nach einem Absturz fast unmittelbar geöffnet und verfügbar ist. 

### Verwaltung von Ressourcen
<a name="how-it-works.reliability.resource-governance"></a>

Amazon DocumentDB schützt Ressourcen, die für die Ausführung kritischer Prozesse im Service benötigt werden, wie z. B. Zustandsprüfungen. Zu diesem Zweck drosselt Amazon DocumentDB Anfragen, wenn eine Instance unter hohem Speicherdruck steht. Daher können einige Operationen in die Warteschlange gestellt werden, um darauf zu warten, dass der Speicherdruck nachlässt. Wenn die Speicherauslastung anhält, kann es bei Vorgängen in der Warteschlange zu einer Zeitüberschreitung kommen. Anhand der folgenden CloudWatch Messwerte können Sie überwachen, ob der Dienst aufgrund von zu wenig Arbeitsspeicher Drosselungen durchführt oder nicht:`LowMemThrottleQueueDepth`,,. `LowMemThrottleMaxQueueDepth` `LowMemNumOperationsThrottled` `LowMemNumOperationsTimedOut` Weitere Informationen finden Sie unter Amazon DocumentDB überwachen mit CloudWatch. Wenn Sie aufgrund der LowMem CloudWatch Metriken einen anhaltenden Speicherdruck auf Ihrer Instance feststellen, empfehlen wir Ihnen, Ihre Instance hochzuskalieren, um zusätzlichen Speicher für Ihre Arbeitslast bereitzustellen.

## Lesen Sie die Einstellungsoptionen
<a name="durability-consistency-isolation"></a>

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

**Topics**
+ [Haltbarkeit beim Schreiben](#durability-consistency-isolation.write-durability)
+ [Isolierung lesen](#durability-consistency-isolation.read-isolation)
+ [Lesekonsistenz](#durability-consistency-isolation.read-consistency)
+ [Hohe Verfügbarkeit](#durability-consistency-isolation.high-availability)
+ [Lesevorgänge skalieren](#durability-consistency-isolation.scaling-reads)

### Haltbarkeit beim Schreiben
<a name="durability-consistency-isolation.write-durability"></a>

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 Schreibvorgang an den Client bestätigt wird. Wenn Sie einen MongoDB-Replikatsatz mit drei Knoten ausführen, `{w:3, j:true}` würde die Verwendung eines Schreibproblems von die bestmögliche Konfiguration im Vergleich zu Amazon DocumentDB ergeben.

Schreibvorgänge in einen Amazon DocumentDB-Cluster müssen von der Writer-Instance des Clusters verarbeitet werden. Der Versuch, in ein Lesegerät zu schreiben, führt zu einem Fehler. Ein bestätigter Schreibvorgang von einer primären Amazon DocumentDB-Instance ist dauerhaft und kann nicht rückgängig gemacht werden. Amazon DocumentDB ist standardmäßig sehr robust und unterstützt keine nicht dauerhafte Schreiboption. 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 Datenverarbeitung in der Amazon DocumentDB DocumentDB-Architektur getrennt sind, ist ein Cluster mit einer einzigen Instanz äußerst robust. Die Zuverlässigkeit wird auf der Speicherschicht geregelt. Dadurch erreichen ein Amazon DocumentDB-Cluster mit einer einzigen 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 erfolgen innerhalb eines einzigen 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 DocumentDB-Instance werden garantiert nicht auf unbestimmte Zeit blockiert.

### Isolierung lesen
<a name="durability-consistency-isolation.read-isolation"></a>

Lesevorgänge aus einer Amazon DocumentDB 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
<a name="durability-consistency-isolation.read-consistency"></a>

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 dauerhafte Leseoption.

Lesevorgänge aus der primären Instance eines Amazon DocumentDB-Clusters sind unter normalen Betriebsbedingungen sehr konsistent und read-after-write konsistent. 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
<a name="durability-consistency-isolation.read-preferences"></a>

Amazon DocumentDB unterstützt das Festlegen einer Lesepräferenzoption nur beim Lesen von Daten vom Cluster-Endpunkt im Replikatsatzmodus. 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 Replikatsatzmodus keine Verbindung zu einem Amazon DocumentDB-Cluster-Endpunkt herstellt, ist das Ergebnis der Angabe einer Lesepräferenz undefiniert.

Amazon DocumentDB unterstützt die Einstellung *von Tag-Sets* als Lesepräferenz nicht.

**Unterstützte Leseeinstellungsoptionen**
+ **`primary`**— Durch die Angabe einer `primary` Lesepräferenz wird sichergestellt, dass alle Lesevorgänge an die primäre Instance des Clusters weitergeleitet werden. Wenn die primäre Instance nicht verfügbar ist, schlägt der Lesevorgang fehl. Eine `primary` Lesepräferenz sorgt für read-after-write Konsistenz und eignet sich für Anwendungsfälle, in denen read-after-write Konsistenz Vorrang vor Hochverfügbarkeit und Leseskalierung hat.

  Im folgenden Beispiel wird die Leseeinstellung `primary` angegeben:

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

   
+ **`primaryPreferred`**— Die Angabe einer `primaryPreferred` Lesepräferenz leitet Lesevorgänge bei normalem Betrieb an die primäre Instance weiter. Wenn es ein primäres Failover gibt, leitet der Client Anfragen an ein Replikat weiter. Eine `primaryPreferred` Lesepräferenz sorgt für read-after-write Konsistenz während des normalen Betriebs und letztendlich für konsistente Lesevorgänge während eines Failover-Ereignisses. Eine `primaryPreferred` Lesepräferenz eignet sich für Anwendungsfälle, in denen read-after-write Konsistenz Vorrang vor Leseskalierung hat, aber dennoch eine hohe Verfügbarkeit erforderlich ist.

  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 und niemals an die primäre Instanz weitergeleitet werden. Wenn es in einem Cluster keine Replikat-Instances gibt, schlägt die Leseanforderung fehl. Eine `secondary` Lesepräferenz führt letztendlich zu konsistenten Lesevorgängen und eignet sich für Anwendungsfälle, in denen der Schreibdurchsatz der primären Instanz Vorrang vor hoher Verfügbarkeit und Konsistenz hat. read-after-write

  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 eine Read Replica 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. Dadurch wird read-after-write Konsistenz gewährleistet, wenn der Lesevorgang von der primären Instanz verarbeitet wird (mit Ausnahme von Failover-Ereignissen). Eine `secondaryPreferred` Lesepräferenz eignet sich für Anwendungsfälle, in denen Leseskalierung und Hochverfügbarkeit Vorrang vor Konsistenz haben. read-after-write

  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. Dadurch wird read-after-write Konsistenz gewährleistet, wenn der Lesevorgang von der primären Instance bedient wird (mit Ausnahme von Failover-Ereignissen). Eine `nearest` Lesepräferenz eignet sich für Anwendungsfälle, in denen eine möglichst geringe Leselatenz und hohe Verfügbarkeit Vorrang vor read-after-write Konsistenz und Leseskalierung haben.

  Im folgenden Beispiel wird die Leseeinstellung `nearest` angegeben:

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

### Hohe Verfügbarkeit
<a name="durability-consistency-isolation.high-availability"></a>

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 ein Amazon DocumentDB DocumentDB-Replikat zur neuen primären Instance hochgestuft, mit einer kurzen Unterbrechung, während 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. Das Heraufstufen eines Amazon DocumentDB DocumentDB-Replikats ist jedoch viel schneller als das Neuerstellen der primären Instance. Wir empfehlen daher, ein oder mehrere Amazon DocumentDB DocumentDB-Replikate als Failover-Ziele zu erstellen.

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](db-cluster-fault-tolerance.md).

### Lesevorgänge skalieren
<a name="durability-consistency-isolation.scaling-reads"></a>

Amazon DocumentDB 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. Mit Amazon DocumentDB DocumentDB-Repliken zahlen Sie nur für die Lesekapazität, die Sie benötigen.

Amazon DocumentDB unterstützt die clientseitige Leseskalierung mithilfe von Read Preference-Optionen. Weitere Informationen finden Sie unter [Amazon DocumentDB Leseeinstellungen](#durability-consistency-isolation.read-preferences).

## TTL löscht
<a name="how-it-works.ttl-deletes"></a>

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 die Durchsatz- und TTL-Löschraten steigen, sollten Sie aufgrund der erhöhten I/O-Auslastung mit einer Erhöhung Ihrer Rechnung rechnen.

Wenn Sie einen TTL-Index für eine bestehende 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 Teils 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 deutlich kostengünstiger sein als die Verwendung eines TTL-Index.

## Abrechnungsfähige Ressourcen
<a name="billing"></a>

### Identifizieren von kostenpflichtigen Amazon DocumentDB DocumentDB-Ressourcen
<a name="billing.identifying-billable-resources"></a>

Als vollständig verwalteter Datenbankservice berechnet 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)](https://aws.amazon.com/documentdb/pricing/). 

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

#### Verwenden Sie den AWS-Managementkonsole
<a name="billing.identifying-billable-resources-con"></a>

Mithilfe von können Sie die AWS-Managementkonsole Amazon DocumentDB-Cluster, -Instances und -Snapshots ermitteln, die Sie für eine bestimmte Person 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 DocumentDB-Konsole unter [https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb).

1. Um nach abrechnungsfähigen Ressourcen in einer anderen Region als Ihrer Standardregion zu suchen, wählen Sie in der oberen rechten Ecke des Bildschirms die Region aus, nach der Sie suchen möchten. AWS-Region   
![\[Die Region North Virginia in der Regionsauswahl.\]](http://docs.aws.amazon.com/de_de/documentdb/latest/developerguide/images/db-cluster-console-region.png)

1. Wählen Sie im Navigationsbereich die Art der kostenpflichtigen Ressource aus: **Clusters (Cluster)**, **Instances** oder **Snapshots**.  
![\[Cluster, Instanzen und Snapshots im Navigationsbereich.\]](http://docs.aws.amazon.com/de_de/documentdb/latest/developerguide/images/db-navigation-pane-clusters-instances-snapshots.png)

1. 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.

#### Mit dem AWS CLI
<a name="billing.identifying-billable-resources-cli"></a>

Mithilfe von können Sie die AWS CLI Amazon DocumentDB-Cluster, -Instances und -Snapshots ermitteln, die Sie für eine bestimmte Person 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.

**Example**  
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 kostenpflichtiger Ressourcen
<a name="billing.deleting-billable-resources"></a>

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](db-instance-delete.md). 
**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](db-cluster-delete.md). 
+ Weitere Informationen zum Löschen manueller Snapshots finden Sie unter [Löschen eines Cluster-Snapshots](backup_restore-delete_cluster_snapshot.md). 

# Was ist eine Dokumentendatenbank?
<a name="what-is-document-db"></a>

Einige Entwickler betrachten ihr Datenmodell nicht als normalisierte Zeilen und Spalten. In der Regel werden Daten auf Anwendungsebene als JSON-Dokument dargestellt, da es für Entwickler intuitiver ist, ihr Datenmodell als Dokument zu betrachten. 

Die Popularität von Dokumentdatenbanken ist gestiegen, weil Sie mit ihnen Daten in einer Datenbank erhalten können, indem Sie das gleiche Dokumentmodellformat verwenden, das Sie in Ihrem Anwendungscode verwenden. Dokumentendatenbanken bieten leistungsstarke und intuitive Funktionen APIs für eine flexible und agile Entwicklung.

**Topics**
+ [Anwendungsfälle](document-database-use-cases.md)
+ [Dokumente verstehen](document-database-documents-understanding.md)
+ [Arbeiten mit Dokumenten](document-database-working-with-documents.md)

# Anwendungsfälle für Dokumentendatenbanken
<a name="document-database-use-cases"></a>

Ihr Anwendungsfall bestimmt, ob Sie eine Dokumentendatenbank oder eine andere Art von Datenbank für die Verwaltung Ihrer Daten benötigen. Dokumentdatenbanken sind nützlich für Workloads, die ein flexibles Schema für eine schnelle, iterative Entwicklung benötigen. Im Folgenden finden Sie einige Beispiele für Anwendungsfälle, bei denen Dokumentendatenbanken erhebliche Vorteile bieten können:

**Topics**
+ [Benutzerprofile](#document-databases-use-cases.user-profiles)
+ [Big Data in Echtzeit](#document-databases-use-cases.big-data)
+ [Verwaltung von Inhalten](#document-databases-use-cases.content-management)

## Benutzerprofile
<a name="document-databases-use-cases.user-profiles"></a>

Da Dokumentdatenbanken über ein flexibles Schema verfügen, können sie Dokumente speichern, die unterschiedliche Attribute und Datenwerte aufweisen. Dokumentdatenbanken sind eine praktische Lösung für Online-Profile, in denen verschiedene Benutzer unterschiedliche Arten von Informationen bereitstellen. Mit Hilfe einer Dokumentdatenbank können Sie das Profil jedes Benutzers effizient speichern, indem Sie nur die Attribute speichern, die für jeden Benutzer spezifisch sind.

Angenommen, ein Benutzer entscheidet sich dafür, Informationen in seinem Profil hinzuzufügen oder zu entfernen. In diesem Fall könnte ihr Dokument leicht durch eine aktualisierte Version ersetzt werden, die alle kürzlich hinzugefügten Attribute und Daten enthält oder alle neu weggelassenen Attribute und Daten auslässt. Dokumentdatenbanken bewältigen diese Individualität und Fluidität auf einfache Weise.

## Big Data in Echtzeit
<a name="document-databases-use-cases.big-data"></a>

In der Vergangenheit wurde die Fähigkeit, Informationen aus Betriebsdaten zu extrahieren, dadurch beeinträchtigt, dass operative Datenbanken und analytische Datenbanken in unterschiedlichen Umgebungen verwaltet wurden — den betrieblichen bzw. den jeweiligen. business/reporting Die Fähigkeit, operative Informationen in Echtzeit zu extrahieren, ist in einem hart umkämpften Geschäftsumfeld von entscheidender Bedeutung. Durch die Verwendung von Dokumentendatenbanken kann ein Unternehmen Betriebsdaten aus jeder beliebigen Quelle speichern und verwalten und gleichzeitig die Daten zur Analyse an die BI-Engine seiner Wahl weiterleiten. Es ist nicht erforderlich, dass zwei Umgebungen vorhanden sein müssen.

## Verwaltung von Inhalten
<a name="document-databases-use-cases.content-management"></a>

Um Inhalte effektiv zu verwalten, müssen Sie in der Lage sein, Inhalte aus einer Vielzahl von Quellen zu sammeln, zu aggregieren und dann an den Client zu liefern. Aufgrund ihres flexiblen Schemas sind Dokumentdatenbanken ideal für die Erfassung und Speicherung jeglicher Art von Daten. Mit ihnen können Sie neue Arten von Inhalten erstellen und integrieren, einschließlich benutzergenerierter Inhalte wie Bilder, Kommentare und Videos.

# Dokumente verstehen
<a name="document-database-documents-understanding"></a>

Dokumentendatenbanken werden verwendet, um semistrukturierte Daten als Dokument zu speichern, anstatt Daten in mehreren Tabellen zu normalisieren, von denen jede eine eindeutige und feste Struktur hat, wie in einer relationalen Datenbank. Dokumente, die in einer Dokumentdatenbank gespeichert sind, verwenden verschachtelte Schlüssel-Werte-Paare, um die Struktur oder das Schema des Dokuments bereitzustellen. Es können jedoch verschiedene Arten von Dokumenten in derselben Dokumentdatenbank gespeichert werden, wodurch die Anforderung erfüllt wird, ähnliche Daten in unterschiedlichen Formaten zu verarbeiten. Da beispielsweise jedes Dokument selbstbeschreibend ist, können die in diesem Abschnitt beschriebenen JSON-kodierten Dokumente für einen Online-Shop, die unter dem Thema [Beispieldokumente in einer Dokumentendatenbank](#document-database-documents) beschrieben werden, in derselben Dokumentendatenbank gespeichert werden. 

**Topics**
+ [SQL im Vergleich zu nichtrelationaler Terminologie](#document-database-sql-vs-nosql-terms)
+ [Einfache Dokumente](#document-database-documents-simple)
+ [Eingebettete Dokumente](#document-database-documents-embeded)
+ [Beispieldokumente in einer Dokumentendatenbank](#document-database-documents)
+ [Grundlegendes zur Normalisierung in einer Dokumentendatenbank](#document-database-normalization)

## SQL im Vergleich zu nichtrelationaler Terminologie
<a name="document-database-sql-vs-nosql-terms"></a>

Die folgende Tabelle vergleicht die von Dokumentendatenbanken (MongoDB) verwendete Terminologie mit der von SQL-Datenbanken verwendeten Terminologie.


|  SQL  |  MongoDB  | 
| --- | --- | 
|  Tabelle  |  Sammlung  | 
|  Zeile  |  Dokument  | 
|  Spalte  |  Feld  | 
|  Primärschlüssel  |  ObjectId  | 
|  Index  |  Index  | 
|  Anzeigen  |  Anzeigen  | 
|  Verschachtelte(s) Tabelle oder Objekt  |  Eingebettetes Dokument  | 
|  Array  |  Array  | 

## Einfache Dokumente
<a name="document-database-documents-simple"></a>

Alle Dokumente in einer Dokumentendatenbank sind selbstbeschreibend. In dieser Dokumentation werden JSON-ähnlich formatierte Dokumente verwendet, Sie können aber auch andere Verschlüsselungsmethoden einsetzen.

Ein einfaches Dokument hat ein oder mehrere Felder, die alle auf der gleichen Ebene innerhalb des Dokuments liegen. Im folgenden Beispiel sind die Felder `SSN`, `LName`, `FName`, `DOB`, `Street`, `City`, `State-Province`, `PostalCode` und `Country` alle Elemente auf derselben Ebene im Dokument.

```
{
   "SSN": "123-45-6789",
   "LName": "Rivera",
   "FName": "Martha",
   "DOB": "1992-11-16",
   "Street": "125 Main St.",
   "City": "Anytown",
   "State-Province": "WA",
   "PostalCode": "98117",
   "Country": "USA"
}
```

Wenn Informationen in einem einfachen Dokument organisiert sind, wird jedes Feld einzeln verwaltet. Um die Adresse einer Person abzurufen, müssen Sie `Street`, `City`, `State-Province`, `PostalCode` und `Country` als einzelne Datenelemente abrufen.

## Eingebettete Dokumente
<a name="document-database-documents-embeded"></a>

Ein komplexes Dokument organisiert seine Daten, indem es eingebettete Dokumente innerhalb des Dokuments erstellt. Eingebettete Dokumente helfen bei der Verwaltung von Daten in Gruppierungen und als einzelne Datenelemente, je nachdem, was im jeweiligen Fall effizienter ist. Mit dem vorhergehenden Beispiel könnten Sie ein `Address`-Dokument in das Hauptdokument einbetten. Dadurch ergibt sich die folgende Dokumentstruktur:

```
{
   "SSN": "123-45-6789",
   "LName": "Rivera",
   "FName": "Martha",
   "DOB": "1992-11-16",
   "Address": 
   {
       "Street": "125 Main St.",
       "City": "Anytown",
       "State-Province": "WA",
       "PostalCode": "98117",
       "Country": "USA" 
   }
}
```

Sie können jetzt auf die Daten im Dokument als einzelne Felder (`"SSN":`), als eingebettetes Dokument (`"Address":`) oder als Mitglied eines eingebetteten Dokuments (`"Address":{"Street":}`) zugreifen.

## Beispieldokumente in einer Dokumentendatenbank
<a name="document-database-documents"></a>

Da jedes Dokument in einer Dokumentdatenbank selbstbeschreibend ist, kann die Struktur von Dokumenten innerhalb einer Dokumentdatenbank unterschiedlich sein. Die folgenden beiden Dokumente, eines für ein Buch und eines für eine Zeitschrift, sind strukturell unterschiedlich. Beide können sich jedoch in der gleichen Dokumentdatenbank befinden.

Im Folgenden finden Sie ein Beispiel-Buch-Dokument:

```
{
    "_id" : "9876543210123",
    "Type": "book",
    "ISBN": "987-6-543-21012-3",
    "Author": 
    {
        "LName":"Roe",
        "MI": "T",
        "FName": "Richard" 
    },
    "Title": "Understanding Document Databases"
}
```

Im Folgenden finden Sie ein Beispiel für ein Zeitschriften-Dokument mit zwei Artikeln:

```
{
    "_id" : "0123456789012",
    "Publication": "Programming Today",
    "Issue": 
    {
        "Volume": "14",
        "Number": "09"
    },
    "Articles" : [ 
        {
            "Title": "Is a Document Database Your Best Solution?",
            "Author": 
            {
                "LName": "Major",
                "FName": "Mary" 
            }
        },
        {
            "Title": "Databases for Online Solutions",
            "Author": 
            {
                "LName": "Stiles",
                "FName": "John" 
            }
        }
    ],
    "Type": "periodical"
}
```

Vergleichen Sie die Struktur dieser beiden Dokumente. Bei einer relationalen Datenbank benötigen Sie entweder getrennte Tabellen "Zeitschriften" und "Bücher" oder eine einzelne Tabelle mit unbenutzten Feldern wie "Publikation", "Ausgabe", "Artikel" und "MI" als `null` Werte. Da Dokumentendatenbanken halbstrukturiert sind und jedes Dokument seine eigene Struktur definiert, können diese beiden Dokumente ohne `null`-Felder gleichzeitig in derselben Dokumentendatenbank vorhanden sein. Dokumentdatenbanken sind gut geeignet, um mit lückenhaften Daten umzugehen.

Die Entwicklung auf Basis einer Dokumentdatenbank ermöglicht eine schnelle, iterative Entwicklung. Denn Sie können die Datenstruktur eines Dokuments dynamisch ändern, ohne das Schema für die gesamte Sammlung ändern zu müssen. Dokumentdatenbanken eignen sich hervorragend für agile Entwicklungen und sich dynamisch verändernde Umgebungen.

## Grundlegendes zur Normalisierung in einer Dokumentendatenbank
<a name="document-database-normalization"></a>

Dokumentdatenbanken werden nicht normalisiert; in einem Dokument gefundene Daten können in einem anderen Dokument wiederholt werden. Darüber hinaus können einige Datenunterschiede zwischen den Dokumenten bestehen. Betrachten Sie beispielsweise das Szenario, in dem Sie einen Einkauf in einem Online-Shop tätigen und alle Details Ihrer Einkäufe in einem einzigen Dokument gespeichert sind. Das Dokument könnte etwa so aussehen wie das folgende JSON-Dokument:

```
{
    "DateTime": "2018-08-15T12:13:10Z",
    "LName" : "Santos",
    "FName" : "Paul",
    "Cart" : [ 
        {
            "ItemId" : "9876543210123",
            "Description" : "Understanding Document Databases",
            "Price" : "29.95"
        },
        {
            "ItemId" : "0123456789012",
            "Description" : "Programming Today",
            "Issue": {
                "Volume": "14",
                "Number": "09"
            },
            "Price" : "8.95"
        },
        {
            "ItemId": "234567890-K",
            "Description": "Gel Pen (black)",
            "Price": "2.49" 
        }
    ],
    "PaymentMethod" : 
    {
        "Issuer" : "MasterCard",
        "Number" : "1234-5678-9012-3456" 
    },
    "ShopperId" : "1234567890" 
}
```

Alle diese Informationen werden als Dokument in einer Transaktionssammlung gespeichert. Später merken Sie, dass Sie vergessen haben, einen Artikel zu kaufen. Daher melden Sie sich erneut im gleichen Shop an und tätigen einen weiteren Kauf, der auch als ein weiteres Dokument in der Transaktionssammlung gespeichert wird.

```
{
    "DateTime": "2018-08-15T14:49:00Z",
    "LName" : "Santos",
    "FName" : "Paul",
    "Cart" : [ 
        {
            "ItemId" : "2109876543210",
            "Description" : "Document Databases for Fun and Profit",
            "Price" : "45.95"
        } 
    ],
    "PaymentMethod" : 
    {
        "Issuer" : "Visa",
        "Number" : "0987-6543-2109-8765" 
    },
    "ShopperId" : "1234567890" 
}
```

Beachten Sie die Redundanz zwischen diesen beiden Dokumenten — Ihrem Namen und Ihrer Kunden-ID (und, falls Sie dieselbe Kreditkarte verwendet haben, Ihren Kreditkarteninformationen). Aber das ist in Ordnung, denn die Speicherung ist kostengünstig, und jedes Dokument zeichnet eine einzelne Transaktion vollständig auf, die mit einer einfachen Schlüssel-/Wertabfrage, die keine Verknüpfungen erfordert, schnell abgerufen werden kann.

Es besteht auch eine offensichtliche Diskrepanz zwischen den beiden Dokumenten — Ihren Kreditkarteninformationen. Dies ist nur eine scheinbare Diskrepanz, da es wahrscheinlich ist, dass Sie für jeden Kauf eine andere Kreditkarte verwendet haben. Jedes Dokument entspricht genau der Transaktion, die es dokumentiert.

# Arbeiten mit Dokumenten
<a name="document-database-working-with-documents"></a>

Als Dokumentendatenbank macht es Amazon DocumentDB einfach, JSON-Daten zu speichern, abzufragen und zu indizieren. In Amazon DocumentDB entspricht eine Sammlung einer Tabelle in einer relationalen Datenbank, außer dass kein einziges Schema für alle Dokumente durchgesetzt wird. Mit Sammlungen können Sie ähnliche Dokumente gruppieren und gleichzeitig alle in derselben Datenbank halten, ohne dass sie in ihrer Struktur identisch sein müssen.

Unter Verwendung der Beispieldokumente aus früheren Abschnitten ist es wahrscheinlich, dass Sie Sammlungen für `reading_material` und `office_supplies` haben werden. Es liegt in der Verantwortung Ihrer Software, die Zugehörigkeit eines Dokuments zu einer bestimmten Sammlung durchzusetzen.

Die folgenden Beispiele zeigen anhand der MongoDB-API, wie Sie Dokumente hinzufügen, abfragen, aktualisieren und löschen können.

**Topics**
+ [Dokumente hinzufügen](#document-database-adding-documents)
+ [Dokumente werden abgefragt](#document-database-queries)
+ [Dokumente werden aktualisiert](#document-database-updating)
+ [Dokumente löschen](#document-database-deleting)

## Dokumente hinzufügen
<a name="document-database-adding-documents"></a>

In Amazon DocumentDB wird eine Datenbank erstellt, wenn Sie ein Dokument zum ersten Mal zu einer Sammlung hinzufügen. In diesem Beispiel erstellen Sie eine Sammlung mit dem Namen `example` in der Datenbank `test`, die die Standarddatenbank ist, wenn Sie eine Verbindung mit einem Cluster herstellen. Da die Sammlung implizit erstellt wird, wenn das erste Dokument eingefügt wird, gibt es bei der Überprüfung des Sammlungsnamens keine Fehler. Das heißt, ein Tippfehler im Sammlungsnamen, wie z. B. `eexample` statt `example` führt dazu, dass das Dokument erstellt und der Sammlung `eexample` und nicht der beabsichtigten Sammlung hinzugefügt wird. Die Fehlerüberprüfung muss von Ihrer Anwendung durchgeführt werden.

Die folgenden Beispiele verwenden die MongoDB-API zum Hinzufügen der Dokumente.

**Topics**
+ [Ein einzelnes Dokument hinzufügen](#document-database-adding-documents-single)
+ [Hinzufügen mehrerer Dokumente](#document-database-adding-documents-multiple)

### Ein einzelnes Dokument hinzufügen
<a name="document-database-adding-documents-single"></a>

Um ein einzelnes Dokument zu einer Sammlung hinzuzufügen, verwenden Sie die Operation `insertOne( {} )` mit dem Dokument, das Sie der Sammlung hinzufügen möchten.

```
db.example.insertOne(
    {
        "Item": "Ruler",
        "Colors": ["Red","Green","Blue","Clear","Yellow"],
        "Inventory": {
            "OnHand": 47,
            "MinOnHand": 40
        },
        "UnitPrice": 0.89
    }
)
```

Die Ausgabe dieser Operation sieht in etwa folgendermaßen aus (JSON-Format).

```
{
    "acknowledged" : true,
    "insertedId" : ObjectId("5bedafbcf65ff161707de24f")
}
```

### Hinzufügen mehrerer Dokumente
<a name="document-database-adding-documents-multiple"></a>

Um mehrere Dokumente zu einer Sammlung hinzuzufügen, verwenden Sie die Operation `insertMany( [{},...,{}] )` mit einer Liste der Dokumente, die Sie der Sammlung hinzufügen möchten. Obwohl die Dokumente in dieser Liste unterschiedliche Schemata haben, können sie alle zur gleichen Sammlung hinzugefügt werden.

```
db.example.insertMany(
    [
        {
            "Item": "Pen",
            "Colors": ["Red","Green","Blue","Black"],
            "Inventory": {
                "OnHand": 244,
                "MinOnHand": 72 
            }
        },
        {
            "Item": "Poster Paint",
            "Colors": ["Red","Green","Blue","Black","White"],
            "Inventory": {
                "OnHand": 47,
                "MinOnHand": 50 
            }
        },
        {
            "Item": "Spray Paint",
            "Colors": ["Black","Red","Green","Blue"],
            "Inventory": {
                "OnHand": 47,
                "MinOnHand": 50,
                "OrderQnty": 36
            }
        }    
    ]
)
```

Die Ausgabe dieser Operation sieht in etwa folgendermaßen aus (JSON-Format).

```
{
    "acknowledged" : true,
    "insertedIds" : [
            ObjectId("5bedb07941ca8d9198f5934c"),
            ObjectId("5bedb07941ca8d9198f5934d"),
            ObjectId("5bedb07941ca8d9198f5934e")
    ]
}
```

## Dokumente werden abgefragt
<a name="document-database-queries"></a>

Manchmal müssen Sie möglicherweise den Bestand Ihres Online-Shops nachschlagen, damit Kunden das Angebot sehen und kaufen können. Die Abfrage einer Sammlung ist relativ einfach, unabhängig davon, ob Sie alle Dokumente in der Sammlung haben möchten oder nur die Dokumente, die ein bestimmtes Kriterium erfüllen.

Verwenden Sie die Operation `find()`, um Dokumente abzufragen. Der Befehl `find()` hat einen einzigen Dokumentenparameter, der die Kriterien für die Auswahl der zurückzugebenden Dokumente definiert. Die Ausgabe von `find()` ist ein Dokument, das als einzelne Textzeile ohne Zeilenumbrüche formatiert ist. Um das Ausgabedokument für eine bessere Lesbarkeit zu formatieren, verwenden Sie `find().pretty()`. Alle Beispiele in diesem Thema verwenden `.pretty()` zum Formatieren der Ausgabe.

Verwenden Sie die vier Dokumente, die Sie in den beiden vorangegangenen Übungen in die `example` Sammlung eingefügt haben — `insertOne()` und`insertMany()`.

**Topics**
+ [Alle Dokumente in einer Sammlung abrufen](#document-database-queries-all-documents)
+ [Dokumente werden abgerufen, die einem Feldwert entsprechen](#document-database-queries-match-criteria)
+ [Dokumente werden abgerufen, die einem eingebetteten Dokument entsprechen](#document-database-queries-entire-embedded-document)
+ [Dokumente werden abgerufen, die einem Feldwert in einem eingebetteten Dokument entsprechen](#document-database-queries-embeded-document-field)
+ [Dokumente werden abgerufen, die einem Array entsprechen](#document-database-queries-array-match)
+ [Dokumente werden abgerufen, die einem Wert in einem Array entsprechen](#document-database-queries-array-value-match)
+ [Dokumente mithilfe von Operatoren abrufen](#document-database-query-operators)

### Alle Dokumente in einer Sammlung abrufen
<a name="document-database-queries-all-documents"></a>

Um alle Dokumente in Ihrer Sammlung abzurufen, verwenden Sie die Operation `find()` mit einem leeren Abfragedokument.

Die folgende Abfrage gibt alle Dokumente der Sammlung `example` zurück.

```
db.example.find( {} ).pretty()
```

### Dokumente werden abgerufen, die einem Feldwert entsprechen
<a name="document-database-queries-match-criteria"></a>

Um alle Dokumente abzurufen, die mit einem Feld und einem Wert übereinstimmen, verwenden Sie die Operation `find()` mit einem Abfragedokument, das die entsprechenden Felder und Werte identifiziert.

Bei Verwendung der vorangegangenen Dokumente gibt diese Abfrage alle Dokumente zurück, bei denen das Feld "Item" (Element) "Pen" (Stift) entspricht.

```
db.example.find( { "Item": "Pen" } ).pretty()
```

### Dokumente werden abgerufen, die einem eingebetteten Dokument entsprechen
<a name="document-database-queries-entire-embedded-document"></a>

Um alle Dokumente zu suchen, die mit einem eingebetteten Dokument übereinstimmen, verwenden Sie die Operation `find()` mit einem Abfragedokument, in dem der Name des eingebetteten Dokuments sowie alle Felder und Werte für dieses eingebettete Dokument angegeben werden.

Beim Vergleichen mit einem eingebetteten Dokument muss das eingebettete Dokument denselben Namen haben wie in der Abfrage. Zudem müssen die Felder und Werte im eingebetteten Dokument mit der Abfrage übereinstimmen.

Die folgende Abfrage gibt nur das Dokument "Poster Paint" zurück. Dies liegt daran, dass "Pen" über verschiedene Werte für "`OnHand`" und "`MinOnHand`" verfügt und "Spray Paint" ein weiteres Feld (`OrderQnty`) als das Abfragedokument besitzt.

```
db.example.find({"Inventory": {
    "OnHand": 47,
    "MinOnHand": 50 } } ).pretty()
```

### Dokumente werden abgerufen, die einem Feldwert in einem eingebetteten Dokument entsprechen
<a name="document-database-queries-embeded-document-field"></a>

Um alle Dokumente zu suchen, die mit einem eingebetteten Dokument übereinstimmen, verwenden Sie die Operation `find()` mit einem Abfragedokument, in dem der Name des eingebetteten Dokuments sowie alle Felder und Werte für dieses eingebettete Dokument angegeben werden.

Aufgrund der vorangegangenen Dokumente verwendet die folgende Abfrage "Punktnotation", um das eingebettete Dokument und die Felder von Interesse anzugeben. Jedes Dokument, das damit übereinstimmt, wird zurückgegeben, unabhängig davon, welche anderen Felder im eingebetteten Dokument vorhanden sind. Die Abfrage gibt "Poster Paint" und "Spray Paint" zurück, weil sie beide den angegebenen Feldern und Werten entsprechen.

```
db.example.find({"Inventory.OnHand": 47, "Inventory.MinOnHand": 50 }).pretty()
```

### Dokumente werden abgerufen, die einem Array entsprechen
<a name="document-database-queries-array-match"></a>

Um alle Dokumente zu finden, die einem Array entsprechen, verwenden Sie die Operation `find()` mit dem Namen des Arrays, an dem Sie interessiert sind, und allen Werten in diesem Array. Die Abfrage gibt alle Dokumente zurück, in denen sich ein Array mit diesem Namen befindet und in denen die Array-Werte identisch sind und die gleiche Reihenfolge wie in der Abfrage aufweisen.

Die folgende Abfrage gibt nur "Pen" zurück, da "Poster Paint" über eine zusätzlichen Farbe (White) verfügt und die Farben in "Spray Paint" in einer anderen Reihenfolge vorliegen.

```
db.example.find( { "Colors": ["Red","Green","Blue","Black"] } ).pretty() 
```

### Dokumente werden abgerufen, die einem Wert in einem Array entsprechen
<a name="document-database-queries-array-value-match"></a>

Um alle Dokumente mit einem bestimmten Array-Wert zu finden, verwenden Sie die Operation `find()` mit dem Namen und Wert des Arrays, an dem Sie interessiert sind.

```
db.example.find( { "Colors": "Red" } ).pretty() 
```

Bei der vorherigen Operation werden alle drei Dokumente zurückgegeben, da jedes davon ein Array mit dem Namen `Colors` und den Wert "`Red`" irgendwo im Array besitzt. Wenn Sie den Wert "`White`" angeben, gibt die Abfrage nur "Poster Paint" zurück.

### Dokumente mithilfe von Operatoren abrufen
<a name="document-database-query-operators"></a>

Die folgende Abfrage gibt alle Dokumente zurück, in denen der Wert "`Inventory.OnHand`" kleiner als 50 ist.

```
db.example.find(
        { "Inventory.OnHand": { $lt: 50 } } )
```

Eine Liste der unterstützten Abfrageoperatoren finden Sie unter [Abfrage- und Projektionsoperatoren](mongo-apis.md#mongo-apis-query). 

## Dokumente werden aktualisiert
<a name="document-database-updating"></a>

In der Regel sind Ihre Dokumente nicht statisch und werden als Teil Ihrer Anwendungs-Workflows aktualisiert. Die folgenden Beispiele zeigen einige der Möglichkeiten, wie Sie Dokumente aktualisieren können.

Um ein bestehendes Dokument zu aktualisieren, verwenden Sie die Operation`update()`. Die Operation `update()` besitzt zwei Dokumentenparameter. Das erste Dokument gibt an, welche Dokumente aktualisiert werden sollen. Das zweite Dokument gibt an, welche Aktualisierungen durchzuführen sind.

Wenn Sie ein vorhandenes Feld aktualisieren — unabhängig davon, ob es sich bei dem Feld um ein einfaches Feld, ein Array oder ein eingebettetes Dokument handelt — geben Sie den Feldnamen und seine Werte an. Am Ende der Operation wirkt es so, als ob das Feld im alten Dokument durch das neue Feld und die Werte ersetzt wurde.

**Topics**
+ [Aktualisierung der Werte eines vorhandenen Felds](#document-database-updating-existing-fields)
+ [Ein neues Feld hinzufügen](#document-database-updating-adding-field)
+ [Ein eingebettetes Dokument ersetzen](#document-database-replacing-embedded-document)
+ [Neue Felder in ein eingebettetes Dokument einfügen](#document-database-updating-adding-field-embedded)
+ [Ein Feld aus einem Dokument entfernen](#document-database-remove-field)
+ [Ein Feld aus mehreren Dokumenten entfernen](#document-database-remove-field-all)

### Aktualisierung der Werte eines vorhandenen Felds
<a name="document-database-updating-existing-fields"></a>

Verwenden Sie die folgenden vier Dokumente, die Sie zuvor hinzugefügt haben, für die folgenden Aktualisierungsoperationen.

```
{
    "Item": "Ruler",
    "Colors": ["Red","Green","Blue","Clear","Yellow"],
    "Inventory": {
        "OnHand": 47,
        "MinOnHand": 40
    },
    "UnitPrice": 0.89
},
{
    "Item": "Pen",
    "Colors": ["Red","Green","Blue","Black"],
    "Inventory": {
        "OnHand": 244,
        "MinOnHand": 72 
    }
},
{
    "Item": "Poster Paint",
    "Colors": ["Red","Green","Blue","Black","White"],
    "Inventory": {
        "OnHand": 47,
        "MinOnHand": 50 
    }
},
{
    "Item": "Spray Paint",
    "Colors": ["Black","Red","Green","Blue"],
    "Inventory": {
        "OnHand": 47,
        "MinOnHand": 50,
        "OrderQnty": 36
    }
}
```

**So aktualisieren Sie ein einfaches Feld**  
Um ein einfaches Feld zu aktualisieren, verwenden Sie `update()` mit `$set`, um den Feldnamen und den neuen Wert anzugeben. Im folgenden Beispiel wird das `Item` von "Pen" in "Gel Pen" geändert.

```
db.example.update(
    { "Item" : "Pen" },
    { $set: { "Item": "Gel Pen" } }
)
```

Ergebnisse dieser Operation sehen in etwa folgendermaßen aus.

```
{
    "Item": "Gel Pen",
    "Colors": ["Red","Green","Blue","Black"],
    "Inventory": {
        "OnHand": 244,
        "MinOnHand": 72 
    }
}
```

**So aktualisieren Sie ein Array**  
Das folgende Beispiel ersetzt das vorhandene Array von Farben mit einem neuen Array, das in der Liste der Farben `Orange` enthält und `White` weglässt. Die neue Liste von Farben liegt in der Reihenfolge vor, die in der Operation `update()` festgelegt wurde.

```
db.example.update(
    { "Item" : "Poster Paint" },
    { $set: { "Colors": ["Red","Green","Blue","Orange","Black"] } }
)
```

Ergebnisse dieser Operation sehen in etwa folgendermaßen aus.

```
{
    "Item": "Poster Paint",
    "Colors": ["Red","Green","Blue","Orange","Black"],
    "Inventory": {
        "OnHand": 47,
        "MinOnHand": 50 
    }
}
```

### Ein neues Feld hinzufügen
<a name="document-database-updating-adding-field"></a>

Um ein Dokument durch Hinzufügen eines oder mehrerer neuer Felder zu ändern, verwenden Sie die Operation `update()` mit einem Abfragedokument, das das einzufügende Dokument und die neuen Felder und Werte, die mit dem Operator `$set` eingefügt werden sollen, identifiziert.

Im folgenden Beispiel wird das Feld `UnitPrice` mit dem Wert `3.99` dem Dokument "Spray Paints" hinzugefügt. Beachten Sie, dass der Wert `3.99` numerisch ist und keine Zeichenfolge.

```
db.example.update(
    { "Item": "Spray Paint" },
    { $set: { "UnitPrice": 3.99 } } 
)
```

Die Ergebnisse dieser Operation sehen ungefähr wie folgt aus (JSON-Format).

```
{
    "Item": "Spray Paint",
    "Colors": ["Black","Red","Green","Blue"],
    "Inventory": {
        "OnHand": 47,
        "MinOnHand": 50,
        "OrderQnty": 36
    },
    "UnitPrice": 3.99
}
```

### Ein eingebettetes Dokument ersetzen
<a name="document-database-replacing-embedded-document"></a>

Um ein Dokument durch Ersetzen eines eingebetteten Dokuments zu ändern, verwenden Sie die Operation `update()` mit Dokumenten, die das eingebettete Dokument und seine neuen Felder und Werte mit dem Operator `$set` identifizieren.

Anhand des folgenden Dokuments

```
db.example.insert({
    "DocName": "Document 1",
    "Date": {
        "Year": 1987,
        "Month": 4,
        "Day": 18
    }
})
```

**So ersetzen Sie ein eingebettetes Dokument**  
Im folgenden Beispiel wird das aktuellen Datumsdokument durch ein neues ersetzt, das nur die Felder `Month` und `Day` besitzt; `Year` wurde entfernt.

```
db.example.update(
    { "DocName" : "Document 1" },
    { $set: { "Date": { "Month": 4, "Day": 18 } } }
)
```

Ergebnisse dieser Operation sehen in etwa folgendermaßen aus.

```
{
    "DocName": "Document 1",
    "Date": {
        "Month": 4,
        "Day": 18
    }
}
```

### Neue Felder in ein eingebettetes Dokument einfügen
<a name="document-database-updating-adding-field-embedded"></a>

**So fügen Sie einem eingebetteten Dokument neue Felder hinzu**  
Um ein Dokument durch Hinzufügen eines oder mehrerer neuer Felder zu einem eingebetteten Dokument zu ändern, verwenden Sie die Operation `update()` mit Dokumenten, die das eingebettete Dokument identifizieren, und "Punktnotation" zum Angeben des eingebetteten Dokuments und der neuen Felder und Werte verwenden, die mit dem Operator `$set` eingefügt werden sollen.

Beim folgenden Dokument verwendet der folgende Code "Punktnotierung", um die Felder `DoW` und `Year` im eingebetteten `Date`-Dokument und `Words` im übergeordneten Dokument einzufügen.

```
{
    "DocName": "Document 1",
    "Date": {
        "Month": 4,
        "Day": 18
    }
}
```

```
db.example.update(
    { "DocName" : "Document 1" },
    { $set: { "Date.Year": 1987, 
              "Date.DoW": "Saturday",
              "Words": 2482 } }
)
```

Ergebnisse dieser Operation sehen in etwa folgendermaßen aus.

```
{
    "DocName": "Document 1",
    "Date": {
        "Month": 4,
        "Day": 18,
        "Year": 1987,
        "DoW": "Saturday"
    },
    "Words": 2482
}
```

### Ein Feld aus einem Dokument entfernen
<a name="document-database-remove-field"></a>

Um ein Dokument zu ändern, indem Sie ein Feld aus dem Dokument entfernen, verwenden Sie die Operation `update()` mit einem Abfragedokument, das das Dokument identifiziert, aus dem das Feld entfernt werden soll, und den Operator `$unset`, um das zu entfernende Feld anzugeben.

Das folgende Beispiel entfernt das Feld `Words` aus dem vorangegangen Dokument.

```
db.example.update(
    { "DocName" : "Document 1" },
    { $unset: { Words:1 } }
)
```

Ergebnisse dieser Operation sehen in etwa folgendermaßen aus.

```
{
    "DocName": "Document 1",
    "Date": {
        "Month": 4,
        "Day": 18,
        "Year": 1987,
        "DoW": "Saturday"
    }
}
```

### Ein Feld aus mehreren Dokumenten entfernen
<a name="document-database-remove-field-all"></a>

Um ein Dokument zu ändern, indem ein Feld aus mehreren Dokumenten entfernt wird, verwenden Sie die Operation `update()` mit dem Operator `$unset` und der Option `multi`, die auf `true` festgelegt ist.

Im folgenden Beispiel wird das Feld `Inventory` aus allen Dokumenten in der Beispielsammlung entfernt. Wenn ein Dokument das Feld `Inventory` nicht hat, wird keine Aktion für dieses Dokument durchgeführt. Wenn `multi: true` weggelassen wird, wird die Aktion nur für das erste Dokument ausgeführt, das das Kriterium erfüllt.

```
db.example.update(
    {},
    { $unset: { Inventory:1 } },
    { multi: true }
)
```

## Dokumente löschen
<a name="document-database-deleting"></a>

Um ein Dokument aus Ihrer Datenbank zu entfernen, verwenden Sie die Operation `remove()` und geben Sie an, welches Dokument Sie entfernen möchten. Der folgende Code entfernt "Gel Pen" aus Ihrer `example`-Sammlung.

```
db.example.remove( { "Item": "Gel Pen" } )
```

Um alle Dokumente aus Ihrer Datenbank zu entfernen, verwenden Sie den `remove()` Vorgang mit einer leeren Abfrage.

```
db.example.remove( { } )
```