meaning that a read request immediately after a write operation might not show the latest change. However,
DynamoDB offers you the option to request the most up-to-date version of the data. To support varied
application requirements, DynamoDB supports both eventually consistent and strongly consistent read
options.
Eventually Consistent Reads
When you read data (GetItem, BatchGetItem, Query or Scan operations), the response might not
reflect the results of a recently completed write operation (PutItem, UpdateItem or DeleteItem).The
response might include some stale data. Consistency across all copies of the data is usually reached
within a second; so if you repeat your read request after a short time, the response returns the latest data.
By default, the Query and GetItem operations perform eventually consistent reads, but you can optionally
request strongly consistent reads. BatchGetItem operations are eventually consistent by default, but
you can specify strongly consistent on a per-table basis.Scan operations are always eventually consistent.
For more information about operations in DynamoDB, see Using the DynamoDB API (p. 473).
Strongly Consistent Reads
When you issue a strongly consistent read request, DynamoDB returns a response with the most up-to-date
data that reflects updates by all prior related write operations to which DynamoDB returned a successful
response. A strongly consistent read might be less available in the case of a network delay or outage.
For the query or get item operations, you can request a strongly consistent read result by specifying
optional parameters in your request.
Conditional Updates and Concurrency Control
In a multiuser environment, it is important to ensure data updates made by one client don't overwrite
updates made by another client.This "lost update" problem is a classic database concurrency issue.
Suppose two clients read the same item. Both clients get a copy of that item from DynamoDB. Client 1
then sends a request to update the item. Client 2 is not aware of any update. Later, Client 2 sends its
own request to update the item, overwriting the update made by Client 1.Thus, the update made by Client
1 is lost.
DynamoDB supports a "conditional write" feature that lets you specify a condition when updating an item.
DynamoDB writes the item only if the specified condition is met; otherwise it returns an error. In the "lost
update" example, client 2 can add a condition to verify item values on the server-side are same as the
item copy on the client-side. If the item on the server is updated, client 2 can choose to get an updated
copy before applying its own updates.
DynamoDB also supports an "atomic counter" feature where you can send a request to add or subtract
from an existing attribute value without interfering with another simultaneous write request. For example,
a web application might want to maintain a counter per visitor to its site. In this case, the client only wants
to increment a value regardless of what the previous value was. DynamoDB write operations support
incrementing or decrementing existing attribute values.
For more information, see Working with Items in DynamoDB (p. 83).
Provisioned Throughput in Amazon DynamoDB
When you create or update a table, you specify how much provisioned throughput capacity you want to
reserve for reads and writes. DynamoDB will reserve the necessary machine resources to meet your
throughput needs while ensuring consistent, low-latency performance.
A unit of read capacity represents one strongly consistent read per second (or two eventually consistent
reads per second) for items as large as 4 KB. A unit of write capacity represents one write per second
for items as large as 1 KB.
API Version 2012-08-10
10
Amazon DynamoDB Developer Guide
Conditional Updates and Concurrency Control