淘宝Oceanbase云存储系统实践通俗地讲，云计算就是把基础设施以服务的形式打包对外销售，它是一种商业模式，而其中的云存储是技术难点。 本文关键字： 云计算 通俗地讲，云计算就是把基础设施以服务的形式打包对外销售，它是一种商业模式，而其中的云存储是技术难点。可以从两个维度分析云存储系统的特性：功能和可扩展性，这是一个“鱼和熊掌”不容易兼得的问题。不同的数据规模，不同的事务和一致性要求，不同的系统故障容忍度，都可能导致不同的存储系统设计。国外的互联网巨头Amazon、Google、Microsoft、Yahoo都有各自的云存储系统，国内的淘宝也研发了自己的云存储系统Oceanbase，并开始应用到联机事务处理OLTP（On-line Transaction Processing）和联机分析处理OLAP（On-line Analytical Processing）业务。 云存储系统数据结构 为了保证存储系统的可靠性，需要将数据复制为多份。当数据规模增加时，我们可能会对传统的数据库分库分表以水平扩展，很多企业还开发了各自的数据库中间层以屏蔽分库分表规则。然而，在传统的分库/分表架构下，每一份数据只能为一组Master-Slave节点服务，这就导致同一组机器节点存放了完全相同的数据，当其中某个节点发生故障时，只能通过所在机器组中的节点进行故障恢复，这样的系统称为同构系统。 云存储系统一般指异构系统，每份数据可以被动态分配到集群中的任意一个节点，当某个节点发生故障时，可以将故障节点原有服务动态迁移到集群中的任何一台机器。只有实现系统异构才能发挥分布式集群的规模优势，减少集群运维成本，适应云存储系统数据量快速增长的需求。 数据结构决定了云存储系统的功能，云存储系统的数据结构主要有两种：分布式Hash表和分布式B+树，如图1所示。分布式Hash表通过比如一致性Hash的方式将数据分布到集群中的不同节点，数据随机分布，不支持范围查询；而分布式B+树的数据连续存放，支持范围查询，但是需要支持分裂和合并，实现相对较为复杂。  图1 云存储系统分类图 常见的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可以看出，系统有以下几个主要模块。 责编：赵龙  微信扫一扫实时了解行业动态 著作权声明：畅享网文章著作权分属畅享网、网友和合作伙伴，部分非原创文章作者信息可能有所缺失，如需补充或修改请与我们联系，工作人员会在1个工作日内配合处理。 |
最新专题 推荐圈子 |
|
|
DB2数据的导入(Import)_导出(Expo..
Cognos 中国社区——Cognos 10.2...