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.

Bewährte Methoden für Amazon DocumentDB

Lernen Sie bewährte Methoden für die Arbeit mit Amazon DocumentDB (mit MongoDB-Kompatibilität) kennen. Dieser Abschnitt wird fortlaufend aktualisiert, wenn neue bewährte Methoden identifiziert werden.

Grundlegende Anleitungen für den Betrieb

Im Folgenden finden Sie grundlegende Betriebsrichtlinien, die jeder bei der Arbeit mit Amazon DocumentDB beachten sollte. Das Amazon DocumentDB Service Level Agreement verlangt, dass Sie diese Richtlinien befolgen.

Dimensionierung der Instanzen

Einer der wichtigsten Aspekte bei der Auswahl einer Instance-Größe in Amazon DocumentDB ist die Größe des Arbeitsspeichers für Ihren Cache. Amazon DocumentDB reserviert ein Drittel des RAM für seine eigenen Dienste, was bedeutet, dass nur zwei Drittel des Instance-RAM für den Cache verfügbar sind. Daher ist es eine bewährte Methode von Amazon DocumentDB, einen Instance-Typ auszuwählen, der über ausreichend RAM verfügt, damit Ihr Arbeitssatz (d. h. Daten und Indizes) im Arbeitsspeicher Platz findet. Durch die richtige Größe von Instances wird die Gesamtleistung optimiert und die E/A-Kosten möglicherweise minimiert. Sie können den Amazon DocumentDB DocumentDB-Größenrechner eines Drittanbieters verwenden, um die Instance-Größe für einen bestimmten Workload zu schätzen.

Um festzustellen, ob das Arbeitssatz Ihrer Anwendung in den Arbeitsspeicher passt, überwachen BufferCacheHitRatio Sie die Nutzung von Amazon CloudWatch für jede Instanz in einem Cluster, die unter Last steht.

Die BufferCacheHitRatio CloudWatch Metrik misst den Prozentsatz der Daten und Indizes, die aus dem Speichercache einer Instance bereitgestellt werden (im Vergleich zum Speichervolumen). Im Allgemeinen sollte der Wert von BufferCacheHitRatio so hoch wie möglich sein, da das Lesen von Daten aus dem Arbeitssatz-Speicher schneller und kostengünstiger ist als das Lesen vom Speicher-Volume. Obwohl es wünschenswert ist, BufferCacheHitRatio möglichst nahe bei 100% zu halten, hängt der beste erreichbare Wert von den Zugriffsmustern und den Leistungsanforderungen Ihrer Anwendung ab. Um das höchstmögliche BufferCacheHitRatio beizubehalten, wird empfohlen, dass die Instances in Ihrem Cluster über ausreichend RAM verfügen, damit Ihre Indizes und Arbeitsdatensätze in den Speicher passen.

Wenn Ihre Indizes nicht in den Speicher passen, wird Ihnen ein niedrigeres BufferCacheHitRatio angezeigt. Kontinuierliches Lesen von der Festplatte verursacht zusätzliche I/O-Kosten und ist nicht besser als das Lesen aus dem Arbeitsspeicher. Wenn Ihr BufferCacheHitRatio-Verhältnis niedriger als erwartet ist, skalieren Sie die Instance-Größe für Ihren Cluster, um mehr RAM zur Verfügung zu stellen, damit die Arbeitssatzdaten in den Speicher passen. Wenn das Skalieren der Instance-Klasse zu einem enormen Anstieg im BufferCacheHitRatio führt, passte der Arbeitssatz Ihrer Anwendung nicht in den Speicher. Skalieren Sie weiter, bis sich BufferCacheHitRatio nach einer Skalierungsoperation nicht mehr drastisch erhöht. Weitere Informationen zur Überwachung von Instance-Metriken finden Sie unter Amazon DocumentDB-Metriken.

