Consistency - Amazon SimpleDB

Consistency

Amazon SimpleDB keeps multiple copies of each domain. A successful write (using PutAttributes, BatchPutAttributes, DeleteAttributes, BatchDeleteAttributes, CreateDomain, or DeleteDomain) guarantees that all copies of the domain will durably persist.

Amazon SimpleDB supports two read consistency options: eventually consistent read and consistent read.

An eventually consistent read (using Select or GetAttributes) might not reflect the results of a recently completed write (using PutAttributes, BatchPutAttributes, DeleteAttributes, or BatchDeleteAttributes). Consistency across all copies of the data is usually reached within a second; repeating a read after a short time should return the updated data.

A consistent read (using Select or GetAttributes with ConsistentRead=true) returns a result that reflects all writes that received a successful response prior to the read.

By default, GetAttributes and Select perform an eventually consistent read.

The following table describes the characteristics of eventually consistent read and consistent read.

Eventually Consistent Read Consistent Read
Stale reads possible No stale reads
Lowest read latency Potential higher read latency
Highest read throughput Potential lower read throughput

Concurrent Applications

This section provides examples of eventually consistent and consistent read requests when multiple clients are writing to the same items. Whenever you have multiple clients writing to the same items, implement some concurrently control mechanism, such as timestamp ordering, to ensure you are getting the data you want.

In this example, both W1 (write 1) and W2 (write 2) complete (receive a successful response from the server) before the start of R1 (read 1) and R2 (read 2). For a consistent read, R1 and R2 both return color = ruby. For an eventually consistent read, R1 and R2 might return color = red, color = ruby, or no results, depending on the amount of time that has elapsed.

 

Diagram showing two clients, two write operations (W1, W2), and two read operations (R1, R2) on a timeline.

 

In the next example, W2 does not complete before the start of R1. Therefore, R1 might return color = ruby or color = garnet for either a consistent read or an eventually consistent read. Data is distributed among several servers. If R1 is sent to one server that does not have the W2 values, yet, then R1 returns W1 values. Also, depending on the amount of time that has elapsed, an eventually consistent read might return no results.

Note

If a failure occurs during the second write operation (W2), the value might change depending on when in the operation the failure occurs.

For a consistent read, R2 returns color = garnet. For an eventually consistent read, R2 might return color = ruby, color = garnet, or no results depending on the amount of time that has elapsed.

 

Timeline showing two writes and two reads with consistency and eventual outcomes for distributed systems.

 

In the last example, Client 2 submits W2 before Amazon SimpleDB completes W1, so the outcome of the final value is unknown (color = garnet or color = brick). Any subsequent reads (consistent read or eventually consistent) might return either value. Also, depending on the amount of time that has elapsed, an eventually consistent read might return no results.

 

Diagram showing two clients, two write operations W1 and W2, and two read operations R1 and R2 on a timeline.