2023年7月21日发(作者：)

DynamoDB和MongoDB分析⽐较DynamoDB是Amazon最新发布的NoSQL产品。本⽂在介绍DynamoDB特性的基础上，将其与SimpleDB、Cassandra和MongoDB进⾏了分析和⽐较。DynamoDB简介在NoSQL概念⽇益⽕爆的今天，市场上⼜增加了⼀个重量级的NoSQL产品—DynamoDB，它是Amazon AWS于2012年1⽉18⽇发布的。⼀看到这个名称，很多⼈都会想起2007年Amazon发表的Dynamo论⽂。⼈们经常将这篇论⽂与Google的BigTable相提并论，这在当时带来了相当⼤的影响，很多产品都借鉴了Dynamo的思想，⽐如Cassandra。那什么是DynamoDB呢？按照AWS CTO Werner Vogels的说法：“DynamoDB是⼀个性能好、可靠⾼且具有可扩展性的NoSQL云数据库服务，DynamoDB集15年分布式⾮关系性数据库开发之精粹，⼜通过内部使⽤考验，是AWS团队精⼼打造的产品。”本⽂将通过DynamoDB的特性、数据模型，以及API来进⾏深⼊的介绍。从官⽅⽂档来看，DynamoDB有以下⼏个特性。稳定的性能保证。为了保证⾼性能，DynamoDB采⽤固态硬盘（SSD）进⾏存储，对于⼀般的请求，DynamoDB在⼗毫秒内就可以完成，⽽且处理请求的速度不会随着数据量的增加⽽减慢。读/写流量限制预设（Provisioned Throughput）。这个概念和我们经常接触的按带宽收费⾮常相像，⽤户必须指定对数据库的读/写带宽，Amazon会按⽤户设置的读/写带宽收费。但与传统的带宽收费不同，⽤户可以随时通过控制台或者API更改数据库的读/写流量的限制。⾃动扩容。DynamoDB不会对⽤户的数据规模⼤⼩做任何限制，后台会默默地把⽤户的数据分布到各个机器上去。强⼀致性。⽤户可以通过参数指定要读的数据是否需要⼀致性。这⾥需要注意的是，如果读的数据全是要求强⼀致性的话，那么在设置读流量上限时需要设置成实际读流量的两倍。?完全分布式，⽆中⼼化架构。⼀个表上的数据可以分布到⼏百台机器上。Schema free。都叫NoSQL了，Schema必须free。和Amazon Elastic MapReduce深度整合。在EMR上可以调⽤DynamoDB的数据进⾏MapReduce，并将计算结果保存到S3，同时也可以⽤EMR对DynamoDB做备份。容灾。容错、完善的监控、安全、物美价廉、管理⽅便，这些都是云服务应该做到的。⼤家第⼀眼看到Provisioned Throughput时，都会觉得这个概念⽐较别扭。为什么要给⾃⼰限制读/写流量呢？但仔细分析之后⼤家会发现Provisioned Throughput是迫不得已的做法，⽽且前三个特性其实也与之有着不可分割的关联。DynamoDB是⼀个共享型的数据库云服务。所谓共享型的数据库云服务，是指⼀台机器上的CPU、内存及磁盘资源会给多⽤户使⽤。共享型服务最⼤的问题在于资源的公平性，如何保证⼀个⽤户对资源的使⽤不会影响到其他⽤户？例如，⽤户A在DynamoDB上保存了10GB的数据，假设这10GB数据全部保存在同⼀台机器上，⽽且这台机器的读性能只有1GB/秒。此时，如果⽤户每秒要读1GB数据，必然会影响到其他⽤户对同台机器上的数据访问，因为⼀台机器的吞吐量是固定的。这样就没有办法做到每个⽤户每个请求都有稳定的性能保证。正如各种MySQL共享服务会根据⽤户预购买的数据空间来限定每秒的请求数来解决资源公平性⼀样，DynamoDB利⽤Provisioned Throughput来解决资源公平性。如果⽤户的读/写请求量变⼤，就得提⾼读/写请求的带宽上限，付更多的钱，DynamoDB同时会根据⽤户购买的带宽将数据分散到更多的机器上。⽬前，单表最多⽀持10000个1KB 读/写（相当于10MB/s的读写），单⽤户最多20000个1KB读/写（相当于20MB/s的读写）。如果需求增加，则需要填表单独申请。同时还有更多详细的规定，具体详见⽤户⼿册（其实所有的规定都是受到资源公平性以及后台具体实现的约束）。从DynamoDB的数据模型来看，Attribute、Item和Table是DynamoDB中的三个基本概念。Attribute。⼀个Attribute是⼀个name-value对，其中value可以是string、number、string set、number set，⽐如：“ID” = 1“Title” = “Programmer”“Tags” = “DynamoDB”, “AWS”, “CSDN”“Ratings” = 6, 7, 5Item。Item是由多个Attribute组成的，相当于⼀个JSON字符串，每个Item的Attribute 不同，但同⼀个Table的Item都必须指定为Primary Key的Attribute。Table。由多个Item组成，其概念和关系型数据库的Table类似，相当于MongoDB的Collecion。DynamoDB并没有DB的概念，⽽且⽬前单⽤户最多只能创建256个Table。每个Table 都必须要⼀个Primary Index。Index有两种Primary Key：Simple Hash Key和Composite Hash Key with Range Keys。Simple Hash Key。这个Key对应的Attribute在每个Item⾥都必须存在⽽且唯⼀。Composite Hash Key with Range Keys。顾名思义，在Hask Key的基础上，⽤户可以增加⼀个Attribute作为范围查询的Key。此时不需要保证Hash Key的唯⼀性，只需要这两个组合Key是唯⼀的就可以。这在我们做时间范围查询时⾮常有⽤，⽐如某个⽤户在24⼩时内访问过的⽹页。DynamoDB共提供了11个API接⼝，如表1所⽰。表1 Dynam oDB提供的11个API接⼝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的差异。在这⾥我将这两者和⽬前⽐较⽕的MongoDB放在⼀起进⾏⽐较，如表2所⽰。表2 Dynam oDB和Cassandra、MongoDB的⽐较虽然Jonathan Ellis认为DynamoDB不⽀持Secondary Key Indexes是在开历史的倒车，但如果DynamoDB⽀持了SecondaryKey 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最⼤的价值所在。