Amazon DynamoDB详解

今早Amazon发布了DynamoDB，作为AWS服务的新成员，提升了AWS管理结构化数据的能力。总体来说，DynamoDB是基于Amazon Dynamo技术实现的可伸缩性和可用性优异的NoSQL数据库托管服务。

我们知道，Amazon搞了一个很牛的KV数据库Dynamo，可伸缩性、可用性和性能稳定性非常好。但Dynamo推出后并没有在Amazon内部被广泛接纳，主要原因是Dynamo是作为软件系统提供给开发者，要用得部署各自的Dynamo集群，安装管理成本很高。后来Amazon推出了SimpleDB托管服务（Managed Service），没有部署和管理开销，很受欢迎。用户也很欢迎SimpleDB灵活的数据模型。

但是SimpleDB也存在几个主要问题：

1、可伸缩性有限。因为批量操作只有Domain数据在一个节点上才能有效完成，导致单个Domain最大只能支持到10G；

2、性能不可预期。SimpleDB为了方便使用，所有属性都建索引，都可以搜索，这导致更新性能不可控，如果属性一多或数据量一大更新就很慢；

3、最终一致性难以使用。一开始SimpleDB只提供最终一致性读，开发者觉得开发应用时很麻烦，几年后SimpleDB才提供了一致性读选项；

4、Machine Hours计费很难用；

根据这些经验，Amazon重新设计了DynamoDB。采纳了SimpleDB中成功的托管服务形式及灵活的数据模型，并从一开始提供了一致性读功能。限制了系统的功能，只能通过主键去操作记录，不能进行批量更新，这使得系统可以保证可伸缩性及任何时候的高性能。另外，全面的使用SSD来提升系统性能。

下面来详细说说DynamoDB的各项特性。

一、数据模型

DynamoDB的数据模型可以说是SimpleDB/BigTable与Oracle NoSQL的融合。系统首先分成多张表（Table）。表中的记录拥有单属性简单哈希主键或两属性Hash Key+Range Key组合主键。记录内容可包含任意多个属性，属性分单值或多值两种。属性值可以是字符串或数值类型。表没有统一的模式，建表时只需要指定主键的定义，其余各记录都可以拥有自己不同的属性集合。记录由主键和多个属性组成这一点类似于SimpleDB与BigTable，这比简单的KV模型更易用。主键可以由Hash Key+Range Key组合而成则类似于Oracle NoSQL，这主要为了提供相同Hash Key的记录集合操作。

Dynamo service对PrimaryKey的规则定义：

1. 可以只有一列作为primary key，则该列作为hash的输入，也就是用来分Partition

2. 可以由两列作为composite primary key，则第一列仍然作为hash输入，用来分partition，而第二列及其之后的列就可以提供range的查询了

Simple Hash Key

　　。这个Key对应的Attribute在每个Item里都必须存在而且唯一。

　　Composite Hash Key with Range Keys

　　。顾名思义，在Hask Key的基础上，用户可以增加一个Attribute作为范围查询的Key。此时不需要保证Hash Key的唯一性，只需要这两个组合Key是唯一的就可以。这在我们做时间范围查询时非常有用，比如某个用户在24小时内访问过的网页。

二、操作

DynamoDB提供如下操作：

1、putItem：插入或更新一条记录，支持条件更新，支持在更新时返回属性旧值

2、getItem：获取一条完整的记录或某些属性， 允许指定用最终一致性读还是严格一致性读

3、batchGetItem：获取一个或多个表中的多条记录或某些属性，只能用最终一致性读。一次最多返回100个属性及小于1MB数据，如果没有返回所有记录，会返回还没有处理的键值以便应用再次去获取

4、updateItem：插入/删除/更新一条记录中的某些属性， 支持条件更新，支持更新时返回所有属性旧/新值、被更新属性旧/新值

5、deleteItem：删除一条记录，支持条件删除，支持删除时返回被删除记录

6、query：使用组合主键时查询同一Hash Key的多条记录或某些属性，可指定Range Key范围条件及读一致性要求，可指定返回条数限制。操作保证按主键顺序返回记录，因此可通过在下一条查询时指定上次返回的最大主键作为起始点来实现分页

Query时可指定range key的范围条件(EQ, NE, BETWEEN,  BEGINS_WITH)来缩小返回记录数。

DynamoDB中的数据是以 primary key索引， 在同一个primary key下的多条记录以RANGE key排序存储。

7、scan：表扫描，可指定多个过滤条件，可指定返回条数限制。实现分页的方法同query

可以看到DynamoDB不但提供了单记录的CRUD操作，还提供了条件更新、多记录读、范围扫描、全表扫描等功能，还算比较灵活。

此外，还 可以用MapReduce来分析DynamoDB中的数据。特别的，因为DynamoDB已经是表结构，可以很方便的用Hive来分析。

三、其它

DynamoDB的数据至少都会同步复制到在同一Region的3个以上的数据中心，因此可用性和数据可靠性非常好。

DynamoDB的计费模式中最显著的特点是按读写操作的能力收费，用户要指定每张表第秒能提供多少次读写操作。费用价格为0.01$/小时.10 Write Capacity+0.01$/小时.50 Read Capacity，最终一致性读操作半价。另外存储费用为存储1$/GB.月，操作超过1KB的对象还要另收费。可以看到DynamoDB的存储费用是S3的7－18倍，估计是因为用了SSD带来的成本提高。

四、读后感

数据库，最简单的莫过KV，最复杂多能的莫过传统关系数据库。现在一般认为KV太过简单，关系数据库太过复杂，怎么才是最好的中庸之道，是大家都在探索的问题。时至今日，各项技术都明了，难做的是怎么取舍。DynamoDB是Amazon基于多年经验给出的答案，其特点是类似于关系表但Schemaless的灵活数据模型、组合主键、条件更新、可选的一致性读、受限的范围扫描、全表扫描等，没有多记录原子操作。以Amazon的经验，这些取舍当然值得重视。但并非唯一，如在数据库领域更富有经验的Oracle做的NoSQL数据库则包含多记录原子操作功能。

Amazon 发布DynamoDB NoSql 服务:  http://www.cnblogs.com/raymondshiquan/articles/amazon_dynamo_service.html

http://hb.qq.com/a/20120410/000144.htm

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