Abhängig von Ihren Workload- und Latenzanforderungen kann es akzeptabel sein, dass Ihre Anwendung während der stabilen Zustandsnutzung höhere BufferCacheHitRatio-Werte aufweist, das BufferCacheHitRatio jedoch periodisch nachlässt, da analytische Abfragen, die eine gesamte Sammlung scannen müssen, auf einer Instance ausgeführt werden. Diese periodischen Einbrüche im BufferCacheHitRatio können sich als höhere Latenz für nachfolgende Abfragen manifestieren, die die Arbeitssatzdaten aus dem Speicher-Volume wieder in den Puffercache füllen müssen. Es wird empfohlen, Ihre Workloads zunächst in einer Vorproduktionsumgebung mit einem repräsentativen Produktions-Workload zu testen, um die Leistungsmerkmale und das BufferCacheHitRatio zu verstehen, bevor Sie den Workload für die Produktion bereitstellen.

Es handelt sich beim BufferCacheHitRatio um eine Instance-spezifische Metrik, daher können verschiedene Instances innerhalb desselben Clusters unterschiedliche BufferCacheHitRatio-Werte aufweisen, je nachdem, wie Lesevorgänge auf die Primär- und Replikat-Instances verteilt werden. Wenn Ihr betrieblicher Workload nicht mit periodischen Erhöhungen der Latenz durch erneutes Auffüllen des Arbeitssatzcache nach dem Ausführen analytischer Abfragen umgehen kann, sollten Sie versuchen, den Puffercache des regulären Workloads von dem der analytischen Abfragen zu isolieren. Sie können eine vollständige BufferCacheHitRatio-Isolation erreichen, indem Sie betriebliche Abfragen an die Primär-Instance und analytische Abfragen nur an die Replikat-Instances weiterleiten. Sie können auch eine partielle Isolation erreichen, indem Sie analytische Abfragen an eine bestimmte Replikat-Instance weiterleiten, mit dem Verständnis, dass ein gewisser Prozentsatz der regulären Abfragen auch auf diesem Replikat ausgeführt wird und möglicherweise betroffen sein könnte.

Angemessene BufferCacheHitRatio-Werte hängen von Ihrem Anwendungsfall und Ihren Anwendungsanforderungen ab. Es gibt keinen besten oder minimalen Wert für diese Metrik. Nur Sie können entscheiden, ob der Kompromiss von einem vorübergehend niedrigeren BufferCacheHitRatio aus Kosten- und Leistungsperspektive akzeptabel ist.

Arbeiten mit Indizes

Erstellen von Indizes

Wenn Sie Daten in Amazon DocumentDB importieren, sollten Sie Ihre Indizes erstellen, bevor Sie große Datensätze importieren. Sie können das Amazon DocumentDB Index Tool verwenden, um Indizes aus einer laufenden MongoDB-Instance oder einem mongodump Verzeichnis zu extrahieren und diese Indizes in einem Amazon DocumentDB-Cluster zu erstellen. Weitere Hinweise zu Migrationen finden Sie unter Migration zu Amazon DocumentDB.

Index-Selektivität

Wir empfehlen Ihnen, die Erstellung von Indizes auf Felder zu beschränken, bei denen die Anzahl der Duplikatwerte weniger als 1 % der Gesamtzahl der Dokumente in der Sammlung beträgt. Wenn Ihre Sammlung beispielsweise 100.000 Dokumente enthält, erstellen Sie Indizes nur für Felder, in denen derselbe Wert 1.000 Mal oder weniger vorkommt.

