Read/write capacity modes in Amazon Keyspaces
Amazon Keyspaces has two read/write capacity modes for processing reads and writes on your tables:
-
On-demand (default)
-
Provisioned
The read/write capacity mode that you choose controls how you are charged for read and write throughput and how table throughput capacity is managed.
Topics
On-demand capacity mode
Amazon Keyspaces (for Apache Cassandra) on-demand capacity mode is a flexible billing option capable of serving thousands of requests per second without capacity planning. This option offers pay-per-request pricing for read and write requests so that you pay only for what you use.
When you choose on-demand mode, Amazon Keyspaces can scale the throughput capacity for your table up to any previously reached traffic level instantly, and then back down when application traffic decreases. If a workload’s traffic level hits a new peak, the service adapts rapidly to increase throughput capacity for your table. You can enable on-demand capacity mode for both new and existing tables.
On-demand mode is a good option if any of the following is true:
-
You create new tables with unknown workloads.
-
You have unpredictable application traffic.
-
You prefer the ease of paying for only what you use.
To get started with on-demand mode, you can create a new table or update an existing table to use on-demand capacity mode using the console or with a few lines of Cassandra Query Language (CQL) code. For more information, see Tables.
Topics
Read request units and write request units
With on-demand capacity mode tables, you don't need to specify how much read and write throughput you expect your application to use in advance. Amazon Keyspaces charges you for the reads and writes that you perform on your tables in terms of read request units (RRUs) and write request units (WRUs).
-
One RRU represents one
LOCAL_QUORUM
read request, or twoLOCAL_ONE
read requests, for a row up to 4 KB in size. If you need to read a row that is larger than 4 KB, the read operation uses additional RRUs. The total number of RRUs required depends on the row size, and whether you want to useLOCAL_QUORUM
orLOCAL_ONE
read consistency. For example, reading an 8 KB row requires 2 RRUs usingLOCAL_QUORUM
read consistency, and 1 RRU if you chooseLOCAL_ONE
read consistency. -
One WRU represents one write for a row up to 1 KB in size. All writes are using
LOCAL_QUORUM
consistency, and there is no additional charge for using lightweight transactions (LWTs). If you need to write a row that is larger than 1 KB, the write operation uses additional WRUs. The total number of WRUs required depends on the row size. For example, if your row size is 2 KB, you require 2 WRUs to perform one write request.
For information about supported consistency levels, see Supported Apache Cassandra read and write consistency levels and associated costs.
Peak traffic and scaling properties
Amazon Keyspaces tables that use on-demand capacity mode automatically adapt to your
application’s traffic volume. On-demand capacity mode instantly accommodates up
to double the previous peak traffic on a table. For example, your application's
traffic pattern might vary between 5,000 and 10,000 LOCAL_QUORUM
reads per second, where 10,000 reads per second is the previous traffic peak.
With this pattern, on-demand capacity mode instantly accommodates sustained traffic of up to 20,000 reads per second. If your application sustains traffic of 20,000 reads per second, that peak becomes your new previous peak, enabling subsequent traffic to reach up to 40,000 reads per second.
If you need more than double your previous peak on a table, Amazon Keyspaces automatically allocates more capacity as your traffic volume increases. This helps ensure that your table has enough throughput capacity to process the additional requests. However, you might observe insufficient throughput capacity errors if you exceed double your previous peak within 30 minutes.
For example, suppose that your application's traffic pattern varies between 5,000 and 10,000 strongly consistent reads per second, where 20,000 reads per second is the previously reached traffic peak. In this case, the service recommends that you space your traffic growth over at least 30 minutes before driving up to 40,000 reads per second.
To learn how to estimate read and write capacity consumption of a table, see How to estimate capacity consumption of read and write throughput in Amazon Keyspaces.
To learn more about default quotas for your account and how to increase them, see Quotas for Amazon Keyspaces (for Apache Cassandra).
Initial throughput for on-demand capacity mode
If you create a new table with on-demand capacity mode enabled or switch an existing table to on-demand capacity mode for the first time, the table has the following previous peak settings, even though it hasn't served traffic previously using on-demand capacity mode:
-
Newly created table with on-demand capacity mode: The previous peak is 2,000 WRUs and 6,000 RRUs. You can drive up to double the previous peak immediately. Doing this enables newly created on-demand tables to serve up to 4,000 WRUs and 12,000 RRUs.
-
Existing table switched to on-demand capacity mode: The previous peak is half the previous WCUs and RCUs provisioned for the table or the settings for a newly created table with on-demand capacity mode, whichever is higher.
Provisioned throughput capacity mode
If you choose provisioned throughput capacity mode, you specify the number of reads and writes per second that are required for your application. This helps you manage your Amazon Keyspaces usage to stay at or below a defined request rate to optimize price and maintain predictability. To learn more about automatic scaling for provisioned throughput see Manage throughput capacity automatically with Amazon Keyspaces auto scaling.
Provisioned throughput capacity mode is a good option if any of the following is true:
-
You have predictable application traffic.
-
You run applications whose traffic is consistent or ramps up gradually.
-
You can forecast capacity requirements to optimize price.
Read capacity units and write capacity units
For provisioned throughput capacity mode tables, you specify throughput capacity in terms of read capacity units (RCUs) and write capacity units (WCUs):
-
One RCU represents one
LOCAL_QUORUM
read per second, or twoLOCAL_ONE
reads per second, for a row up to 4 KB in size. If you need to read a row that is larger than 4 KB, the read operation uses additional RCUs.The total number of RCUs required depends on the row size, and whether you want
LOCAL_QUORUM
orLOCAL_ONE
reads. For example, if your row size is 8 KB, you require 2 RCUs to sustain oneLOCAL_QUORUM
read per second, and 1 RCU if you chooseLOCAL_ONE
reads. -
One WCU represents one write per second for a row up to 1 KB in size. All writes are using
LOCAL_QUORUM
consistency, and there is no additional charge for using lightweight transactions (LWTs). If you need to write a row that is larger than 1 KB, the write operation uses additional WCUs.The total number of WCUs required depends on the row size. For example, if your row size is 2 KB, you require 2 WCUs to sustain one write request per second. For more information about how to estimate read and write capacity consumption of a table, see How to estimate capacity consumption of read and write throughput in Amazon Keyspaces.
If your application reads or writes larger rows (up to the Amazon Keyspaces maximum row size of 1 MB), it consumes more capacity units. To learn more about how to estimate the row size, see Calculating row size in Amazon Keyspaces. For example, suppose that you create a provisioned table with 6 RCUs and 6 WCUs. With these settings, your application could do the following:
-
Perform
LOCAL_QUORUM
reads of up to 24 KB per second (4 KB × 6 RCUs). -
Perform
LOCAL_ONE
reads of up to 48 KB per second (twice as much read throughput). -
Write up to 6 KB per second (1 KB × 6 WCUs).
Provisioned throughput is the maximum amount of throughput capacity an application can consume from a table. If your application exceeds your provisioned throughput capacity, you might observe insufficient capacity errors.
For example, a read request that doesn’t have enough throughput capacity fails
with a Read_Timeout
exception and is posted to the
ReadThrottleEvents
metric. A write request that doesn’t have
enough throughput capacity fails with a Write_Timeout
exception and
is posted to the WriteThrottleEvents
metric.
You can use Amazon CloudWatch to monitor your provisioned and actual throughput metrics and insufficient capacity events. For more information about these metrics, see Amazon Keyspaces metrics and dimensions.
Note
Repeated errors due to insufficient capacity can lead to client-side
driver specific exceptions, for example the DataStax Java driver fails with
a NoHostAvailableException
.
To change the throughput capacity settings for tables, you can use the
AWS Management Console or the ALTER TABLE
statement using CQL, for more
information see ALTER TABLE.
To learn more about default quotas for your account and how to increase them, see Quotas for Amazon Keyspaces (for Apache Cassandra).
Managing and viewing capacity modes
You can query the system table in the Amazon Keyspaces system keyspace to review capacity mode information about a table. You can also see whether a table is using on-demand or provisioned throughput capacity mode. If the table is configured with provisioned throughput capacity mode, you can see the throughput capacity provisioned for the table.
Example
SELECT * from system_schema_mcs.tables where keyspace_name = 'mykeyspace' and table_name = 'mytable';
A table configured with on-demand capacity mode returns the following.
{ 'capacity_mode': { 'last_update_to_pay_per_request_timestamp': '1579551547603', 'throughput_mode': 'PAY_PER_REQUEST' } }
A table configured with provisioned throughput capacity mode returns the following.
{ 'capacity_mode': { 'last_update_to_pay_per_request_timestamp': '1579048006000', 'read_capacity_units': '5000', 'throughput_mode': 'PROVISIONED', 'write_capacity_units': '6000' } }
The last_update_to_pay_per_request_timestamp
value is measured in
milliseconds.
To change the provisioned throughput capacity for a table, use ALTER TABLE.
Considerations when changing capacity modes
When you switch a table from provisioned capacity mode to on-demand capacity mode, Amazon Keyspaces makes several changes to the structure of your table and partitions. This process can take several minutes. During the switching period, your table delivers throughput that is consistent with the previously provisioned WCU and RCU amounts.
When you switch from on-demand capacity mode back to provisioned capacity mode, your table delivers throughput that is consistent with the previous peak reached when the table was set to on-demand capacity mode.
Note
You can switch capacity modes from provisioned to on-demand only once in a 24-hour period.