Write data
Tablestore provides three operations for writing data to tables: PutRow, UpdateRow, and BatchWriteRow.
Rows are the basic units of tables. Each row consists of primary key columns and optional attribute columns. Primary key column names and types are the same across all rows in a table. Attribute columns can differ between rows. For more information, see Overview.
Operations
| Operation | Scope | Behavior |
|---|---|---|
| PutRow | Single row | Inserts a row. If a row with the same primary key exists, deletes all versions of data in all columns and writes the new data. |
| UpdateRow | Single row | Adds, updates, or removes attribute columns. Deletes a specific version of data from a column. If the row does not exist, inserts a new row (unless the request only removes columns). |
| BatchWriteRow | Multiple rows | Combines multiple PutRow, UpdateRow, and DeleteRow sub-operations in a single request across one or more tables. Each sub-operation is performed and responded to independently. |
Common settings
Before writing data, you can configure the following optional settings for any write operation:
-
Data version number: By default, Tablestore uses the current UNIX timestamp (milliseconds since
January 1, 1970, 00:00:00UTC) as the version number. Specify a custom version number if needed. For more information, see Data versions and TTL. -
Conditional update: Set a row existence condition or a condition based on column values. For more information, see Conditional updates.
PutRow response
-
On success, Tablestore returns the number of capacity units (CUs) consumed.
-
On failure, Tablestore returns an error code (for example, parameter validation failure, excessive row data, or row existence check failure).
For more information about error codes, see Error codes.
BatchWriteRow partial failure handling
When some rows fail in a BatchWriteRow request, Tablestore does not throw an exception. Instead, it returns a BatchWriteRowResponse that contains information about the failed rows. Always call the isAllSucceed method to check whether all rows were written successfully.
If the server detects invalid parameters in some operations, it may return an error before performing any operations in the request.
BatchWriteRow also supports per-operation conditions -- configure update conditions separately for each PutRow, UpdateRow, or DeleteRow sub-operation.
Use the Tablestore console
Use the Tablestore CLI
Use Tablestore SDKs
Billing
Tablestore provides two billing methods: VCU mode (formerly reserved mode) and CU mode (formerly pay-as-you-go mode). The billing for computing resources differs between these two methods.
-
VCU mode (formerly reserved mode)
You purchase computing capacity in advance with a subscription. This capacity covers the computing resources consumed by data writes.
-
CU mode (formerly pay-as-you-go mode)
Billing is based on the CUs converted from the actual computing resources consumed. Depending on the instance type, billing distinguishes between pay-as-you-go read/write CUs and reserved read/write CUs.
NoteFor more information about instance types and CUs, see Instances and Read/write throughput.
Operation
CU consumption
PutRow operation
-
The number of write CUs consumed is the total size of the primary key and attribute columns of the modified row, divided by 4 KB and rounded up.
-
The consumed read CUs depend on the specified condition. Set the condition field in a single-row write request to specify whether to check for the existence of the row during the write operation.
-
If the condition check is not set to IGNORE, the operation consumes read CUs. The number of read CUs is the data size of the row's primary key, divided by 4 KB and rounded up.
-
If the operation does not meet the specified row existence condition, the operation fails and consumes 1 write CU and 1 read CU.
-
UpdateRow operation
-
The number of write CUs consumed is the total size of the primary key and attribute columns of the modified row, divided by 4 KB and rounded up.
For attribute columns that are to be deleted in the operation, only the names of the attribute columns are included in the attribute column data size.
-
The consumed read CUs depend on the specified condition. Set the condition field in a single-row update request to specify whether to check for the existence of the row during the update operation.
-
If the condition check is not set to IGNORE, the operation consumes read CUs. The number of read CUs is the data size of the row's primary key, divided by 4 KB and rounded up.
-
If the operation does not meet the specified row existence condition, the operation fails and consumes 1 write CU and 1 read CU.
-
BatchWriteRow operation
The read and write CUs are calculated independently for each PutRow, UpdateRow, and DeleteRow operation included in the BatchWriteRow request.
The consumption of read and write CUs for a DeleteRow operation is as follows:
-
The number of write CUs consumed is the data size of the primary key of the deleted row, divided by 4 KB and rounded up.
-
If the condition check is not set to IGNORE, the operation consumes read CUs. The number of read CUs is the data size of the row's primary key, divided by 4 KB and rounded up.
-
If the operation does not meet the specified row existence condition, the operation fails and consumes 1 write CU.
-
Write CU calculation
Read CU calculation
Read CUs are consumed only when the condition parameter is not set to IGNORE.