Amazon DynamoDB, 面向互联网应用的高性能、可扩展的NoSQL数据库

DynamoDB是一款全面托管的NoSQL数据库服务。客户能够很easy地使用DynamoDB的服务。同一时候享受到高性能，海量扩展性和数据的持久性保护。

DynamoDB数据库是Amazon在2012年1月18日公布的。

它融入了亚马逊在大规模非关系型数据库和云计算领域积累的多年丰富经验。事实上早在2007年。亚马逊就以前公布了一篇论文。深入讨论了AmazonDynamo所使用的设计理念和实现技术，而且讨论了怎样在大规模扩展的同一时候提供高可靠的数据保护的问题。

最初的Dynamo设计基于一系列核心原则。以实如今分布式系统中搭建高可靠、高扩展系统。

如今的Amazon
DynamoDB，继续基于这些设计原则来构建。可是同一时候融入了Amazon多年以来在非关系型数据库和云计算领域积累的宝贵经验，比方Amazon SimpleDB和AmazonS3服务的技术。客户能够很easy的方式使用到全然托管的数据库服务。

AmazonDynamoDB 是高性能、可扩展的NoSQL数据库。今天的互联网应用的用户、流量和数据都在不断地增长。数据库怎样非常好地扩展。以满足互联网应用对容量和性能的需求是让非常多客户头疼的问题。DynamoDB非常好地攻克了这一难题。使用DynamoDB。开发人员能够从相对小的规模開始，在应用吸引了很多其它用户的时候，对应地添加DynamoDB的表的性能。

DynamoDB中的表没有不论什么容量限制。通过分布式的技术。DynamoDB把用户对一个表的数据和流量请求分布在足够数量的server上，以满足并发请求的性能要求。同一时候，在面对不论什么规模的请求的时候，DynamoDB都能够提供能够预測的高性能低延时的用户体验。

我们在国内的客户，木瓜移动，就是採用了DynamoDB的数据库服务，在RTB实时竞价的在线移动营销领域获得成功。AppFlood是木瓜移动公布的移动实时竞价的广告平台。作为AppFlood的核心组件，数据库的性能非常大程度上决定平台的实时竞价的能力。

非常多因素，如网络通讯延迟、数据库数据读取的延迟、定价算法的延迟都可能造成竞价过程超时。提供稳定的高性能、低延迟响应的DynamoDB，非常大程度上帮助木瓜移动搭建成功的RTB平台。

DynamoDB给用户提供了例如以下价值：

• 使用简单。DynamoDB帮助用户处理全部的数据库管理工作，从硬件资源配置，安装配置，分布式集群的搭建。和日常的系统维护。开发人员能够从繁琐的数据库管理工作解放出来。

  作为全然托管的数据库，你不须要专家的技能来管理DynamoDB的安装-你的开发人员全然能够独立完毕。訪问DynamoDB的时候，能够通过简单地API的方式。眼下通过只13个API，你就能够实现对DynamoDB数据库的表的管理，查询检索操作。单个项目Item的訪问和实现批量存取项目。

• 可扩展。Amazon DynamoDB的设计，没有不论什么容量上得限制。能够把单个表的数据，分布在多个可用区内的多台server上。来满足容量和吞吐的需求。

• 高性能。在高并发请求的情况下。DynamoDB仍然能够保证非常低的延时。

  由于全部数据都存储在固态磁盘上。所以能够保证持续的高性能。

  执行在同一个区域的EC2上的应用程序，在訪问DynamoDB的数据对象的时候，通常能够在server端体验到个位数毫秒的响应时间。更重要的是，DynamoDB的表的性能是能够预測的。即使在数据增长的情况下。由于DynamoDB分布式的特点。仍然能够维持稳定的低延时的响应。DynamoDB在后台把你的数据在大量资源之间进行分区和在须要的时候又一次分区，从而能够在大规模訪问的情况下还能提供非常高的IO性能。

• 持久和高可用。AmazonDynamoDB自己主动地在至少3个数据中心内复制数据。每一个写操作。在至少写入两个节点之后，才会返回写成功确认。

  在不论什么一个节点或者磁盘发生损坏的时候。数据都会及时的又一次复制数据和又一次分区。

  这样能够确保在各种复杂的故障出现的时候，DynamoDB仍然能够正常的提供服务，你全然不须要操心由于物理故障造成的数据丢失的情况。

除了上述的优点之外，作为一款云上的全面托管的数据库服务，DynamoDB还有非常多不同的地方。比較特别是它提供预先配置的吞吐量目标。