Die Wahl eines Index mit einer hohen Anzahl von eindeutigen Werten (d. h. einer hohen Kardinalität) gewährleistet, dass Filteroperationen eine geringe Anzahl von Dokumenten zurückgeben, wodurch eine gute Leistung während der Index-Scans erzielt wird. Ein Beispiel für einen Index hoher Kardinalität ist ein einzigartiger Index, der garantiert, dass Gleichheitsprädikate höchstens ein einziges Dokument zurückgeben. Beispiele für niedrige Kardinalität sind ein Index über ein boolesches Feld und ein Index über einen Wochentag. Aufgrund ihrer schlechten Leistung ist es unwahrscheinlich, dass der Abfragenoptimierer der Datenbank Indizes mit niedriger Kardinalität auswählt. Gleichzeitig verbrauchen Indizes mit niedriger Kardinalität weiterhin Ressourcen wie Plattenplatz und E/A-Vorgänge. Als Faustregel gilt, dass Sie Indizes für Felder verwenden sollten, bei denen die typische Wertehäufigkeit 1 % der Gesamtsammlungsgröße oder weniger beträgt.

Darüber hinaus wird empfohlen, nur Indizes für Felder zu erstellen, die häufig als Filter verwendet werden, und regelmäßig nach nicht verwendeten Indizes zu suchen. Weitere Informationen finden Sie unter Wie analysiere ich die Indexnutzung und identifiziere ungenutzte Indizes?.

Einfluss von Indizes auf das Schreiben von Daten

Zwar können Indizes die Abfrageleistung verbessern, da nicht jedes Dokument in einer Sammlung gescannt werden muss, diese Verbesserung erfordert jedoch einen Kompromiss. Für jeden Index einer Sammlung muss die Datenbank jedes Mal, wenn ein Dokument eingefügt, aktualisiert oder gelöscht wird, die Sammlung aktualisieren und die Felder in jeden der Indizes für die Sammlung schreiben. Wenn eine Sammlung beispielsweise über neun Indizes verfügt, muss die Datenbank zehn Schreibvorgänge durchführen, bevor die Operation dem Kunden bestätigt wird. Daher verursacht jeder zusätzliche Index zusätzliche Schreiblatenz, E/As und eine Erhöhung des insgesamt genutzten Speichers.

Cluster-Instances müssen über eine angemessene Größe verfügen, um den gesamten Arbeitsspeicher zu erhalten. Dadurch wird vermieden, dass ständig Indexseiten aus dem Speichervolumen gelesen werden müssen, was sich negativ auf die Leistung auswirkt und höhere E/A-Kosten verursacht. Weitere Informationen finden Sie unter Dimensionierung der Instanzen.

Um eine optimale Leistung zu erzielen, sollten Sie die Anzahl der Indizes in Ihren Sammlungen minimieren und nur die Indizes hinzufügen, die zur Verbesserung der Leistung bei häufigen Abfragen erforderlich sind. Bei variierenden Workloads gilt als gute Richtschnur, die Anzahl der Indizes pro Sammlung auf fünf oder weniger zu beschränken.

Identifizierung fehlender Indizes

Die Identifizierung fehlender Indizes ist eine bewährte Methode, die wir empfehlen, regelmäßig durchzuführen. Weitere Informationen finden Sie unter Wie identifiziere ich fehlende Indizes?.

Identifizieren ungenutzter Indizes

Da das Identifizieren und Löschen fehlender Indizes eine bewährte Vorgehensweise ist, empfiehlt sich eine regelmäßige Durchführung. Weitere Informationen finden Sie unter Wie analysiere ich die Indexnutzung und identifiziere ungenutzte Indizes?.

Bewährte Methoden für die Gewährleistung der Sicherheit

Aus Sicherheitsgründen müssen Sie AWS Identity and Access Management (IAM-) Konten verwenden, um den Zugriff auf Amazon DocumentDB DocumentDB-API-Operationen zu kontrollieren, insbesondere Operationen, die Amazon DocumentDB DocumentDB-Ressourcen erstellen, ändern oder löschen. Zu solchen Ressourcen gehören Cluster, Sicherheitsgruppen und Parametergruppen. Sie müssen IAM auch zur Steuerung von Aktionen verwenden, mit denen allgemeine Verwaltungsaktionen wie das Sichern und Wiederherstellen von Clustern ausgeführt werden. Verwenden Sie bei der Erstellung von IAM-Rollen das Prinzip der geringsten Rechte.

