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

Erfahren Sie mehr über bewährte Methoden für die Arbeit mit Amazon DocumentDB (mit MongoDB-Kompatibilität). 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 befolgen sollte. Das Amazon DocumentDB Service Level Agreement verlangt, dass Sie diese Richtlinien befolgen.

Dimensionierung der Instanz

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 Arbeitsspeichers 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 mit ausreichend RAM zu wählen, um Ihren Arbeitsspeicher (d. h. Daten und Indizes) im Arbeitsspeicher unterzubringen. Instances mit der richtigen Größe helfen dabei, die Gesamtleistung zu optimieren und potenziell die Kosten zu minimieren I/O . Sie können den Amazon DocumentDB-Größenrechner eines Drittanbieters verwenden, um die Instance-Größe für eine bestimmte Arbeitslast abzuschätzen.

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

Die BufferCacheHitRatio CloudWatch Metrik misst den Prozentsatz der Daten und Indizes, die aus dem Speicher-Cache 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 Speicher. 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. Testen Sie Ihre Workloads zunächst in einer Vorproduktionsumgebung mit einer repräsentativen Produktionsauslastung, um sich ein Bild von den Leistungsmerkmalen zu machen, und BufferCacheHitRatio 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

Indizes erstellen

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 und Aktualisierung von Amazon DocumentDB.

Index-Selektivität

Beschränken Sie die Indexerstellung auf Felder, bei denen die Anzahl der doppelten Werte 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 Speicherplatz und. I/Os 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?.

Auswirkung 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. Somit führt jeder zusätzliche Index zu einer zusätzlichen Schreiblatenz und einer Erhöhung des insgesamt genutzten I/O Speichers.

Cluster-Instances müssen über eine angemessene Größe verfügen, um den gesamten Arbeitsspeicher zu erhalten. Dadurch entfällt die Notwendigkeit, ständig Indexseiten vom Speichervolumen zu lesen, was sich negativ auf die Leistung auswirkt und höhere I/O Kosten verursacht. Weitere Informationen finden Sie unter Dimensionierung der Instanz.

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

Es hat sich bewährt, fehlende Indizes regelmäßig zu identifizieren. Weitere Informationen finden Sie unter Wie identifiziere ich fehlende Indizes?.

Identifizieren ungenutzter Indizes

Es hat sich bewährt, ungenutzte Indizes regelmäßig zu identifizieren und zu entfernen. Weitere Informationen finden Sie unter Wie analysiere ich die Indexnutzung und identifiziere ungenutzte Indizes?.

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

Bewährte Sicherheitsmethoden für Amazon DocumentDB finden Sie unter. Bewährte Sicherheitsmethoden für Amazon DocumentDB

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 Preise für Amazon DocumentDB (mit MongoDB-Kompatibilität) und häufig gestellte Fragen zu Amazon DocumentDB (mit MongoDB-Kompatibilität).

Verwendung von Metriken zur Identifizierung von Problemen mit der Leistung

Um Leistungsprobleme zu identifizieren, die durch unzureichende Ressourcen und andere häufig auftretende 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 mithilfe von oder anzeigen. AWS-Managementkonsole AWS CLI Weitere Informationen finden Sie unter CloudWatch Daten anzeigen.

Einen CloudWatch Alarm einstellen

Informationen zum Einstellen eines CloudWatch Alarms finden Sie unter Verwenden von CloudWatch Amazon-Alarmen 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 erwägen, Ihre Amazon DocumentDB-Instance-Klasse auf eine Klasse mit mehr Ressourcen (CPU, RAM, Festplattenspeicher, Netzwerkbandbreite, I/O Kapazität) zu aktualisieren, die mit dem aufgetretenen Problem zusammenhängt.

Bewertung der Nutzung der Amazon DocumentDB-Instance anhand von Metriken CloudWatch

Sie können CloudWatch Metriken verwenden, um Ihren Instance-Durchsatz zu beobachten und festzustellen, ob Ihre Instance-Klasse ausreichend Ressourcen für Ihre Anwendungen bereitstellt. Informationen zu Ihren Instance-Klassenkontingenten finden Sie in den Spezifikationen für Ihre Instance-Klasse, um Ihre Netzwerkleistung zu ermitteln. Kontingente für Instanzen

Wenn sich Ihre Instance-Nutzung dem Instance-Klassenlimit nähert, verlangsamt sich möglicherweise die Leistung. Die CloudWatch Metriken können diese Situation bestätigen, sodass Sie eine manuelle Skalierung auf eine größere Instance-Klasse planen können.

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 StorageNetworkThroughput zu ermitteln, der von jeder Instance in Ihrem Amazon DocumentDB-Cluster vom Amazon DocumentDB-Cluster empfangen und an das Amazon DocumentDB-Cluster-Speicher-Volume 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 durch eine Instance beruhen auf Gegenseitigkeit. 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-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, verursacht jedes Löschen I/O Kosten, was Ihre Rechnung erhöht. Wenn der Durchsatz und die TTL-Löschraten steigen, sollten Sie aufgrund der erhöhten Nutzung mit einer höheren Rechnung rechnen. I/O Wenn Sie jedoch keinen TTL-Index zum Löschen von Dokumenten erstellen, sondern Dokumente stattdessen nach Zeit in Sammlungen unterteilen und diese Sammlungen einfach löschen, wenn sie nicht mehr benötigt werden, fallen keine I/O-Kosten an. Dies kann erheblich kostengünstiger sein als die Verwendung eines TTL-Indexes.

Bei Zeitreihen-Workloads können Sie erwägen, fortlaufende Sammlungen anstelle eines TTL-Indexes zu erstellen, da rollierende Sammlungen eine bessere Methode zum Löschen von Daten sein können und weniger intensiv sind. I/O Wenn Sie große Sammlungen haben (insbesondere Sammlungen über 1 TB) oder wenn die I/O TTL-Löschkosten ein Problem darstellen, partitionieren Sie Dokumente nach Zeit in Sammlungen und löschen Sie Sammlungen, 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 I/O Kosten und kann schneller und kostengünstiger sein als die Verwendung eines TTL-Index.

Migrationen

Als bewährte Methode für die Migration von Daten zu Amazon DocumentDB sollten Sie zunächst Ihre Indizes in Amazon DocumentDB erstellen und dann Ihre 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. https://github.com/awslabs/amazon-documentdb-tools Weitere Informationen zu Migrationen finden Sie unter. Migration und Aktualisierung von Amazon DocumentDB

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

Testen Sie Änderungen an Cluster-Parametergruppen auf einem Testcluster, bevor Sie die Änderungen auf Ihre Produktionscluster anwenden. Weitere Informationen zum Sichern Ihres Clusters finden Sie unter Sichern und Wiederherstellen in Amazon DocumentDB.

Abfragen 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 gleichzeitiger batchInsert and/or batchUpdate Operationen ausführen und die Menge von FreeableMemory (CloudWatch Metric) auf Ihrer primären Instance auf Null geht, können Sie entweder die Parallelität des Batch-Insert- oder Aktualisierungs-Workloads reduzieren oder, falls die Parallelität des Workloads nicht reduziert werden kann, die Instance-Größe erhöhen, um den Umfang von zu erhöhen. FreeableMemory