<p>        通俗地讲，云计算就是把基础设施以服务的形式打包对外销售，它是一种商业模式，而其中的云存储是技术难点。可以从两个维度分析云存储系统的特 性：功能和可扩展性，这是一个“鱼和熊掌”不容易兼得的问题。不同的数据规模，不同的事务和一致性要求，不同的系统故障容忍度，都可能导致不同的存储系统 设计。国外的互联网巨头 Amazon、Google、Microsoft、Yahoo 都有各自的云存储系统，国内的淘宝也研发了自己的云存储系统 Oceanbase，并开始应用到联机事务处理 OLTP（On-line Transaction Processing）和联机分析处理 OLAP（On-line Analytical Processing）业务。</p>    <p>        <strong>云存储系统数据结构</strong></p>    <p>        为了保证存储系统的可靠性，需要将数据复制为多份。当数据规模增加时，我们可能会对传统的数据库分库分表以水平扩展，很多企业还开发了各自的数 据库中间层以屏蔽分库分表规则。然而，在传统的分库/分表架构下，每一份数据只能为一组 Master-Slave 节点服务，这就导致同一组机器节点存放了完全相同的数据，当其中某个节点发生故障时，只能通过所在机器组中的节点进行故障恢复，这样的系统称为同构系统。</p>    <p>        云存储系统一般指异构系统，每份数据可以被动态分配到集群中的任意一个节点，当某个节点发生故障时，可以将故障节点原有服务动态迁移到集群中的任何一台机器。只有实现系统异构才能发挥分布式集群的规模优势，减少集群运维成本，适应云存储系统数据量快速增长的需求。</p>    <p>        数据结构决定了云存储系统的功能，云存储系统的数据结构主要有两种：分布式 Hash 表和分布式B+ 树，如图 1 所示。分布式 Hash 表通过比如一致性 Hash 的方式将数据分布到集群中的不同节点，数据随机分布，不支持范围查询；而分布式B+ 树的数据连续存放，支持范围查询，但是需要支持分裂和合并，实现相对较为复杂。</p>    <p style="text-align:center;"><img alt="淘宝Oceanbase云存储系统实践" src="https://simg.open-open.com/show/74ffeddb88aacb852e9d8b6c780ee58f.jpg" width="500" height="172" /></p>    <p style="text-align:center;">图 1 云存储系统分类图</p>    <p>        常见的 Key-Value 系统的数据结构一般为分布式 Hash 表，只支持基本的 Put、Get 和 Delete 操作，比如 Amazon 的 Dynamo 和 S3 系统。而 Amazon Simpledb 按照 domain 进行数据划分，规定同一个 domain 数据量不能超过 10GB，从而可以存放到一个数据节点，用户只允许在同一个 domain 内部执行范围查询操作。Amazon 的云存储系统看起来不完美，但相当实用。</p>    <p>        Google 的系统设计之初就强调可扩展性。从最初的 GFS 到 BigTable，再到后来的 Megastore、Percolator，Google 先将系统的可扩展性发挥到极致，以后再逐步加入分布式事务、SQL 支持等功能。这样的设计得益于 Google 强大的工程师团队和公司一直以来崇尚通用系统的文化。Google 的云存储分为两层：分布式文件系统 GFS 和分布式数据库系统 BigTable，GFS 是一个带有追加功能的分布式文件系统，BigTable 将事务的提交日志追加到 GFS 中做持久化。数据在 BigTable 内连续存储，逻辑上构成一棵分布式B+ 树，Megastore、Percolator 又在 BigTable 的基础上加入分布式事务、索引、SQL 支持等功能。Google 的系统设计比较贵族化，可以远观，但模仿前请三思，比如将系统分成多层可能会增加用户操作的延时，对工程师的设计编码能力提出了更高的要求。</p>    <p>        Microsoft SQL Azure 是一个传统数据库厂商在云存储系统设计上给出的答案。当数据量增长时，必然要求牺牲部分功能来换取可扩展性，这对于 Microsoft 是不愿意看到的。Microsoft 直接在原有的关系型数据库 SQL Server 上进行分布式扩展，尽可能多地支持 SQL 功能，其功能非常丰富，但系统内部不支持 SQL Azure 实例的分裂和合并。因此，SQL Azure 内部也限制了单个 SQL Azure 实例允许的最大数据量，如 Business Edition 的最大数据量不超过 50GB。相比 Google 的系统，Microsoft 系统的扩展性较弱，但功能较强。</p>    <p>        云存储系统的难点在于状态数据的迁移和持久化，状态数据也就是系统的事务提交日志。Google BigTable 通过分布式文件系统 GFS 持久化提交日志，Microsoft SQL Azure 直接将提交日志通过网络复制到数据的多个副本，而 PNUTS 通过 Yahoo!内部的分布式消息中间件 Yahoo! Message Broker 持久化提交日志。Yahoo!没有对外提供云存储服务，但这样的设计可扩展性也是相当不错的。</p>    <p>        <strong>淘宝 Oceanbase 架构设计</strong></p>    <p>        淘宝 Oceanbase 是从 2010 年 5 月开始研发的，其定位是解决淘宝内部在线业务的云存储问题。我们在设计系统时，总是考虑现在及今后一段时间的需求。互联网业务大致可以分为 OLTP 和 OLAP 两类，对在线存储的需求简单归纳如下。</p>    <ul>     <li>OLTP：今后数据规模为千亿级，数据量百 TB，要求几十万 QPS 和几万 TPS。</li>     <li>OLAP：支持千万级记录的数据集上进行实时计算。</li>     <li>功能：支持范围查询，支持跨行跨表事务。</li>     <li>其他：5个 9 的可用性、自动故障处理、自动扩容等。</li>    </ul>    <p>        OLTP 和 OLAP 业务对性能的要求使我们必须采用分布式方案。另外，淘宝的业务发展迅猛，传统的分库/分表方法带来的扩容及运维成本太高，必须构建异构的云存储系统。通过 进一步分析在线业务，我们发现互联网在线存储业务有一个特点：数据量虽然很大，但新增数据量比较小，每天新增数据量基本在 1TB 之内。此外，淘宝的业务面临一些其他挑战，比如需要高效支持跨行跨表事务，需要支持两张几亿到几十亿条记录的大表进行联表操作。淘宝的海量数据以及复杂的 功能需求对存储系统的设计提出了新的挑战，关系型数据库在数据量上有点儿力不从心，而云存储系统又不能高效地支持复杂的功能要求。因此，需要融合关系型数 据库的功能和云存储系统的可扩展性这两个优点。</p>    <p>        如何借鉴已有技术满足淘宝未来一段时间内的云存储需求？如果直接模仿国外的互联网巨头，比如模仿 GFS + BigTable，淘宝的团队确实有一定的经验。然而这样的系统在两年之内很难稳定，并且不能满足跨行跨表事务等复杂的功能需求。既然在线业务新增数据量 比较小，那是否可以把最新修改的数据和以前的数据分离呢？</p>    <p>        答案是肯定的。淘宝 Oceanbase 将数据分成动态数据和静态数据两部分：动态数据的数据量较小，侧重 TPS 和 QPS，采用集中式的方法存放到单个节点的高品质存储介质，如内存和 SSD；静态数据的数据量很大，侧重存储容量，采用分布式的方法将数据分布到多台普通 PC 服务器的磁盘或者 SSD。由于动态数据的存储介质成本较高，需要不断地将动态数据合并到静态数据中，从而分布到多台机器以实现分布式存储。</p>    <p>        淘宝 Oceanbase 系统架构大致如图 2 所示。从图 2 可以看出，系统有以下几个主要模块。</p>    <p style="text-align:center;"><img alt="淘宝Oceanbase云存储系统实践" src="https://simg.open-open.com/show/159dc067702041037e5a778be559c256.jpg" width="500" height="231" /></p>    <p style="text-align:center;">图 2 Oceanbase 架构图</p>    <ul>     <li>RootServer：负责数据定位、机器管理、负载均衡、全局表 Schema 信息管理等。</li>     <li>UpdateServer：负责存储动态数据，存储介质为内存和 SSD。</li>     <li>ChunkServer：负责存储静态数据，数据存储 3 份，存储介质为磁盘或者 SSD。</li>     <li>Client：Oceanbase 提供的胖客户端。</li>    </ul>    <p>        写事务只操作 UpdateServer，读事务需要同时读取 ChunkServer 和 UpdateServer。某些操作，比如 OLAP 分析型操作可能需要涉及多个 ChunkServer 上的数据，这时将引入一个新的 MergeServer 模块将请求拆分到不同的 ChunkServer，合并每个 ChunkServer 的返回结果后执行排序、分组、分页等操作。静态数据在 ChunkServer 中保存三份，UpdateServer 通过 Linux HA 的方式进行双机热备以保证可靠性。RootServer 的访问压力很小，一般可以和 UpdateServer 部署在相同节点上，并采用相同的 Linux HA 方式。Oceanbase 的 UpdateServer 在同一个 IDC 机房采用实时同步的方式保证强一致性，这意味着写事务只有等到主机和备机都操作成功后才返回客户端。Oceanbase 支持跨 IDC 机房的异步准实时热备，多个机房之间的数据延迟为秒级。</p>    <p>        Oceanbase 的静态数据和 BigTable 类似，数据被分为几十到几百 MB 不等的子表，每个子表的磁盘存储格式为 SSTable，通过 bloom filter、block cache、key value cache 等方式进行优化。SSTable 支持根据 column group 按列存储，从而高效地支持 OLAP 分析。动态数据采用 copy-on-write 的方式实现了单机内存中的B+ 树，在单写多读的应用场景下不需要加锁。</p>    <p>        Oceanbase 静态数据构成一棵分布式B+ 树，动态数据为单机B+ 树。与线下 MapReduce 批处理应用不同，在线存储应用的更新量一般比较小，动态数据服务器不会成为性能瓶颈。这也就意味着，淘宝 Oceanbase 用一种更为简便的方式在底层实现了和其他互联网巨头类似的B+ 树数据结构，并且能够高效地支持跨行跨表事务。当然，当数据量增长到万亿级或者数据更新更快时，需要考虑将动态数据服务器的方案由集中式修改为分布式。我 们也考虑过多 UpdateServer 方案的设计，但由于短期内看不到明确的需求，暂时没有实现，目前我们认为可以通过硬件的方法，比如万兆网卡、更好的 CPU、更大的内存和 SSD 来解决。</p>    <p>        Oceanbase 还实现了一些分布式系统中常见的特性，比如自动负载均衡、在线修改 Schema、内置压缩解压缩等。另外，Oceanbase 系统里面没有随机写操作，因此天然适应 SSD 存储介质，很好地弥补了磁盘的 IOPS 不足这个问题。</p>    <p>        <strong>Oceanbase 应用效果和经验</strong></p>    <p>        Oceanbase 首先应用在淘宝收藏夹并取得了明显的效果。淘宝收藏夹最初采用 MySQL 分库/分表的方式实现，通过使用 Oceanbase，机器数由原来的 16 台主加上 16 台备共 32 台减少到 12 台静态数据服务器加上 2 台动态数据服务器，大大节省了机器资源。另外，目前应用的很多问题在 Oceanbase 中是通过更好的架构来解决，单机层面基本没做优化，相信后续还有很大的提升空间。在这过程中，我们也积累了一些经验教训。</p>    <ul>     <li>选择合适的技术。云存储听起来比较神秘，但实际上，对于大多数企业，需要设计好系统可扩展性发展的路线图，当数据规模比较小，可以采用传统的分库分表的方式构建同构系统；当数据规模逐步增加时，可以考虑构建符合企业需求的异构系统。</li>    </ul>    <ul>     <li>细节决定成败。云存储更多地是一个工程问题，代码质量、优化细节对系统的表现影响至关重要，淘宝 Oceanbase 的大多数代码都被两个以上的工程师 Review，我们也在减少 Cache 锁粒度、减少上下文切换、减少内存分配和内存拷贝等方面做了很多细粒度的工作。</li>    </ul>    <p>        <strong>展望</strong></p>    <p>        Oceanbase 目前的主要工作是应用推广，根据应用的需求来逐步完善 Oceanbase 系统，实现互联网数据库的构想。我们已经开始和淘宝的业务团队开展了千万级数据秒级实时分析的 OLAP 项目。另外，Oceanbase 还在考虑整合分布式 Blob 存储系统。随着应用推广的深入和 Oceanbase 系统的优化，希望能在合适的时间进行数据库新基准 TPC-E的测试。</p>    <p>        另外一个振奋人心的消息是：Oceanbase 将在合适的时间点开源。相信通过业界同仁一起努力，一定能够将云存储这个问题解决好！</p>    <p>        <strong>作者杨传辉，花名日照，淘宝存储系统专家，热衷于分布式存储和计算系统设计，对分布式系统理论和工程实践有比较深厚的理解。之前在百度作为核心成员主导或参与 MapReduce、BigTable 和分布式消息队列等底层基础设施架构工作。</strong><br /> <br /> 来自: <a id="link_source2" href="/misc/goto?guid=4959499216816996086" target="_blank">www.programmer.com.cn</a></p>