Kostenoptimierung

Die folgenden bewährten Methoden können Ihnen helfen, Ihre Kosten bei der Verwendung von Amazon DocumentDB zu verwalten und zu minimieren. Preisinformationen finden Sie unter Amazon DocumentDB (mit MongoDB-Kompatibilität) und Amazon DocumentDB (mit MongoDB-Kompatibilität). FAQs

Verwendung von Metriken zur Identifizierung von Problemen mit der Leistung

Um Leistungsprobleme zu identifizieren, die durch unzureichende Ressourcen und andere häufige Engpässe verursacht werden, können Sie die für Ihren Amazon DocumentDB-Cluster verfügbaren Metriken überwachen.

Anzeigen von Leistungsmetriken

Überwachen Sie die Leistungsmetriken regelmäßig, um die Durchschnitts-, Höchst- und Mindestwerte für verschiedene Zeitbereiche anzuzeigen. Auf diese Weise können Sie feststellen, wenn die Leistung nachlässt. Sie können CloudWatch Amazon-Alarme auch für bestimmte Metrik-Schwellenwerte einrichten, sodass Sie benachrichtigt werden, wenn diese erreicht werden.

Um Probleme mit der Leistung zu beheben, müssen Sie die Basisleistung des Systems kennen. Nachdem Sie einen neuen Cluster eingerichtet haben und er mit einer typischen Workload ausgeführt wird, erfassen Sie die Durchschnitts-, Höchst- und Mindestwerte aller Leistungsmetriken in unterschiedlichen Intervallen (z. B. 1 Stunde, 24 Stunden, 1 Woche, 2 Wochen). Auf diese Weise erhalten Sie eine Vorstellung davon, was normal ist. Dies hilft, um Vergleichswerte für Betriebsstunden während und außerhalb von Spitzenbelastungen zu erhalten. Sie können diese Informationen anschließend verwenden, um festzustellen, wann die Leistung unter Standardwerte absinkt.

Sie können Leistungskennzahlen mit dem AWS Management Console oder anzeigen. AWS CLI Weitere Informationen finden Sie unter CloudWatch Daten anzeigen.

Einen CloudWatch Alarm einrichten

Informationen zum Einstellen eines CloudWatch Alarms finden Sie unter Verwenden von Amazon CloudWatch Alarms im CloudWatch Amazon-Benutzerhandbuch.

Auswerten von Leistungsmetriken

Eine Instance besitzt mehrere unterschiedliche Kategorien von Metriken. Die Art und Weise, wie Sie bestimmen, welche Werte akzeptabel sind, ist von der Metrik abhängig.

Allgemein ausgedrückt, sind die zulässigen Werte für Leistungsmetriken davon abhängig, wie die Basisleistung aussieht und welche Aufgaben von Ihrer Anwendung ausgeführt werden. Prüfen Sie, ob dauerhafte oder tendenzielle Abweichungen von Ihrer Ausgangsbasis vorliegen.

Nachstehend folgen Empfehlungen und Ratschläge zu bestimmten Arten von Metriken:

Wenn Ihre Abfragen optimiert sind und ein Problem weiterhin besteht, sollten Sie ein Upgrade Ihrer Amazon DocumentDB DocumentDB-Instance-Klasse auf eine Klasse mit mehr Ressourcen (CPU, RAM, Festplattenspeicher, Netzwerkbandbreite, I/O-Kapazität) in Betracht ziehen, die mit dem aufgetretenen Problem zusammenhängen.

Auswertung der Nutzung von Amazon DocumentDB DocumentDB-Instances anhand von Metriken CloudWatch

Mithilfe von CloudWatch Metriken können Sie Ihren Instance-Durchsatz beobachten und herausfinden, ob Ihre Instance-Klasse ausreichend Ressourcen für Ihre Anwendungen bereitstellt. Informationen zu Ihren Instance-Klassenlimits finden Sie in den Spezifikationen für Ihre Instance-Klasse, um Ihre Netzwerkleistung zu ermitteln. Instance-Limits

