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.

So schätzen Sie den Kapazitätsverbrauch des Lese- und Schreibdurchsatzes in Amazon Keyspaces ab

Wenn Sie Daten in Amazon Keyspaces lesen oder schreiben, hängt die Menge der Lese-/Schreibanforderungseinheiten (RRUs/WRUs) oder Lese-/Schreibkapazitätseinheiten (RCUs/WCUs), die Ihre Abfrage verbraucht, von der Gesamtmenge der Daten ab, die Amazon Keyspaces verarbeiten muss, um die Abfrage auszuführen. In einigen Fällen können die an den Client zurückgegebenen Daten eine Teilmenge der Daten sein, die Amazon Keyspaces lesen musste, um die Abfrage zu verarbeiten. Bei bedingten Schreibvorgängen verbraucht Amazon Keyspaces Schreibkapazität, auch wenn die bedingte Prüfung fehlschlägt.

Um die Gesamtmenge der für eine Anfrage verarbeiteten Daten abzuschätzen, müssen Sie die kodierte Größe einer Zeile und die Gesamtzahl der Zeilen berücksichtigen. In diesem Thema werden einige Beispiele für gängige Szenarien und Zugriffsmuster behandelt, um zu zeigen, wie Amazon Keyspaces Abfragen verarbeitet und wie sich dies auf den Kapazitätsverbrauch auswirkt. Sie können den Beispielen folgen, um den Kapazitätsbedarf Ihrer Tabellen abzuschätzen, und Amazon verwenden, CloudWatch um den Lese- und Schreibkapazitätsverbrauch für diese Anwendungsfälle zu beobachten.

Informationen zur Berechnung der codierten Zeilengröße in Amazon Keyspaces finden Sie unter. Berechnung der Zeilengröße in Amazon Keyspaces

Bereichsabfragen

Um den Lesekapazitätsverbrauch einer Bereichsabfrage zu untersuchen, verwenden wir die folgende Beispieltabelle, die den On-Demand-Kapazitätsmodus verwendet.

pk1 | pk2 | pk3 | ck1 | ck2 | ck3 | value
-----+-----+-----+-----+-----+-----+-------
a | b | 1 | a | b | 50 | <any value that results in a row size larger than 4KB>
a | b | 1 | a | b | 60 | value_1
a | b | 1 | a | b | 70 | <any value that results in a row size larger than 4KB>

Führen Sie nun die folgende Abfrage für diese Tabelle aus.

SELECT * FROM amazon_keyspaces.example_table_1 WHERE pk1='a' AND pk2='b' AND pk3=1 AND ck1='a' AND ck2='b' AND ck3 > 50 AND ck3 < 70;

Sie erhalten die folgende Ergebnismenge aus der Abfrage und der von Amazon Keyspaces ausgeführte Lesevorgang verbraucht 2 RRUs im LOCAL_QUORUM Konsistenzmodus.

pk1 | pk2 | pk3 | ck1 | ck2 | ck3 | value
-----+-----+-----+-----+-----+-----+-------
a | b | 1 | a | b | 60 | value_1

Amazon Keyspaces verwendet 2 RRUs, um die Zeilen mit den Werten auszuwerten ck3=60 und die Abfrage ck3=70 zu verarbeiten. Amazon Keyspaces gibt jedoch nur die Zeile zurück, in der die in der Abfrage angegebene WHERE Bedingung wahr ist, also die Zeile mit dem Wertck3=60. Um den in der Abfrage angegebenen Bereich auszuwerten, liest Amazon Keyspaces in diesem Fall die Zeile, die der Obergrenze des Bereichs entsprichtck3 = 70, gibt diese Zeile jedoch nicht im Ergebnis zurück. Der Lesekapazitätsverbrauch basiert auf den bei der Verarbeitung der Abfrage gelesenen Daten, nicht auf den zurückgegebenen Daten.

Abfragen einschränken

Bei der Verarbeitung einer Abfrage, die die LIMIT Klausel verwendet, liest Amazon Keyspaces Zeilen bis zur maximalen Seitengröße, wenn versucht wird, die in der Abfrage angegebene Bedingung zu erfüllen. Wenn Amazon Keyspaces nicht genügend passende Daten finden kann, die dem LIMIT Wert auf der ersten Seite entsprechen, sind möglicherweise ein oder mehrere paginierte Aufrufe erforderlich. Um mit dem Lesen auf der nächsten Seite fortzufahren, können Sie ein Paginierungstoken verwenden. Die Standardseitengröße ist 1 MB. Um bei der Verwendung von LIMIT Klauseln weniger Lesekapazität zu verbrauchen, können Sie die Seitengröße reduzieren. Weitere Hinweise zur Seitennummerierung finden Sie unter. Ergebnisse in Amazon Keyspaces paginieren

