dynamodb

AmazonDyna浓moDB被设计成用来托管的NoSQL数据库服务、可预期的性能、可实现无缝扩展性和可靠性等核心问题。

• 外文名称 dynamodb
• 释义 完全托管的NoSQL数据库服务
• 性能 提供快速的、可预期
• 特性 可扩展性

简介

　　Amazon DynamoDB是一个完全托管的NoSQL数据库服务，可以提供快速的、可预期的性能，并且可以实现无缝扩展。只来自需要在AWS(Amazon Web Service)管理控制台上面，用鼠标轻听国构令未图松点击几下，用户就可以自己创建一个新的Amazon DynamoDB数据库表，并可以根据实际需求对表进行扩展和收缩，这个过程既不需要停止对外服务，也不会降低服务性能。通过AWS管理控制台，用户还可以看见资源利用情况和各种性能指标。Amazon DynamoDB可以使得用户把操作和扩展分布式数据库的沉重负担，交付给AW360百科S来处理，这样，用户就不需又临取易交联稳兰沉胶要担心硬件配置、复制照、软件安装和打补丁包、簇扩展等。

　　DynamoDB是亚马逊的key-value模式的存储平台，可用性和扩展性都很好，性能也不错:读写访问中99.9%的响皮川广晚料连整星急预应时间都在300ms内。DynamoDB的NoSQL解决方案，也是使用键/值对存储的模式，而且通过服务器生河政结征失把所有的数据存储在SSD上席沿量般长需光将酒的三个不同的区域。如果有更高的传输需求，Dy吃namoDB也可以在后台添加更多的服务器。

　　Am自子清单宪变因精由azonDynamoDB被设计成用来解决数据库怎钱未立固称统亚管理、性能、可扩展性和可靠性参等核心问题。开发人大氧布越快陆处商治改员可以创建一个数据库表，该表刘年杨衣重些油可以存储和检索任何数量的数据，并且可以

功能

　　如果要使用Amazon 冷DynamoDB，你只需要:

　　使用AWS管理控制台或者AWS DynamoDB API来创建一个表，并且确定你所需要的请求容量。

　　使用Amazon DynamoDB API进行写和检索数据的操作;

　　使用AWS管理控制台中Amazon CloudWatch，对你的AWS DynamoDB数据库的表的状态和性能进行监视;

　今很　为你实际使用的资源付费:你每个月的消费账单，是基于你确坚作湖差突黑育定的表的处理请求能力和存储的数量;

特性

　　1、可扩来自展性:AWS DynamoDB的设计，可以支持在吞吐量和存储能力上的无缝扩展;

　　额定的吞吐量:在创建一个表的时候，可以很简单地设定你的表所需360百科要的处理请求的能力。AWS DynamoDB会根据你的处理能力要求，为你的表分配专用的资源，从而满足你的性能需求，并且会把数据分区到足够多的服务器上，从而满足你对处理能力的要求。如果你的吞吐量需求改变了，你可以使用AWS管理控制台或者AWS DynamoDB API对你的表所需要的处理请求的能力进行修改。当扩展正在进行时，你仍然可以获得先前级别的处理能力。

　　自动存储扩展:AWS DynamoDB没有对一个表中可以存储的数据量的大小进行限制，当你使用AWS DynamoDB的写操作API存入更多数据时，就会自动为你分配更多的存储空间。

　　完全分布式、非共享架构:AWS DynamoDB可以实现水平扩展，可以无缝地把一个表扩跑展到多个(几百个)服务器上。

　　2、快速、可预期的性能:AWS Dyna是九moDB的服务端的平均延迟，通常是几毫秒(millisecond)。运行北接机都征企临还在固态盘上面的服务，可以在任何扩展级别下维持一致性和低延迟。

　　3、简易的管理:AWS DynamoDB是一个完全托管的服务，你只需要简单地创建一个数据库表，剩下的所有事铁器刻口情都交给AWS服务来处理。你不需要担心硬件和软件的配给、油亲建立、配置，也不要担心软件安乱爱列尽测装和打补丁包，更不必担心如何运行一个可靠的分布式数据库簇，或者把数据分区到多个实例。