Wenn Ihre Instance-Nutzung nahe dem Instance-Klassenlimit liegt, kann es sein, dass sich die Leistung verlangsamt. Die CloudWatch Metriken können diese Situation bestätigen, sodass Sie planen können, manuell auf eine größere Instance-Klasse hochzuskalieren.

Kombinieren Sie die folgenden CloudWatch Metrikwerte, um herauszufinden, ob Sie sich dem Instance-Klassenlimit nähern:

Fügen Sie den hinzu NetworkThroughput, um den Netzwerkdurchsatz StorageNetworkThroughputzu ermitteln, der von jeder Instance in Ihrem Amazon DocumentDB-Cluster vom Amazon DocumentDB-Cluster empfangen und an das Amazon DocumentDB-Cluster gesendet wurde. Das Instance-Klassenlimit für Ihre Instance sollte größer sein als die Summe dieser beiden kombinierten Metriken.

Sie können die folgenden Metriken verwenden, um zusätzliche Details des Netzwerkverkehrs Ihrer Client-Anwendungen beim Senden und Empfangen zu überprüfen:

Addieren Sie all diese Metriken, um zu bewerten, wie Ihre Netzwerknutzung im Vergleich zum Instance-Klassenlimit abschneidet. Das Instance-Klassenlimit sollte größer sein als die Summe dieser kombinierten Metriken.

Die Netzwerklimits und die CPU-Auslastung einer Instance sind wechselseitig. Wenn der Netzwerkdurchsatz steigt, steigt auch die CPU-Auslastung. Die Überwachung der CPU- und Netzwerknutzung gibt Aufschluss darüber, wie und warum die Ressourcen erschöpft werden.

Sie können Folgendes in Betracht ziehen, um die Netzwerknutzung zu minimieren:

Optimieren von Abfragen

Eine der besten Möglichkeiten zur Verbesserung der Cluster-Leistung besteht darin, die am häufigsten verwendeten und ressourcenintensivsten Abfragen so anzupassen, dass ihre Ausführung weniger aufwändig wird.

Mit dem Profiler (siehe Profilierung von Amazon DocumentDB DocumentDB-Vorgängen) können Sie die Ausführungszeit und Details der Vorgänge protokollieren, die für Ihren Cluster ausgeführt wurden. Profiler ist nützlich für die Überwachung der langsamsten Operationen in Ihrem Cluster, um die Leistung einzelner Abfragen und die allgemeine Cluster-Leistung zu verbessern.

Sie können den Befehl explain auch verwenden, um zu erfahren, wie ein Abfrageplan für eine bestimmte Abfrage analysiert wird. Mithilfe dieser Informationen können Sie eine Abfrage oder zugrundeliegende Sammlung ändern, um die Abfrageleistung zu verbessern (z. B. Hinzufügen eines Indexes).

TTL- und Zeitreihen-Workloads

Das Löschen von Dokumenten, das aus dem Ablauf des TTL-Index resultiert, ist ein hochaufwendiges Verfahren. Es wird nicht garantiert, dass Dokumente innerhalb eines bestimmten Zeitraums gelöscht werden. Faktoren wie die Größe der Instance, die Ressourcenauslastung der Instance, die Dokumentgröße, der Gesamtdurchsatz, die Anzahl der Indizes und die Frage, ob die Indizes und der Arbeitssatz in den Speicher passen, können den Zeitpunkt beeinflussen, zu dem abgelaufene Dokumente durch den TTL-Prozess gelöscht werden.

