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 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 | <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 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.
