淘宝Oceanbase云存储系统实践

常见的Key-Value系统的数据结构一般为分布式Hash表，只支持基本的Put、Get和Delete操作，比如Amazon的Dynamo和S3系统。而Amazon Simpledb按照domain进行数据划分，规定同一个domain数据量不能超过10GB，从而可以存放到一个数据节点，用户只允许在同一个domain内部执行范围查询操作。Amazon的云存储系统看起来不完美，但相当实用。

Google的系统设计之初就强调可扩展性。从最初的GFS到BigTable，再到后来的Megastore、Percolator，Google先将系统的可扩展性发挥到极致，以后再逐步加入分布式事务、SQL支持等功能。这样的设计得益于Google强大的工程师团队和公司一直以来崇尚通用系统的文化。Google的云存储分为两层：分布式文件系统GFS和分布式数据库系统BigTable，GFS是一个带有追加功能的分布式文件系统，BigTable将事务的提交日志追加到GFS中做持久化。数据在BigTable内连续存储，逻辑上构成一棵分布式B+树，Megastore、Percolator又在BigTable的基础上加入分布式事务、索引、SQL支持等功能。Google的系统设计比较贵族化，可以远观，但模仿前请三思，比如将系统分成多层可能会增加用户操作的延时，对工程师的设计编码能力提出了更高的要求。

Microsoft SQL Azure是一个传统数据库厂商在云存储系统设计上给出的答案。当数据量增长时，必然要求牺牲部分功能来换取可扩展性，这对于Microsoft是不愿意看到的。Microsoft直接在原有的关系型数据库SQL Server上进行分布式扩展，尽可能多地支持SQL功能，其功能非常丰富，但系统内部不支持SQL Azure实例的分裂和合并。因此，SQL Azure内部也限制了单个SQL Azure实例允许的最大数据量，如Business Edition的最大数据量不超过50GB。相比Google的系统，Microsoft系统的扩展性较弱，但功能较强。

云存储系统的难点在于状态数据的迁移和持久化，状态数据也就是系统的事务提交日志。Google BigTable通过分布式文件系统GFS持久化提交日志，Microsoft SQL Azure直接将提交日志通过网络复制到数据的多个副本，而PNUTS通过Yahoo!内部的分布式消息 中间件Yahoo! Message Broker持久化提交日志。Yahoo!没有对外提供 云存储服务，但这样的设计可扩展性也是相当不错的。

淘宝Oceanbase架构设计

淘宝Oceanbase是从2010年5月开始研发的，其定位是解决淘宝内部在线业务的云存储问题。我们在设计系统时，总是考虑现在及今后一段时间的需求。互联网业务大致可以分为OLTP和OLAP两类，对 在线存储的需求简单归纳如下。

OLTP和OLAP业务对性能的要求使我们必须采用分布式方案。另外，淘宝的业务发展迅猛，传统的分库/分表方法带来的扩容及运维成本太高，必须构建异构的云存储系统。通过进一步分析在线业务，我们发现互联网在线存储业务有一个特点：数据量虽然很大，但新增数据量比较小，每天新增数据量基本在1TB之内。此外，淘宝的业务面临一些其他挑战，比如需要高效支持跨行跨表事务，需要支持两张几亿到几十亿条记录的大表进行联表操作。淘宝的海量数据以及复杂的功能需求对存储系统的设计提出了新的挑战，关系型数据库在数据量上有点儿力不从心，而云存储系统又不能高效地支持复杂的功能要求。因此，需要融合关系型数据库的功能和云存储系统的可扩展性这两个优点。

如何借鉴已有技术满足淘宝未来一段时间内的云存储需求？如果直接模仿国外的互联网巨头，比如模仿GFS + BigTable，淘宝的团队确实有一定的经验。然而这样的系统在两年之内很难稳定，并且不能满足跨行跨表事务等复杂的功能需求。既然在线业务新增数据量比较小，那是否可以把最新修改的数据和以前的数据分离呢？

答案是肯定的。淘宝Oceanbase将数据分成动态数据和静态数据两部分：动态数据的数据量较小，侧重TPS和QPS，采用集中式的方法存放到单个节点的高品质存储介质，如内存和 SSD；静态数据的数据量很大，侧重存储容量，采用分布式的方法将数据分布到多台普通PC 服务器的磁盘或者SSD。由于动态数据的存储介质成本较高，需要不断地将动态数据合并到静态数据中，从而分布到多台机器以实现分布式存储。

淘宝Oceanbase系统架构大致如图2所示。从图2可以看出，系统有以下几个主要模块。