　　4、内置的容错性:AWS Dy苏望注稳富较掌namoDB具有内在的容错能力，可以自动、同步地把你的数据复制到一个Regi顶袁听格他输数劳针族坐on中的多个可用的Zone祖热频服中，即使遇到单个机器或设施的实效，你的数据也可以得到很好的保护。

　　5、灵活性:AWS DynamoDB没有固定的模式(schema)。相反，谈石起烟球无还农物粮密每个项目(item)都具有不同数量的属性，可以支持多种数据类型，比如string、number和set。

　　6、强一致性、原子计数器:和许多场普语原春非关系型数据库不同，AWS DynamoDB使你的开发工作变得更加简单，它可以支持读操作的强一致性，从而保证你可以总是获供云者也剧命本万围识得最新的数据。读操作支持多个本地(native)数据类型，比如number、string和否帝想委端械项multi-value attribute。这种服务也可以支持原子计数器(Atomic Counter)，允许你通过一个简单的破亮宜世常运API调用就可以皇终副坐刚有根保茶自动增加和减少数值属性。

　　抗滑的7、性价比高:AWS DynamoDB被设计成在任造何级别的负载下都可以取得很高的性价比。你可以从一个免费的等级开始，这种级别只支持每个月4000万次的数据库操交升延扩距相振作，对于超出这个免费级别的范围，你只需要为你使用的资源支付以小时计费的很低的费用。由于具备了简易的管理和高效的请求定价能力，采用AWS DynamoDB相比采用其他非关系型数据库而言，具有更低的总体拥有成本(TCO:total cost of owership)。

　　8、安全:AWS DynamoDB使用可靠的密钥方法，只允许授权用户访问数据，而绝对不允许非授权用户的非法访问。AWS DynamoDB集成了AWS Identiy and Access Management(简称AWS IAM)，可以实现更细粒度的访问控制。

　　9、集成的监视功能:AWS DynamoDB可以在AWS管理控制台中，把关于你的表的关键性能指标都显示出来。同时还集成了Amazon CloudWatch，可以让用户每个表的请求吞吐量和延迟，从而很容易实现对资源的跟踪。

　　10、弹性的MapReduce集成:AWS DynamoDB同时集成了Amazon Elastic MapReduce(简称Amazon EMR)。Amazon EMR可以支持对大型的数据集执行复杂的分析操作，并且采用AWS中按需付费的Hadoop框架。随着AWS DynamoDB的发布，对于用户而言，很容易使用Amazon EMR来对存储在DynamoDB中的数据集进行分析，并且把分析结果存储在Amazon Simple Storage Service(简称Amazon S3)中，而原来的数据仍然原封不动地保存在AWS DynamoDB中。用户也可以使用Amazon EMR来访问存储在多个地方的数据，比如AWS DynamoDB、Amazon RDS和Amazon S3，并且对来自这些地方的数据进行合并以后，做更加复杂的分析，并且把分析结果存储在Amazon S3中。

比较

　　DynamoDB和SimpleDB的区别

　　熟悉Amazon AWS的朋友应该知道SimpleDB。细心的朋友还会发现，自DynamoDB上线以后，在AWS首页的Database列表中，只能看到RDS和DynamoDB，DynamoDB已经替换了SimpleDB原来在这个列表中的位置，似乎SimpleDB已被打入冷宫

　　SimpleDB是AWS上的第一个NoSQL数据库服务，AWS团队也在博客上详数SimpleDB几个致命的缺点，正是这些缺点导致AWS开发全新的数据库服务。

• SimpleDB有单表限制。SimpleDB也有类似于Table的东西叫做Domain，每个Domain最多只能保存10GB的数据，而DynamoDB并没有单表存储的任何限制。虽然SimpleDB提供的Schema Free可以提高开发者的效率和灵活性，但10GB这种无法扩展的限制妨碍了很多开发者的使用，使得很多开发者采用了其他NoSQL解决方案。
• 性能不稳定。SimpleDB以简单为设计目标，SimpleDB并不需要用户指定Primary Key，也不需要用户创建索引，会默认对所有Attribute创建索引。然而这种简洁性也带来了一些副作用:如果用户插入的一条数据带有非常多的Attribute，SimpleDB就需要去更新所有Attribute的索引，而且不管用户将来是否需要。真是所谓的:用或者不用，索引就在那里。正是由于默认对所有Attribute创建索引，整个Domain才会有10GB这么奇怪的限制，以避免数据量变得比较大时，创建索引的过程会变得极慢无比，根本不能忍受。而DynamoDB因为有了Provisioned Throughput的限制以及采用了固态硬盘，可以保证每个请求的性能是非常稳定而且高效的。
• 一致性问题。SimpleDB设计时采用的是最终一致性模型，而DynamoDB读数据时用户可以选择弱一致性或者强一致性，对用户而言可以根据业务特征来进行选择，毕竟强一致性在逻辑上更容易让用户接受。

