Amazon S3 & Simpledb内部实现分析

超、凢脫俗 2021-10-19 16:28 290阅读 0赞

作者: [Chuanhui][] | 可以转载， 但必须以超链接形式标明文章原始出处和作者信息及版权声明  
本文链接地址: [http://www.nosqlnotes.net/archives/163][http_www.nosqlnotes.net_archives_163]

Amazon S3申请了一篇专利，名称为”[Keymap Service Architecture for A Distributed Storage System][]“，而Amazon Simpledb的实现细节暂时没有公开。本文根据Dynamo论文，S3专利以及S3&Simpledb的对外API尝试推测这两个系统的内部实现。

对外API

1, S3：撇开S3系统中的Region, Bucket，用户权限管理等，和底层存储系统相关的API只有如下几种：

*  Put Object：将object加入到bucket中，即加入<bucket, name> => object 对；如果多个客户端并发更新同一条记录，最后一个更新覆盖所有其它的更新；
 *  Get Object：获取指定的object，即根据<bucket, name>获取object内容；
 *  Delete Object：删除指定的object，即根据<bucket, name>删除object；
 *  List Objects：批量读取操作，可以获取用户所有的object；

S3中有一些看似很牛的特性，比如单个object最大支持5TB。

2, Simpledb：相比S3, Simpledb支持更多的功能，比如表schema；另外，Simpledb还支持乐观锁机制以及强一致读，这和S3有很大的区别。Simpledb中domain相当于一个table，item相当于一行，attribute相当于一列，一列可以有多个值。Simpledb底层存储系统相关的API如下：

*  GetAttributes：获取一行的某些列，随机读取操作；
 *  PutAttributes：修改一行的某些列。
 *  DeleteAttributes：删除一行的某些列或者删除整行；
 *  Select：获取一个用户多行数据，范围查询操作，支持属性过滤，排序等，类似关系型数据库的SELECT；
 *  强一致性读：与S3不同，Simpledb支持强一致性读取最近的更新；
 *  条件更新或者条件删除：当满足一定条件，比如某一行，某一列是否存在或者某一列值符合某个特征时执行PutAttributes或者DeleteAttributes操作；

内部实现

Amazon S3和Simpledb看起来挺类似的，很容易让我们联想到Dynamo，然而，二者的一致性有很大的区别。Amazon S3一致性模型为弱一致性，只支持最基本的Put/Get/Delete操作，且每个操作之间是互相独立的。而Simpledb除了支持Get/Put/Delete以外还需要支持强一致读以及基于条件更新或者删除的乐观锁机制，二者的实现上有很大的差别。

Amazon S3起源于Dynamo，基本可以认为是Dynamo(称为Keymap) + Blob File System(称为Bitstore)。其中，Bitstore系统中存储多份用户Object序列化后的内容，Keymap存储对象名(name)到对象(object)在Blob File System中多个存放位置的映射。与Dynamo不同的是，Amazon S3直接使用”last write wins”的方式解决冲突，这是因为集群内部机器时钟不一致的概率很小，另外，发生同一条记录被多个客户端并发更新且同时发生机器故障等异常情况的概率也很小。更为重要的是，S3系统中的各个操作之间是互相独立的，任何操作都不需要依赖上一个操作的返回结果，不需要支持事务，即使出现极小概率的异常情况，用户仍然可以接受这种弱一致性。S3还支持一些很酷的功能，比如最大的对象可以达到5TB，但是这对于S3的存储架构并没有带来太大的挑战，让Bitstore支持少部分大文件并不是什么很难的事情，只是需要控制这样的文件不要过多。

而Amazon Simpledb显然不能接受这种弱一致性，因为它需要支持一些条件更新或者删除，从而支持乐观锁机制，以实现类似原子计数这样的操作。因此，Amazon Simpledb对于更新操作选择了强一致性，这也就意味着同一份数据同一时刻只能被一个节点更新，即Simpledb采用了传统的基于commit log的replication模式，因此，系统能够支持条件更新和删除也就不奇怪了。Simpledb的强一致读通过强制读主节点实现，但是可能出现主节点宕机时无法提供服务的情况，因此，增加另外一种最终一致读模式，允许读其它副本。对于用户而言，如果没有碰到异常情况，强一致读和最终一致读延时相当，基本感觉不到差别。

一致性选择

S3和Simpledb最大的区别还在于一致性选择，初期的S3选择走Dynamo的技术路线，后来的系统发现这个路线不容易走，比如用户迫切希望的乐观锁和强一致读功能无法实现，因此Simpledb对于更新操作选择强一致性。Simpledb支持乐观锁机制并提供了简单的SQL Select子集支持，我认为这个系统的设计是比较优雅的。

数据划分

S3的数据划分这里不想多说，感兴趣的同学可以复习Dynamo论文，而Simpledb的数据划分显得更有意思。第一种数据划分的思路可以参考Bigtable&Megastore这样的系统，同一个用户的数据连续存放，但单个子表的大小一般是100MB ~ 200MB之间，同一个用户的数据可能被分散到多台机器。Bigtable的数据划分是动态的，这样在负载均衡上能够获得很多好处，但是Bigtable的方案要求支持子表的分裂和合并，实现非常复杂。而Amazon Simpledb更像是一个分布式Hash系统，数据划分是静态的，数据按照domain哈希划分到多台机器，这样的好处是实现简单，问题是同一个domain在一台机器，一个用户的多个domain不怎么连续，因此，对用户使用有一些限制。比如，”Simpledb中一个domain只能有1 billion attribute，大小不超过10GB”，然而，这对于用户而言显然是很不友好的。

分析

从Amazon S3到Simpledb的系统演近过程中我们看到了Amazon在一致性考虑上的思路转化，同时我们也分析了Simpledb限制同一个domain不超过10GB的原因。在云存储的道路上，不管是采用可扩展性优先的思路（如Google），还是采用功能优先的思路（如Microsoft），采用分布式B+树的数据结构还是采用分布式Hash表数据结构，都会碰到各种各样的问题。

【注：Simpledb的设计资料由于没有公开，文章中某些观点来源于作者的推测，作者认为这种做法是work的，但不保证和Simpledb内部相同。欢迎讨论！】

[Chuanhui]: http://www.nosqlnotes.net/
[http_www.nosqlnotes.net_archives_163]: http://www.nosqlnotes.net/archives/163
[Keymap Service Architecture for A Distributed Storage System]: http://www.google.com/patents?id=HmjLAAAAEBAJ&printsec=abstract&zoom=4&source=gbs_overview_r&cad=0#v=onepage&q&f=false