Schauen wir uns als Beispiel die folgende Abfrage an.

SELECT * FROM my_table WHERE partition_key=1234 LIMIT 1;”

Wenn Sie die Seitengröße nicht festlegen, liest Amazon Keyspaces 1 MB an Daten, obwohl es Ihnen nur 1 Zeile zurückgibt. Damit Amazon Keyspaces nur eine Zeile liest, können Sie die Seitengröße für diese Abfrage auf 1 setzen. In diesem Fall würde Amazon Keyspaces nur eine Zeile lesen, vorausgesetzt, Sie haben keine abgelaufenen Zeilen, die auf ime-to-live T-Einstellungen oder clientseitigen Zeitstempeln basieren. Um weniger Lesekapazität zu verbrauchen, empfehlen wir, Ihre Seitengröße auf den LIMIT Wert einzustellen, um die von Amazon Keyspaces gelesene Datenmenge zu reduzieren.

Tabellenscans

Abfragen, die zu vollständigen Tabellenscans führen, z. B. Abfragen, die die ALLOW FILTERING Option verwenden, sind ein weiteres Beispiel für Abfragen, die mehr Lesevorgänge verarbeiten, als sie als Ergebnisse zurückgeben. Und der Verbrauch an Lesekapazität basiert auf den gelesenen Daten, nicht auf den zurückgegebenen Daten.

Für das Beispiel für den Tabellenscan verwenden wir die folgende Beispieltabelle im On-Demand-Kapazitätsmodus.

pk | ck | value
---+----+---------
pk | 10 | <any value that results in a row size larger than 4KB>
pk | 20 | value_1 
pk | 30 | <any value that results in a row size larger than 4KB>

Amazon Keyspaces erstellt standardmäßig eine Tabelle im On-Demand-Kapazitätsmodus mit vier Partitionen. In dieser Beispieltabelle werden alle Daten in einer Partition gespeichert und die restlichen drei Partitionen sind leer.

Führen Sie nun die folgende Abfrage für die Tabelle aus.

SELECT * from amazon_keyspaces.example_table_2;

Diese Abfrage führt zu einem Tabellenscanvorgang, bei dem Amazon Keyspaces alle vier Partitionen der Tabelle scannt und im LOCAL_QUORUM Konsistenzmodus 6 RRUs verbraucht. Erstens verbraucht Amazon Keyspaces 3 RRUs zum Lesen der drei Zeilen mit. pk=‘pk’ Dann verbraucht Amazon Keyspaces die zusätzlichen 3 RRUs zum Scannen der drei leeren Partitionen der Tabelle. Da diese Abfrage zu einem Tabellenscan führt, scannt Amazon Keyspaces alle Partitionen in der Tabelle, einschließlich Partitionen ohne Daten.

Leichte Transaktionen

Lightweight Transactions (LWT) ermöglichen es Ihnen, bedingte Schreiboperationen für Ihre Tabellendaten durchzuführen. Bedingte Aktualisierungsoperationen sind nützlich, wenn Datensätze auf der Grundlage von Bedingungen eingefügt, aktualisiert und gelöscht werden, die den aktuellen Status bewerten.

In Amazon Keyspaces erfordern alle Schreibvorgänge die Konsistenz LOCAL_QUORUM, und es fallen keine zusätzlichen Gebühren für die Verwendung von LWTs an. Der Unterschied bei LWTs besteht darin, dass, wenn eine LWT-Zustandsprüfung den Wert FALSE ergibt, Schreibkapazitätseinheiten verbraucht werden. Die Anzahl der verbrauchten Schreibkapazitätseinheiten hängt von der Größe der Zeile ab. Wenn die Zeilengröße 2 KB beträgt, verbraucht das fehlgeschlagene bedingte Schreiben zwei Schreibkapazitätseinheiten. Wenn die Zeile derzeit nicht in der Tabelle vorhanden ist, verbraucht der Vorgang eine Schreibkapazitätseinheit. Durch die Überwachung der angegebenen ConditionalCheckFailed Metrik können CloudWatch Sie die Kapazität ermitteln, die durch Fehler bei der LWT-Zustandsprüfung verbraucht wird.

Schätzen Sie den Lese- und Schreibkapazitätsverbrauch mit Amazon ab CloudWatch

Um den Lese- und Schreibkapazitätsverbrauch abzuschätzen und zu überwachen, können Sie ein CloudWatch Dashboard verwenden. Weitere Informationen zu verfügbaren Metriken für Amazon Keyspaces finden Sie unterAmazon Keyspaces-Metriken und Dimensionen.

Gehen Sie wie folgt vor, um die Lese- und Schreibkapazitätseinheiten zu überwachen CloudWatch, die von einer bestimmten Anweisung mit verbraucht werden.