　　在Schema上，两者都不需要固定Schema，但value类型不够丰富，在API设计上DynamoDB继承了SimpleDB的风格，请求的参数个数显得比较臃肿，好在有不同语言的SDK，方便了用户的开发。

　　DynamoDB不是SimpleDB 2.0，但DynamoDB也吸收了SimpleDB以及其他NoSQL数据设计思想的精华，相信会有不少用户会采用DynamoDB作为他们的NoSQL解决方案。

　　DynamoDB和Cassandra、MongoDB的比较

　　前面说过Cassandra受2007年Amazon发表的Dynamo论文影响非常深，在DynamoDB发布的第一天，提供Cassandra商业化支持的DataStax公司的Jonathan Ellis就写了一篇文章，分析了Cassandra和DynamoDB的差异。

　　虽然Jonathan Ellis认为DynamoDB不支持Secondary Key Indexes是在开历史的倒车，但如果DynamoDB支持了Secondary Key Indexes，那么它是无法保证每个请求性能的高效性的。这和DynamoDB的设计理念相冲突，于是舍弃了这部分的功能。

　　其实从开发的易用角度来讲，DynamoDB没有Cassandra和MongoDB强大，Cassandra有CQL可以做非常丰富的查询，MongoDB的查询功能也非常强大，而且后两者都提供Shell客户端，并有不少第三方开发的工具可以进行管理与使用。在条件更新上，DynamoDB也没有MongoDB使用起来那么方便，并且MongoDB提供了更多的原子性操作。在对value类型的支持上，另两者都不如MongoDB，毕竟MongoDB是文档型的数据库，可以理解为底层存储的是JSON。毕竟，JSON支持的类型以及在JSON上可以做的操作是很丰富的。我一直觉得DynamoDB没有支持类JSON格式是个遗憾。也许可能是DynamoDB团队觉得如果支持类JSON格式的话，在API的设计上会显得更加臃肿和让用户更难理解API如何使用。但个人认为，DynamoDB如果提供相应的SDK其实是可以解决这个问题的，就算MongoDB的开放接口相对DynamoDB更加复杂，开发者都是直接使用驱动(相当于SDK)进行开发，于是在开发应用上MongoDB远胜于DynamoDB。

　　但从运维的角度来讲，DynamoDB省去开发者部署/监控/维护数据库环节，给开发者节约了大量时间，强大的扩展能力又减轻了后续运维的压力，这正是DynamoDB最大的价值所在。

发展现状

　　亚马逊的Dynamo数据库(DB)是增长速度最快的亚马逊网络服务(AWS)产品之一。DynamoDB是一个提供自动化的可扩展性和配置IOPS的键-值数据存储服务。对于开发人员和更喜欢使用一个托管服务来管理他们自己的NoSQL数据库的应用程序管理员来说，亚马逊的DynamDB是一个不错的选择。对于已经投入时间和资源建立IAM策略的AWS用户来说，这是特别有吸引力的，因为他们可以精细地控制对保存在亚马逊DynamoDB中数据的访问。

　　为了在亚马逊DynamoDB中保持细粒度的访问控制，管理员们必须在IAM策略中指定条件。条件可以允许或拒绝对键-值数据存储中特定项和属性的访问。这一模式限制了对特定值或行的访问，例如与特定客户账户相关的数据，这样一来客户就只能查看他们自己的数据了。它还允许应用程序管理员们为访问特定属性而定义规则。例如，一个策略可以指定只有甘愿而非顾客可以查看数据库中的一个类别属性。