曾经大家在使用数据库的时候。想要准确的获得你所预期的性能指标，包含响应时间和吞吐量。是一件非常复杂的事情。你须要配置不同的硬件资源。包含CPU。内存，存储容量和性能等等，然后期望这样特定的硬件资源能够非常好地支撑你的数据库的性能需求。但实际上。你想要的数据库性能是响应时间，和每秒钟支持事务量，它们和硬件资源之间没有准确的相关性。

非常多时候数据库的性能容量规划都像一个科研项目。充满了不确定性。DynamoDB非常好地攻克了这个问题。

用户在開始创建DynamoDB的表的时候，能够配置应用所须要支持的吞吐量目标。你能够分别指定表每秒钟支持多少个读取和写入的请求。完毕目标设定后。DynamoDB将会为你预留必要的机器资源，从而确保仅仅要是在给定的并发訪问量以下，应用就能够享受到个位数毫秒的低延时的高速响应。

更重要的是，预配置的性能容量目标不是一成不变的。

假设你的数据库的訪问量有了大幅度的增长，你能够随时调大DynamoDB的表的容量目标，从而支撑很多其它的訪问请求。对应地，假设你的应用不再须要之前预配置的并发訪问容量。你还能够灵活地减少预配置的容量指标。从而帮你减少成本。

使用DynamoDB能够让开发人员灵活地开发应用程序。DynamoDB是模式自由的。这样用户不会被限制在某一个特定的数据模型里。传统的SQL数据库中，表的模式在创建的时候就定义好。

你不能改动或者添加新的列到一个已经创建好的表中。Amazon DynamoDB没有一个固定的模式，这样开发人员能够随时给表添加新的属性。灵活的数据模型能够让开发人员更加方便地进行敏捷开发和应用的高速迭代更新。

当然，和不论什么分布式的系统一样，使用DynamoDB也须要注意一致性的问题。DynamoDB把一致性的选择权交给开发人员，让开发人员自由地选择适合自己应用的一致性模型。

在读取数据的时候，开发人员能够选择採用强一致性的方式，还是终于一致性的方式来读取数据。

假设是终于一致性的方式，意味着应用在刚提交一个写操作之后，假设立即进行读取，可能无法读取到最新的数据，可是终于你会读的一致的数据。

终于一致性的模型能够在最大程度上确保服务的可用性，而且改善性能。比較典型的场景是大家在网上购物时使用的购物车。或者站点的评论信息等等。这些场景对于一致性没有非常严格的要求。

假设选择採用强一致性的方式读取数据，可能会牺牲一定程度的性能和服务的可用性。优点是在不论什么情况下都能够訪问到最新的数据。软件开发也比較简单。

比較典型的用例是须要强一致性的场景。比方网上购物时提交订单的场景。

须要使用强一致性来确保同一商品不会同一时候销售给两个不同的客户。

使用DynamoDB的成本是能够预測。DynamoDB的定价模式很easy。基于每月每GB的存储容量。和每月预配置的读取和写入的吞吐量容量单位计费。容量比較easy理解。吞吐量容量单位是个比較重要，大家也比較陌生的概念。每一个读取容量单位（或者写入容量单位）支持每秒钟进行1次读取（或者写入）1个项目(item)。每一个读取操作最大4KB大小，每一个写入操作最大1KB大小。

超出大小的项目(item)须要额外的性能吞吐容量。

举个样例，比方你配置了1000个读取吞吐量容量单位，和1000个写入性能的吞吐量容量单位。

这样的情况下你的表将能够支撑每秒钟1000个读取操作，和1000个写入操作。假设是终于一致性的方式来读取的话，你的表将能够支撑每秒2000个读取操作。

DynamoDB还提供了其它功能来进一步提高应用訪问的性能， DynamoDB能够创建和维护针对主键属性的索引。应用程序把须要查询的主键提交给数据库。就能非常快地获得所相应的数据集。除此之外，Amazon DynamoDB还支持创建全局和本地的二级索引。使用二级索引，能够让应用程序在查询主键以外的其它属性时。也能够获得非常好的性能。客户能够对一个表创建一个或者多个二级索引，然后对索引执行查询query的操作。

Amazon DynamoDB能让用户以简单而且经济有效地方式存储和检索随意规模的数据。同一时候提供高并发下地低时延的响应。对于吞吐量的保证和几毫秒的低时延响应，使DynamoDB很适合游戏、广告、移动等等基于互联网的应用程序。

假设您想要了解更具体的信息。能够訪问DynamoDB页面。