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. # Schätzen Sie den Kapazitätsverbrauch des Lese- und Schreibdurchsatzes in Amazon Keyspaces Wenn Sie Daten in Amazon Keyspaces lesen oder schreiben, hängt die Anzahl der read/write Anforderungseinheiten (RRUs/WRUs) or read/write capacity units (RCUs/WCUs), die Ihre Abfrage verbraucht, von der Gesamtmenge an 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. [Schätzen Sie die Zeilengröße in Amazon Keyspaces](calculating-row-size.md) **Topics** + [Schätzen Sie den Kapazitätsverbrauch von Bereichsabfragen in Amazon Keyspaces](range_queries.md) + [Schätzen Sie den Lesekapazitätsverbrauch von Grenzabfragen](limit_queries.md) + [Schätzen Sie den Lesekapazitätsverbrauch von Tabellenscans](table_scans.md) + [Schätzen Sie den Kapazitätsverbrauch leichter Transaktionen in Amazon Keyspaces](lightweight_transactions.md) + [Schätzen Sie den Kapazitätsverbrauch für statische Spalten in Amazon Keyspaces](static-columns.md) + [Schätzung und Bereitstellung der Kapazität für eine Tabelle mit mehreren Regionen in Amazon Keyspaces](tables-multi-region-capacity.md) + [Schätzen Sie den Lese- und Schreibkapazitätsverbrauch mit Amazon CloudWatch in Amazon Keyspaces](estimate_consumption_cw.md) # Schätzen Sie den Kapazitätsverbrauch von Bereichsabfragen in Amazon Keyspaces 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 | a | b | 1 | a | b | 60 | value_1 a | b | 1 | a | b | 70 | ``` 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 verbraucht 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 Wert`ck3=60`. Um den in der Abfrage angegebenen Bereich auszuwerten, liest Amazon Keyspaces in diesem Fall die Zeile, die der Obergrenze des Bereichs entspricht`ck3 = 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. # Schätzen Sie den Lesekapazitätsverbrauch von Grenzabfragen 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 übereinstimmende 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 Standard-Seitengröß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](paginating-results.md) 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 Time-to-live Einstellungen oder clientseitigen Zeitstempeln basieren. Der `PAGE SIZE` Parameter bestimmt, wie viele Zeilen Amazon Keyspaces für jede Anfrage von der Festplatte scannt, nicht, wie viele Zeilen Amazon Keyspaces an den Client zurückgibt. Amazon Keyspaces wendet die von Ihnen angegebenen Filter an, z. B. Ungleichheit bei Nichtschlüsselspalten oder `LIMIT` nach dem Scannen der Daten auf der Festplatte. Wenn Sie das nicht explizit festlegen`PAGE SIZE`, liest Amazon Keyspaces bis zu 1 MB an Daten, bevor Filter angewendet werden. Wenn Sie beispielsweise `LIMIT 1` ohne Angabe von verwenden`PAGE SIZE`, könnte Amazon Keyspaces Tausende von Zeilen von der Festplatte lesen, bevor die Limit-Klausel angewendet und nur eine einzige Zeile zurückgegeben wird. Um zu viel Lesen zu vermeiden, reduzieren Sie `PAGE SIZE` die Anzahl der Zeilen, die Amazon Keyspaces bei jedem Abruf scannt. Wenn Sie beispielsweise `LIMIT 5` in Ihrer Abfrage definieren, legen Sie für einen Wert zwischen 5 und 10 fest, sodass Amazon Keyspaces bei jedem paginierten Aufruf nur 5 bis 10 Zeilen scannt. `PAGE SIZE` Sie können diese Zahl ändern, um die Anzahl der Abrufe zu reduzieren. Für Grenzwerte, die größer als die Seitengröße sind, behält Amazon Keyspaces die Gesamtzahl der Ergebnisse mit Paginierungsstatus bei. Bei 10.000 Zeilen kann Amazon Keyspaces diese Ergebnisse auf zwei Seiten mit jeweils 5.000 Zeilen abrufen. `LIMIT` Das Limit von 1 MB ist die Obergrenze für jede festgelegte Seitengröße. # Schätzen Sie den Lesekapazitätsverbrauch von 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 Lesekapazitätsverbrauch 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 | pk | 20 | value_1 pk | 30 | ``` 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 RRUs im `LOCAL_QUORUM` Konsistenzmodus 6 Partitionen verbraucht. Erstens verbraucht Amazon Keyspaces 3 RRUs für das Lesen der drei Zeilen mit. `pk=‘pk’` Dann verbraucht Amazon Keyspaces die zusätzlichen 3 RRUs für das 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. # Schätzen Sie den Kapazitätsverbrauch leichter Transaktionen in Amazon Keyspaces 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\$1QUORUM, und es fallen keine zusätzlichen Gebühren für die Verwendung an. LWTs Der Unterschied besteht LWTs darin, dass Amazon Keyspaces Schreibkapazitätseinheiten (WCUs) oder Schreibanforderungseinheiten () verbraucht`FALSE`, wenn eine LWT-Zustandsprüfung ergibt. WRUs Die Anzahl der WCUs/WRUs verbrauchten Daten hängt von der Größe der Zeile ab. Wenn die Zeilengröße beispielsweise 2 KB beträgt, verbraucht der fehlgeschlagene bedingte Schreibvorgang zwei WCUs/WRUs. Wenn die Zeile derzeit nicht in der Tabelle vorhanden ist, verbraucht der Vorgang einen WCUs Wert vom Typ/. WRUs Um die Anzahl der Anfragen zu ermitteln, die zu Fehlschlägen bei der Zustandsprüfung geführt haben, können Sie die `ConditionalCheckFailed` Metrik in CloudWatch überwachen. ## Schätzen Sie die LWT-Kosten für Tabellen mit Time to Live (TTL) LWTs kann zusätzliche Lesekapazitätseinheiten (RCUs) oder Leseanforderungseinheiten (RRUs) für Tabellen erfordern, die mit TTL konfiguriert sind und keine clientseitigen Zeitstempel verwenden. Bei Verwendung von `IF EXISTS` oder `IF NOT EXISTS` Schlüsselwörtern mit Ergebnissen der Zustandsprüfung werden die folgenden Kapazitätseinheiten verbraucht: `FALSE` + RCUs/RRUs – If the row exists, the RCUs/RRUsDie verbrauchten Daten basieren auf der Größe der vorhandenen Zeile. + RCUs/RRUs – If the row doesn't exist, a single RCU/RRUwird verbraucht. Wenn die ausgewertete Bedingung zu einem erfolgreichen Schreibvorgang führt, WCUs/WRUs werden sie auf der Grundlage der Größe der neuen Zeile verbraucht. # Schätzen Sie den Kapazitätsverbrauch für statische Spalten in Amazon Keyspaces In einer Amazon Keyspaces-Tabelle mit Clusterspalten können Sie das `STATIC` Schlüsselwort verwenden, um eine statische Spalte zu erstellen. Der in einer statischen Spalte gespeicherte Wert wird von allen Zeilen in einer logischen Partition gemeinsam genutzt. Wenn Sie den Wert dieser Spalte aktualisieren, wendet Amazon Keyspaces die Änderung automatisch auf alle Zeilen in der Partition an. In diesem Abschnitt wird beschrieben, wie Sie die kodierte Datengröße berechnen, wenn Sie in statische Spalten schreiben. Dieser Vorgang wird getrennt von dem Prozess durchgeführt, bei dem Daten in die nichtstatischen Spalten einer Zeile geschrieben werden. Neben den Größenkontingenten für statische Daten wirken sich Lese- und Schreibvorgänge an statischen Spalten auch unabhängig voneinander auf die Messung und die Durchsatzkapazität von Tabellen aus. Informationen zu den funktionellen Unterschieden zu Apache Cassandra bei der Verwendung statischer Spalten und paginierter Leseergebnisse finden Sie unter. [Paginierung](functional-differences.md#functional-differences.paging) **Topics** + [Berechnen Sie die statische Spaltengröße pro logischer Partition in Amazon Keyspaces](static-columns-estimate.md) + [Schätzen Sie die Kapazitätsdurchsatzanforderungen für read/write Operationen mit statischen Daten in Amazon Keyspaces](static-columns-metering.md) # Berechnen Sie die statische Spaltengröße pro logischer Partition in Amazon Keyspaces Dieser Abschnitt enthält Einzelheiten zur Schätzung der codierten Größe statischer Spalten in Amazon Keyspaces. Die kodierte Größe wird bei der Berechnung Ihrer Rechnung und der Kontingentnutzung verwendet. Sie sollten die kodierte Größe auch verwenden, wenn Sie die Anforderungen an die bereitgestellte Durchsatzkapazität für Tabellen berechnen. Um die kodierte Größe statischer Spalten in Amazon Keyspaces zu berechnen, können Sie die folgenden Richtlinien verwenden. + Partitionsschlüssel können bis zu 2048 Byte an Daten enthalten. Jede Schlüsselspalte im Partitionsschlüssel benötigt bis zu 3 Byte an Metadaten. Diese Metadaten-Bytes werden auf Ihr statisches Datengrößenkontingent von 1 MB pro Partition angerechnet. Bei der Berechnung der Größe Ihrer statischen Daten sollten Sie davon ausgehen, dass jede Partitionsschlüsselspalte die vollen 3 Byte an Metadaten verwendet. + Verwenden Sie die Rohgröße der statischen Spaltendatenwerte basierend auf dem Datentyp. Weitere Informationen zu Datentypen finden Sie unter [Datentypen](cql.elements.md#cql.data-types). + Fügen Sie der Größe der statischen Daten für Metadaten 104 Byte hinzu. + Clusterspalten und normale Spalten, die keine Primärschlüsselspalten sind, werden nicht auf die Größe statischer Daten angerechnet. Informationen zum Schätzen der Größe nichtstatischer Daten innerhalb von Zeilen finden Sie unter. [Schätzen Sie die Zeilengröße in Amazon Keyspaces](calculating-row-size.md) Die kodierte Gesamtgröße einer statischen Spalte basiert auf der folgenden Formel: ``` partition key columns + static columns + metadata = total encoded size of static data ``` Betrachten Sie das folgende Beispiel für eine Tabelle, in der alle Spalten vom Typ Integer sind. Die Tabelle hat zwei Partitionsschlüsselspalten, zwei Clusterspalten, eine reguläre Spalte und eine statische Spalte. ``` CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, static_col1 int static, primary key((pk_col1, pk_col2),ck_col1, ck_col2)); ``` In diesem Beispiel berechnen wir die Größe der statischen Daten der folgenden Anweisung: ``` INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, static_col1) values(1,2,6); ``` Um die Gesamtanzahl der für diesen Schreibvorgang benötigten Byte abzuschätzen, können Sie die folgenden Schritte verwenden. 1. Berechnen Sie die Größe einer Partitionsschlüsselspalte, indem Sie die Byte für den in der Spalte gespeicherten Datentyp und die Metadaten-Bytes addieren. Wiederholen Sie diesen Vorgang für alle Partitionsschlüsselspalten. 1. Berechnet die Größe der ersten Spalte des Partitionsschlüssels (pk\$1col1): ``` 4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes ``` 1. Berechnet die Größe der zweiten Spalte des Partitionsschlüssels (pk\$1col2): ``` 4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes ``` 1. Fügen Sie beide Spalten hinzu, um die geschätzte Gesamtgröße der Partitionsschlüsselspalten zu erhalten: ``` 7 bytes + 7 bytes = 14 bytes for the partition key columns ``` 1. Fügen Sie die Größe der statischen Spalten hinzu. In diesem Beispiel haben wir nur eine statische Spalte, die eine Ganzzahl speichert (was 4 Byte erfordert). 1. Um schließlich die gesamte kodierte Größe der statischen Spaltendaten zu ermitteln, addieren Sie die Byte für die Primärschlüsselspalten und statischen Spalten und fügen Sie die zusätzlichen 104 Byte für Metadaten hinzu: ``` 14 bytes for the partition key columns + 4 bytes for the static column + 104 bytes for metadata = 122 bytes. ``` Sie können statische und nicht statische Daten auch mit derselben Anweisung aktualisieren. Um die Gesamtgröße des Schreibvorgangs abzuschätzen, müssen Sie zunächst den Umfang der nichtstatischen Datenaktualisierung berechnen. Berechnen Sie dann die Größe der Zeilenaktualisierung, wie im Beispiel unter gezeigt[Schätzen Sie die Zeilengröße in Amazon Keyspaces](calculating-row-size.md), und fügen Sie die Ergebnisse hinzu. In diesem Fall können Sie insgesamt 2 MB schreiben — 1 MB ist das maximale Zeilengrößenkontingent und 1 MB ist das Kontingent für die maximale statische Datengröße pro logischer Partition. Um die Gesamtgröße einer Aktualisierung statischer und nicht statischer Daten in derselben Anweisung zu berechnen, können Sie die folgende Formel verwenden: ``` (partition key columns + static columns + metadata = total encoded size of static data) + (partition key columns + clustering columns + regular columns + row metadata = total encoded size of row) = total encoded size of data written ``` Betrachten Sie das folgende Beispiel für eine Tabelle, in der alle Spalten vom Typ Integer sind. Die Tabelle hat zwei Partitionsschlüsselspalten, zwei Clusterspalten, eine reguläre Spalte und eine statische Spalte. ``` CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, static_col1 int static, primary key((pk_col1, pk_col2),ck_col1, ck_col2)); ``` In diesem Beispiel berechnen wir die Datengröße, wenn wir eine Zeile in die Tabelle schreiben, wie in der folgenden Anweisung dargestellt: ``` INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, ck_col1, ck_col2, reg_col1, static_col1) values(2,3,4,5,6,7); ``` Um die Gesamtanzahl der für diesen Schreibvorgang benötigten Byte zu schätzen, können Sie die folgenden Schritte verwenden. 1. Berechnen Sie die gesamte kodierte Größe der statischen Daten wie zuvor gezeigt. In diesem Beispiel sind es 122 Byte. 1. Fügen Sie die Größe der codierten Gesamtgröße der Zeile hinzu, die auf der Aktualisierung nicht statischer Daten basiert. Gehen Sie dabei wie unter beschrieben vor. [Schätzen Sie die Zeilengröße in Amazon Keyspaces](calculating-row-size.md) In diesem Beispiel beträgt die Gesamtgröße der Zeilenaktualisierung 134 Byte. ``` 122 bytes for static data + 134 bytes for nonstatic data = 256 bytes. ``` # Schätzen Sie die Kapazitätsdurchsatzanforderungen für read/write Operationen mit statischen Daten in Amazon Keyspaces Statische Daten sind logischen Partitionen in Cassandra zugeordnet, nicht einzelnen Zeilen. Logische Partitionen in Amazon Keyspaces können in ihrer Größe praktisch unbegrenzt sein, da sie sich über mehrere physische Speicherpartitionen erstrecken. Aus diesem Grund schreiben Amazon Keyspaces-Messgeräte Operationen für statische und nichtstatische Daten getrennt. Darüber hinaus erfordern Schreibvorgänge, die sowohl statische als auch nicht statische Daten enthalten, zusätzliche zugrunde liegende Operationen, um die Datenkonsistenz zu gewährleisten. Wenn Sie einen gemischten Schreibvorgang für statische und nicht statische Daten ausführen, führt dies zu zwei separaten Schreibvorgängen — einer für nicht statische und einer für statische Daten. Dies gilt sowohl für den bedarfsgesteuerten als auch für den Modus mit bereitgestellter Kapazität. read/write Das folgende Beispiel enthält Details zur Schätzung der erforderlichen Lesekapazitätseinheiten (RCUs) und Schreibkapazitätseinheiten (WCUs), wenn Sie die Anforderungen an die bereitgestellte Durchsatzkapazität für Tabellen in Amazon Keyspaces mit statischen Spalten berechnen. Mithilfe der folgenden Formel können Sie abschätzen, wie viel Kapazität Ihre Tabelle für die Verarbeitung von Schreibvorgängen benötigt, die sowohl statische als auch nichtstatische Daten enthalten: ``` 2 x WCUs required for nonstatic data + 2 x WCUs required for static data ``` Wenn Ihre Anwendung beispielsweise 27 KBs Daten pro Sekunde schreibt und jeder Schreibvorgang 25,5 KBs nichtstatische Daten und 1,5 KBs statische Daten umfasst, benötigt Ihre Tabelle 56 WCUs (2 x 26 WCUs \$1 2 x 2). WCUs Amazon Keyspaces misst die Lesevorgänge statischer und nichtstatischer Daten genauso wie die Lesevorgänge mehrerer Zeilen. Daher basiert der Preis für das Lesen statischer und nichtstatischer Daten in derselben Operation auf der Gesamtgröße der Daten, die für den Lesevorgang verarbeitet wurden. Informationen zur Überwachung serverloser Ressourcen mit Amazon finden Sie CloudWatch unter[Überwachung von Amazon Keyspaces mit Amazon CloudWatch](monitoring-cloudwatch.md). # Schätzung und Bereitstellung der Kapazität für eine Tabelle mit mehreren Regionen in Amazon Keyspaces Sie können die Durchsatzkapazität einer Tabelle mit mehreren Regionen auf eine von zwei Arten konfigurieren: + Kapazitätsmodus auf Abruf, gemessen in Schreibanforderungseinheiten () WRUs + Bereitgestellter Kapazitätsmodus mit auto Skalierung, gemessen in Schreibkapazitätseinheiten () WCUs Sie können den Modus für bereitgestellte Kapazität mit Auto Scaling oder den On-Demand-Kapazitätsmodus verwenden, um sicherzustellen, dass eine Tabelle mit mehreren Regionen über ausreichend Kapazität verfügt, um replizierte Schreibvorgänge für alle durchzuführen. AWS-Regionen **Anmerkung** Wenn Sie den Kapazitätsmodus der Tabelle in einer der Regionen ändern, wird der Kapazitätsmodus für alle Replikate geändert. Standardmäßig verwendet Amazon Keyspaces den On-Demand-Modus für Tabellen mit mehreren Regionen. Im On-Demand-Modus müssen Sie nicht angeben, wie viel Lese- und Schreibdurchsatz Sie von Ihrer Anwendung erwarten. Amazon Keyspaces passt sich sofort Ihren Workloads an, wenn sie auf ein zuvor erreichtes Datenverkehrsniveau hoch- oder herunterfahren. Wenn der Traffic eines Workloads einen neuen Höhepunkt erreicht, passt sich Amazon Keyspaces schnell an den Workload an. Wenn Sie den Modus Bereitgestellte Kapazität für eine Tabelle wählen, müssen Sie die Anzahl der Lesekapazitätseinheiten (RCUs) und Schreibkapazitätseinheiten (WCUs) pro Sekunde konfigurieren, die Ihre Anwendung benötigt. Um den Durchsatzkapazitätsbedarf einer Tabelle mit mehreren Regionen zu planen, sollten Sie zunächst abschätzen, wie viele WCUs pro Sekunde für jede Region benötigt werden. Dann addieren Sie die Schreibvorgänge aus allen Regionen, in denen Ihre Tabelle repliziert wird, und verwenden die Summe, um Kapazität für jede Region bereitzustellen. Dies ist erforderlich, da jeder Schreibvorgang, der in einer Region ausgeführt wird, auch in jeder Replikatregion wiederholt werden muss. Wenn die Tabelle nicht über genügend Kapazität verfügt, um die Schreibvorgänge aus allen Regionen zu verarbeiten, treten Kapazitätsausnahmen auf. Darüber hinaus werden die Wartezeiten bei der interregionalen Replikation zunehmen. Wenn Sie beispielsweise über eine Tabelle mit mehreren Regionen verfügen, in der Sie 5 Schreibvorgänge pro Sekunde in USA Ost (Nord-Virginia), 10 Schreibvorgänge pro Sekunde in USA Ost (Ohio) und 5 Schreibvorgänge pro Sekunde in Europa (Irland) erwarten, sollten Sie damit rechnen, dass die Tabelle WCUs in jeder Region 20 Schreibvorgänge verbraucht: USA Ost (Nord-Virginia), USA Ost (Ohio) und Europa (Irland). Das bedeutet, dass Sie in diesem Beispiel 20 WCUs für jedes Replikat der Tabelle bereitstellen müssen. Sie können den Kapazitätsverbrauch Ihrer Tabelle mit Amazon überwachen CloudWatch. Weitere Informationen finden Sie unter [Überwachung von Amazon Keyspaces mit Amazon CloudWatch](monitoring-cloudwatch.md). Jeder Schreibvorgang wird mit 1 WCU abgerechnet. In diesem Beispiel würden also insgesamt 60 WCU WCUs abgerechnet. Weitere Informationen zu den Preisen finden Sie unter [Amazon Keyspaces (für Apache Cassandra)](https://aws.amazon.com/keyspaces/pricing) — Preise. Weitere Informationen zur bereitgestellten Kapazität mit Amazon Keyspaces Auto Scaling finden Sie unter. [Automatische Verwaltung der Durchsatzkapazität mit Amazon Keyspaces Auto Scaling](autoscaling.md) **Anmerkung** Wenn eine Tabelle im Modus für bereitgestellte Kapazität mit Auto Scaling ausgeführt wird, darf die bereitgestellte Schreibkapazität innerhalb dieser Auto Scaling-Einstellungen für jede Region schwanken. # Schätzen Sie den Lese- und Schreibkapazitätsverbrauch mit Amazon CloudWatch in Amazon Keyspaces 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 unter[Amazon Keyspaces-Metriken und -Dimensionen](metrics-dimensions.md). Gehen Sie wie folgt vor, um die Lese- und Schreibkapazitätseinheiten zu überwachen CloudWatch, die von einer bestimmten Anweisung mit verbraucht werden. 1. Erstellen Sie eine neue Tabelle mit Beispieldaten 1. Konfigurieren Sie ein Amazon CloudWatch Keyspaces-Dashboard für die Tabelle. Zu Beginn können Sie eine Dashboard-Vorlage verwenden, die auf [Github](https://github.com/aws-samples/amazon-keyspaces-cloudwatch-cloudformation-templates) verfügbar ist. 1. Führen Sie die CQL-Anweisung aus, beispielsweise mit der `ALLOW FILTERING` Option, und überprüfen Sie im Dashboard, welche Lesekapazitätseinheiten für den vollständigen Tabellenscan verbraucht wurden.