Wählen Sie Ihre Cookie-Einstellungen aus

Wir verwenden essentielle Cookies und ähnliche Tools, die für die Bereitstellung unserer Website und Services erforderlich sind. Wir verwenden Performance-Cookies, um anonyme Statistiken zu sammeln, damit wir verstehen können, wie Kunden unsere Website nutzen, und Verbesserungen vornehmen können. Essentielle Cookies können nicht deaktiviert werden, aber Sie können auf „Anpassen“ oder „Ablehnen“ klicken, um Performance-Cookies abzulehnen.

Wenn Sie damit einverstanden sind, verwenden AWS und zugelassene Drittanbieter auch Cookies, um nützliche Features der Website bereitzustellen, Ihre Präferenzen zu speichern und relevante Inhalte, einschließlich relevanter Werbung, anzuzeigen. Um alle nicht notwendigen Cookies zu akzeptieren oder abzulehnen, klicken Sie auf „Akzeptieren“ oder „Ablehnen“. Um detailliertere Entscheidungen zu treffen, klicken Sie auf „Anpassen“.

Evaluieren Sie Ihre DynamoDB-Tabellennutzungsmuster

Fokusmodus
Evaluieren Sie Ihre DynamoDB-Tabellennutzungsmuster - Amazon-DynamoDB

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.

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.

In diesem Abschnitt erfahren Sie, wie Sie prüfen können, ob Sie Ihre DynamoDB-Tabellen effizient nutzen. Gewisse Nutzungsmuster sind für DynamoDB nicht optimal und bieten sowohl mit Blick auf die Leistung als auch auf die Kosten Raum für Optimierungen.

Ausführen von weniger strikt konsistenten Lesevorgängen

In DynamoDB können Sie Lesekonsistenz für jede Anfrage konfigurieren. Leseanforderungen sind standardmäßig letztendlich konsistent. Letztendlich konsistente Lesevorgänge werden mit 0,5 RCU für bis zu 4 KB Daten berechnet.

Die meisten Teile von verteilten Workloads sind flexibel und können letztendliche Konsistenz tolerieren. Es kann jedoch Zugriffsmuster geben, die strikt konsistente Lesevorgänge erfordern. Strikt konsistente Lesevorgänge werden mit 1 RCU für bis zu 4 KB Daten berechnet, sodass sich Ihre Lesekosten im Prinzip verdoppeln. DynamoDB bietet Ihnen die Flexibilität, beide Konsistenzmodelle in derselben Tabelle zu verwenden.

Durch Auswertung Ihres Workloads und Anwendungscodes können Sie prüfen, ob strikt konsistente Lesevorgänge nur bei Bedarf verwendet werden.

Ausführen von weniger Transaktionen für Lesevorgänge

DynamoDB ermöglicht es Ihnen, bestimmte Aktionen auf eine all-or-nothing Weise zu gruppieren, was bedeutet, dass Sie ACID-Transaktionen mit DynamoDB ausführen können. Wie bei relationalen Datenbanken ist es jedoch nicht notwendig, dieses Vorgehen für jede Aktion zu befolgen.

Ein transaktionaler Lesevorgang von bis zu 4 KB verbraucht 2 KB im Gegensatz zu den RCUs Standardwerten von 0,5, wenn dieselbe Datenmenge RCUs letztendlich konsistent gelesen werden soll. Bei Schreibvorgängen verdoppeln sich die Kosten, was bedeutet, dass ein transaktionaler Schreibvorgang von bis zu 1 KB 2 entspricht. WCUs

Um festzustellen, ob es sich bei allen Vorgängen in Ihren Tabellen um Transaktionen handelt, können die CloudWatch Metriken für die Tabelle bis zur Transaktion gefiltert werden. APIs Wenn Transaktionen die einzigen Grafiken APIs sind, die unter den SuccessfulRequestLatency Metriken für die Tabelle verfügbar sind, würde dies bestätigen, dass es sich bei jeder Operation um eine Transaktion für diese Tabelle handelt. Wenn der allgemeine Trend der Kapazitätsauslastung mit dem Trend der Transaktions-API übereinstimmt, sollten Sie alternativ erwägen, das Anwendungsdesign zu überdenken, da es offenbar von Transaktionen APIs dominiert wird.

