Read/write throughput capacity

Last Updated: Jul 28, 2017

The read/write throughput is measured by read/write capacity units (CUs),which is the smallest billing unit for the data read and write operations.

One read CU indicates that 4 KB data is read from the table, and one write CU indicates that 4 KB data is written into the table. Data smaller than 4 KB during the operation will be rounded up to an integer. For example, writing 7.6 KB data will consume two write CUs, and reading 0.1 KB data will consume one read CU.

When applications perform Table Store read/write operations through an API, the corresponding amount of read/write CUs will be consumed.

Reserved throughput

The reserved read/write throughput is an attribute of a table. When creating a table, the application specifies the read/write throughput reserved for the table. Configuring the reserved read/write throughput does not affect the table’s access performance and service capability.

The reserved read/write throughput can be set to 0. When the reserved read/write throughput is greater than 0, Table Store assigns and reserves enough resources for the table according to this configuration, so as to ensure lower resource costs. The reserved read/write throughput of a table is dynamically changeable using the UpdateTable request.

With a non-zero reserved read/write throughput, your use of Table Store is still billed even when there are no read and write requests. For this reason, Table Store limits the maximum reserved read/write throughput to 5,000 CUs per table (no more than 5,000 CUs of read throughput and write throughput respectively). If you require more than 5,000 CUs of reserved read/write throughput for a single table, open a ticket to increase the throughput.

The reserved read/write throughput of a non-existent table is regarded as 0. To access a non-existent table will consume one additional read CU or one additional write CU based on the actual operation.

Additional throughput

The additional read/write throughput refers to the portion of the actual consumed read/write throughput that exceeds the reserved read/write throughput. Its statistical period is one second. For example, when the reserved read throughput of a table is set to 100 CUs and the read operation within a second actually consumes 120 CUs, then the additional read throughput consumed within the second is 20 CUs. If the reserved read throughput of a table is set to 0 CU, the read throughput consumed by each read operation of the table is the additional read throughput.

When billing is based on the additional read/write throughput mode, it is difficult to estimate the amount of compute resources that need to be reserved for data tables. Table Store must provide sufficient service capability to deal with the access traffic spikes. For this reason, the unit price of additional read/write throughput is higher than that of the reserved read/write throughput. Set a proper value of the reserved read/write throughput to reduce costs.

Notice: Because it is difficult to accurately reserve resources based on the additional read/write throughput, in extreme situations, Table Store may return an error OTSCapacityUnitExhausted to the application when an access to a single partition key consumes 10,000 CUs per second. In this case, policies such as backoff retry are used to reduce the frequency of access to the table.

For more information, refer to Table Store tables and Billing methods.

Thank you! We've received your feedback.