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.
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.
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.