Ausführen von weniger Scans

Die häufige Verwendung von Scan-Operationen ist im Allgemeinen auf die Notwendigkeit von analytischen Abfragen der DynamoDB-Daten zurückzuführen. Wenn häufig Scan-Operationen in großen Tabellen ausgeführt werden, kann dies ineffizient und teuer sein.

Eine bessere Alternative besteht darin, die Funktion Nach S3 exportieren zu verwenden und einen Zeitpunkt für den Export des Tabellenstatus nach S3 auszuwählen. AWS bietet Dienste wie Athena, mit denen dann analytische Abfragen der Daten ausgeführt werden können, ohne Kapazität aus der Tabelle zu verbrauchen.

Die Häufigkeit von Scan-Operationen kann mithilfe der SampleCount-Statistik unter der Metrik SuccessfulRequestLatency für Scan bestimmt werden. Wenn tatsächlich sehr häufig Scan-Operationen stattfinden, sollten die Zugriffsmuster und das Datenmodell neu bewertet werden.

Verkürzen von Attributnamen

Die Gesamtgröße eines Elements in DynamoDB ist die Summe seiner Attributnamenlängen und Werte. Lange Attributnamen tragen nicht nur zu den Speicherkosten bei, sondern können auch zu einem höheren RCU/WCU consumption. We recommend that you choose shorter attribute names rather than long ones. Having shorter attribute names can help limit the item size within the next 4KB/1KB boundary after which you would consume additional RCU/WCU Datenzugriff führen.

Aktivieren von Time to Live (TTL)

Time to Live (TTL) kann Elemente ermitteln, die älter als die von Ihnen für ein Element festgelegte Ablaufzeit sind, und diese aus der Tabelle entfernen. Wenn Ihre Datenmenge im Laufe der Zeit wächst und ältere Daten irrelevant werden, können Sie durch die Aktivierung von TTL in der Tabelle die Datenmenge reduzieren und Speicherkosten sparen.

Ein weiterer nützlicher Aspekt von TTL ist, dass sich die abgelaufenen Elemente in Ihren DynamoDB-Streams befinden. Anstatt die Daten einfach aus Ihren Daten zu entfernen, ist es möglich, diese Elemente aus dem Datenstrom zu verwenden und in einer kostengünstigeren Speicherebene zu archivieren. Darüber hinaus fallen für das Löschen von Objekten über TTL keine zusätzlichen Kosten an – es wird keine Kapazität verbraucht und es entsteht kein Aufwand für die Entwicklung einer Bereinigungsanwendung.

Ersetzen von globalen Tabellen durch regionsübergreifende Sicherungen

Durch die Verwendung von globalen Tabellen können Sie mehrere aktive Replikattabellen in verschiedenen Regionen unterhalten. Sie alle können Schreibvorgänge akzeptieren und Daten untereinander replizieren. Replikate lassen sich einfach einrichten und die Synchronisation wird für Sie verwaltet. Die Replikate nähern sich unter Verwendung einer Strategie „Wer zuletzt schreibt, gewinnt“ einem konsistenten Zustand an.

Wenn Sie globale Tabellen ausschließlich im Rahmen einer Failover- oder Notfallwiederherstellungsstrategie verwenden, können Sie sie durch eine regionsübergreifende Sicherungskopie ersetzen, wenn die Anforderungen an die Recovery Point Objectives und Recovery Time Objectives relativ gering sind. Wenn Sie keinen schnellen lokalen Zugriff und eine hohe Verfügbarkeit von 99,999 % benötigen, ist die Unterhaltung eines Replikats einer globalen Tabelle möglicherweise nicht das beste Failover-Konzept.

Als Alternative sollten Sie die Verwendung von AWS Backup zur Verwaltung von DynamoDB-Backups in Betracht ziehen. Sie können regelmäßige Sicherungen planen und diese regionsübergreifend kopieren, um die Anforderungen an die Notfallwiederherstellung auf kostengünstigere Weise zu erfüllen als bei der Verwendung von globalen Tabellen.

DatenschutzNutzungsbedingungen für die WebsiteCookie-Einstellungen
© 2025, Amazon Web Services, Inc. oder Tochtergesellschaften. Alle Rechte vorbehalten.