Wenn der TTL-Monitor Ihre Dokumente löscht, entstehen bei jeder Löschung E/A-Kosten, was den Rechnungsbetrag erhöht. Wenn der Durchsatz und die TTL-Löschraten steigen, müssen Sie aufgrund der erhöhten E/A-Nutzung mit einer höheren Rechnung rechnen. Wenn Sie jedoch keinen TTL-Index zum Löschen von Dokumenten erstellen, sondern Dokumente anhand der Zeit in Sammlungen unterteilen und diese Sammlungen einfach löschen, wenn sie nicht mehr benötigt werden, entstehen Ihnen keine I/O-Kosten. Dies kann erheblich kostengünstiger sein als die Verwendung eines TTL-Index.

Für Zeitreihen-Workloads können Sie erwägen, statt eines TTL-Indexes fortlaufende Sammlungen zu erstellen, da rollierende Sammlungen eine bessere Methode zum Löschen von Daten sein können und weniger I/O-intensiv sind. Wenn Sie große Sammlungen haben (insbesondere Sammlungen mit mehr als 1 TB) oder die E/A-Kosten für das TTL-Löschen ein Problem darstellen, empfiehlt es sich, Dokumente basierend auf der Zeit in Sammlungen zu partitionieren und Sammlungen zu löschen, wenn die Dokumente nicht mehr benötigt werden. Sie können eine Sammlung pro Tag oder eine Sammlung pro Woche erstellen, abhängig von der Datenaufnahmerate. Bei je nach Anwendung variierenden Anforderungen gilt als gute Faustregel, besser über mehr kleinere Sammlungen als über einige große Sammlungen zu verfügen. Das Löschen dieser Sammlungen verursacht keine E/A-Kosten und kann schneller und kostengünstiger sein als die Verwendung eines TTL-Index.

Migrationen

Als bewährte Methode empfehlen wir, dass Sie bei der Migration von Daten zu Amazon DocumentDB zuerst Ihre Indizes in Amazon DocumentDB erstellen, bevor Sie die Daten migrieren. Indizes zuerst zu erstellen, kann die Gesamtzeit verkürzen und die Geschwindigkeit der Migration erhöhen. Dazu können Sie das Amazon DocumentDB Index Tool verwenden. Weitere Informationen zu Migrationen finden Sie im Amazon DocumentDB-Migrationsleitfaden.

Wir empfehlen außerdem, Ihre Anwendung vor der Migration Ihrer Produktionsdatenbank vollständig auf Amazon DocumentDB zu testen und dabei Funktionalität, Leistung, Betrieb und Kosten zu berücksichtigen.

Arbeiten mit Cluster-Parametergruppen

Es wird empfohlen, Änderungen an Cluster-Parametergruppen zuerst an einem Test-Cluster auszuprobieren, bevor Sie die Änderungen auf Ihre Produktions-Cluster anwenden. Weitere Informationen zum Sichern Ihres Clusters finden Sie unter Sichern und Wiederherstellen in Amazon DocumentDB.

Abfragen in der Aggregationspipeline

Wenn Sie eine Aggregation-Pipeline-Abfrage mit mehreren Stufen erstellen und nur eine Teilmenge der Daten in der Abfrage auswerten, verwenden Sie die $match-Stufe als erste Stufe oder am Anfang der Pipeline. Wenn Sie $match zuerst verwenden, wird die Anzahl der Dokumente reduziert, die nachfolgende Stufen innerhalb der Aggregation-Pipeline-Abfrage verarbeiten müssen, wodurch die Leistung Ihrer Abfrage verbessert wird.

batchInsert und batchUpdate

Wenn Sie eine hohe Anzahl an gleichzeitigen batchUpdate Vorgängen batchInsert und/oder Vorgängen ausführen und die Anzahl von FreeableMemory (CloudWatch Metric) auf Ihrer primären Instance auf Null sinkt, können Sie entweder die Parallelität der Batch-Insert- oder Aktualisierungs-Workloads reduzieren oder, falls die Gleichzeitigkeit der Arbeitslast nicht reduziert werden kann, die Instance-Größe erhöhen, um die Menge von zu erhöhen. FreeableMemory