DynamoDB的数据会在不同的地理位置机房保存3份。3份数据的同步通常在1秒内完成。

Read consistency

l  终一致性读((Default): 写操作之后立刻发起读操作返回的可能不是新数据。只是保证数据终同步成一致。

终一致性读操作是强一致性读的半价.

l  强一致性读: 写操作之后立刻发起读操作返回的就是新数据.

支持单记录原子操作（Atomic Counters）：

支持条件更新，支持更新时返回所有属性旧/新值、被更新属性旧/新值

支持基于非主键查询: 使用scan扫描全表，效率较差。

Provisioned Throughput:读写操作的速率限制。用户要指定每张表第秒能提供多少次读写操作(以1KB大小的记录为基准).

Units ofCapacity required for writes = Number of item writes per second x item size(rounded up to the nearest KB)

Units ofCapacity required for reads* = Number of item reads per second x item size(rounded up to the nearest KB),  以实际读取的记录数为准， 和API调用次数无关。 例如想从一张表中每秒读取500条记录， 不管调用的是50个BatchGetItem(每个call返回10条记录)还是500个GetItem， Throughput都必须设为500.

如果读写速度超过了设定的上限， 超出部分读写将失败。

限制:

1.      Item size < 64KB(include attribute name and value binary length (UTF-8 length))

2.      Attribute values: Attributevalues cannot be null or empty.

3.      Hash primary key attribute value< 2048 bytes

4.      Range primary key attributevalue < 1024 bytes

5.      Query result < 1MBper API call

6.      Scan data set size < 1MBper API call(每次只能扫描1MB数据集)

In case of a scan operation, it is not the size of items returned by scan,rather it is the size of items evaluated by Amazon DynamoDB. That is, for ascan request, Amazon DynamoDB evaluates up to 1 MB of items and returns onlythe items that satisfy the scan condition.

 a single scan request consumes up to 1 MB / 1 KB = 500 capacity units(because scan returns only eventually consistent result which takes half the capacity units of a consistent read), which is a sudden burst of usage of the configured capacity units for the table. This sudden use of capacity units by a scan starves your other potentially more important requests for the same table from using the available capacity units. As a result, you likely get the "ProvisionedThroughputExceeded" exception for those requests.






You should configure your application to retry any request that receives a response code that indicates you have exceeded your provisioned throughput, or increase the provisioned throughput for your table using the UpdateTable API. If you have temporary spikes in your workload that cause your throughput to exceed, occasionally, beyond the provisioned level, retry the request with exponential backoff. 






Error Retries and Exponential Backoff


Numerous components on a network, such as DNS servers, switches, load-balancers, and others can generate errors anywhere in the life of a given request.


The usual technique for dealing with these error responses in a networked environment is to implement retries in the client application. This technique increases the reliability of the application and reduces operational costs for the developer.


Each AWS SDK supporting Amazon DynamoDB implements retry logic, automatically.The AWS SDK for Java automatically retries requests, and you can configure the retry settings using the ClientConfiguration class.For example, in some cases, such as a web page making a request with minimal latency and no retries, you might want to turn off the retry logic. Use the ClientConfiguration class and provide a maxErrorRetry value of 0 to turn off the retries. For more information, see Using the AWS SDKs with Amazon DynamoDB.
http://docs.amazonwebservices.com/amazondynamodb/latest/developerguide/ErrorHandling.html#APIRetries

http://docs.amazonwebservices.com/amazondynamodb/latest/developerguide/WorkingWithDDTables.html#CapacityUnitCalculations