`
liufei.fir
  • 浏览: 687236 次
  • 性别: Icon_minigender_1
  • 来自: 上海
社区版块
存档分类
最新评论

淘宝Oceanbase云存储系统实践

阅读更多
淘宝Oceanbase云存储系统实践
通俗地讲,云计算就是把基础设施以服务的形式打包对外销售,它是一种商业模式,而其中的云存储是技术难点。可以从两个维度分析云存储系统的特性:功 能和可扩展性,这是一个“鱼和熊掌”不容易兼得的问题。不同的数据规模,不同的事务和一致性要求,不同的系统故障容忍度,都可能导致不同的存储系统设计。 国外的互联网巨头Amazon、Google、Microsoft、Yahoo都有各自的云存储系统,国内的淘宝也研发了自己的云存储系统 Oceanbase,并开始应用到联机事务处理OLTP(On-line Transaction Processing)和联机分析处理OLAP(On-line Analytical Processing)业务。
云存储系统数据结构
为了保证存储系统的可靠性,需要将数据复制为多份。当数据规模增加时,我们可能会对传统的数据库分库分表以水平扩展,很多企业还开发了各自的数据库 中间层以屏蔽分库分表规则。然而,在传统的分库/分表架构下,每一份数据只能为一组Master-Slave节点服务,这就导致同一组机器节点存放了完全 相同的数据,当其中某个节点发生故障时,只能通过所在机器组中的节点进行故障恢复,这样的系统称为同构系统。
云存储系统一般指异构系统,每份数据可以被动态分配到集群中的任意一个节点,当某个节点发生故障时,可以将故障节点原有服务动态迁移到集群中的任何一台机器。只有实现系统异构才能发挥分布式集群的规模优势,减少集群运维成本,适应云存储系统数据量快速增长的需求。
数据结构决定了云存储系统的功能,云存储系统的数据结构主要有两种:分布式Hash表和分布式B+树,如图1所示。分布式Hash表通过比如一致性 Hash的方式将数据分布到集群中的不同节点,数据随机分布,不支持范围查询;而分布式B+树的数据连续存放,支持范围查询,但是需要支持分裂和合并,实 现相对较为复杂。

常见的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:今后数据规模为千亿级,数据量百TB,要求几十万QPS和几万TPS。
• OLAP:支持千万级记录的数据集上进行实时计算。
• 功能:支持范围查询,支持跨行跨表事务。
• 其他:5个9的可用性、自动故障处理、自动扩容等。
OLTP和OLAP业务对性能的要求使我们必须采用分布式方案。另外,淘宝的业务发展迅猛,传统的分库/分表方法带来的扩容及运维成本太高,必须构 建异构的云存储系统。通过进一步分析在线业务,我们发现互联网在线存储业务有一个特点:数据量虽然很大,但新增数据量比较小,每天新增数据量基本在1TB 之内。此外,淘宝的业务面临一些其他挑战,比如需要高效支持跨行跨表事务,需要支持两张几亿到几十亿条记录的大表进行联表操作。淘宝的海量数据以及复杂的 功能需求对存储系统的设计提出了新的挑战,关系型数据库在数据量上有点儿力不从心,而云存储系统又不能高效地支持复杂的功能要求。因此,需要融合关系型数 据库的功能和云存储系统的可扩展性这两个优点。
如何借鉴已有技术满足淘宝未来一段时间内的云存储需求?如果直接模仿国外的互联网巨头,比如模仿GFS + BigTable,淘宝的团队确实有一定的经验。然而这样的系统在两年之内很难稳定,并且不能满足跨行跨表事务等复杂的功能需求。既然在线业务新增数据量 比较小,那是否可以把最新修改的数据和以前的数据分离呢?
答案是肯定的。淘宝Oceanbase将数据分成动态数据和静态数据两部分:动态数据的数据量较小,侧重TPS和QPS,采用集中式的方法存放到单 个节点的高品质存储介质,如内存和SSD;静态数据的数据量很大,侧重存储容量,采用分布式的方法将数据分布到多台普通PC服务器的磁盘或者SSD。由于 动态数据的存储介质成本较高,需要不断地将动态数据合并到静态数据中,从而分布到多台机器以实现分布式存储。
淘宝Oceanbase系统架构大致如图2所示。从图2可以看出,系统有以下几个主要模块。

• RootServer:负责数据定位、机器管理、负载均衡、全局表Schema信息管理等。
• UpdateServer:负责存储动态数据,存储介质为内存和SSD。
• ChunkServer:负责存储静态数据,数据存储3份,存储介质为磁盘或者SSD。
• Client:Oceanbase提供的胖客户端。
写事务只操作UpdateServer,读事务需要同时读取ChunkServer和UpdateServer。某些操作,比如OLAP分析型操作 可能需要涉及多个ChunkServer上的数据,这时将引入一个新的MergeServer模块将请求拆分到不同的ChunkServer,合并每个 ChunkServer的返回结果后执行排序、分组、分页等操作。静态数据在ChunkServer中保存三份,UpdateServer通过Linux HA的方式进行双机热备以保证可靠性。RootServer的访问压力很小,一般可以和UpdateServer部署在相同节点上,并采用相同的 Linux HA方式。Oceanbase的UpdateServer在同一个IDC机房采用实时同步的方式保证强一致性,这意味着写事务只有等到主机和备机都操作成 功后才返回客户端。Oceanbase支持跨IDC机房的异步准实时热备,多个机房之间的数据延迟为秒级。
Oceanbase的静态数据和BigTable类似,数据被分为几十到几百MB不等的子表,每个子表的磁盘存储格式为SSTable,通过 bloom filter、block cache、key value cache等方式进行优化。SSTable支持根据column group按列存储,从而高效地支持OLAP分析。动态数据采用copy-on-write的方式实现了单机内存中的B+树,在单写多读的应用场景下不需 要加锁。
Oceanbase静态数据构成一棵分布式B+树,动态数据为单机B+树。与线下MapReduce批处理应用不同,在线存储应用的更新量一般比较 小,动态数据服务器不会成为性能瓶颈。这也就意味着,淘宝Oceanbase用一种更为简便的方式在底层实现了和其他互联网巨头类似的B+树数据结构,并 且能够高效地支持跨行跨表事务。当然,当数据量增长到万亿级或者数据更新更快时,需要考虑将动态数据服务器的方案由集中式修改为分布式。我们也考虑过多 UpdateServer方案的设计,但由于短期内看不到明确的需求,暂时没有实现,目前我们认为可以通过硬件的方法,比如万兆网卡、更好的CPU、更大 的内存和SSD来解决。
Oceanbase还实现了一些分布式系统中常见的特性,比如自动负载均衡、在线修改Schema、内置压缩解压缩等。另外,Oceanbase系统里面没有随机写操作,因此天然适应SSD存储介质,很好地弥补了磁盘的IOPS不足这个问题。
Oceanbase应用效果和经验
Oceanbase首先应用在淘宝收藏夹并取得了明显的效果。淘宝收藏夹最初采用MySQL分库/分表的方式实现,通过使用Oceanbase,机 器数由原来的16台主加上16台备共32台减少到12台静态数据服务器加上2台动态数据服务器,大大节省了机器资源。另外,目前应用的很多问题在 Oceanbase中是通过更好的架构来解决,单机层面基本没做优化,相信后续还有很大的提升空间。在这过程中,我们也积累了一些经验教训。
• 选择合适的技术。云存储听起来比较神秘,但实际上,对于大多数企业,需要设计好系统可扩展性发展的路线图,当数据规模比较小,可以采用传统的分库分表的方式构建同构系统;当数据规模逐步增加时,可以考虑构建符合企业需求的异构系统。
• 细节决定成败。云存储更多地是一个工程问题,代码质量、优化细节对系统的表现影响至关重要,淘宝Oceanbase的大多数代码都被两个以上的工程师Review,我们也在减少Cache锁粒度、减少上下文切换、减少内存分配和内存拷贝等方面做了很多细粒度的工作。
展望
Oceanbase目前的主要工作是应用推广,根据应用的需求来逐步完善Oceanbase系统,实现互联网数据库的构想。我们已经开始和淘宝的业 务团队开展了千万级数据秒级实时分析的OLAP项目。另外,Oceanbase还在考虑整合分布式Blob存储系统。随着应用推广的深入和 Oceanbase系统的优化,希望能在合适的时间进行数据库新基准TPC-E的测试。
分享到:
评论

相关推荐

    淘宝Oceanbase云存储系统实践.doc

    淘宝Oceanbase是一个自...总的来说,淘宝Oceanbase云存储系统实践是针对大规模电商场景的定制化解决方案,它在满足高并发交易的同时,兼顾了大数据分析的需求,体现了中国互联网公司在云存储领域的技术创新和实践积累。

    淘宝OceanBase云存储实践

    标题:“淘宝OceanBase云存储实践” 描述:“在线海量存储的挑战、可扩展性、存储需求分解”,这简短的描述揭示了淘宝在处理大规模在线数据存储时所面临的三大核心议题。面对PB级别的海量数据和每天TB级别的数据...

    淘宝OceanBase云存储实践.zip

    淘宝OceanBase云存储实践.zip

    淘宝OceanBase云存储实践.pdf

    淘宝作为全球知名的电子商务平台...综上所述,OceanBase的云存储实践展现了淘宝在解决海量数据存储和处理中的创新思维和技术实力,其系统架构、功能特点、业务案例和未来发展方向都为业界提供了宝贵的参考和实践经验。

    分布式 存储系统

    分布式存储系统已成为构建大数据平台、云存储和大规模互联网应用的关键技术之一。 分布式存储系统的关键概念包括分布式存储概念和分布式存储分类。分布式存储概念是指如何在物理上分布数据和存储资源,以及如何通过...

    第三届系统架构师大会全部的PPT

    2011.9.9~9.10,第三届系统架构师大会(2011)在北京召开。大会对架构设计、分布式集群、敏捷运维、系统安全、网络架构优化、数据分析、云平台等多个...淘宝OceanBase云存储实践.pdf 应用交付网络优化技术.pdf ……

    2011系统架构师大会演讲PPT集

    其次,杨传辉的《淘宝OceanBase云存储实践》聚焦于淘宝自研的分布式数据库OceanBase。OceanBase是一个高性能、高可用、可扩展的分布式事务型数据库,尤其适用于大规模电商交易场景。在该演讲中,杨传辉可能会详细...

    淘宝软件基础设施构建实践 pdf

    然后,描述淘宝在软件基础设施上的规划,并一一阐述当前主要项目的要点与进展状况,这包括TFS、TAIR、千亿级别的分布式表格系统OceanBase、MySQL优化、面向Java环境的专用计算平台、服务器平台、Linux内核定制与优化...

    淘宝技术架构-基于Java构建的淘宝

    5. **数据库技术**:在数据存储方面,淘宝可能使用了分库分表、读写分离、分布式数据库(如OceanBase)等策略,以应对大数据量的挑战。MySQL、Redis等数据库可能在其中扮演重要角色。 6. **缓存策略**:为提高数据...

    淘宝数据库架构演进历程.pdf

    3. 分布式数据库阶段:进一步应对海量数据,淘宝引入了分布式数据库系统,如TDDL(Taobao Distributed Data Layer)和OceanBase。TDDL作为一个数据库中间件,负责数据分片、负载均衡和故障恢复,实现了水平扩展。而...

    淘宝技术嘉年华.part4.rar

    7. **曲山-OceanBase内部探秘.pptx**:曲山的报告可能深入解析了OceanBase数据库系统,这是一个分布式数据库系统,可能详细解释了其设计理念、分布式一致性保证、容灾机制以及在淘宝的运营实践中如何保证高可用性和...

    淘宝数据挖掘

    文章提到了数据平台架构中的调度监控、数据门户、多维自助查询平台,以及分布式集群DXP、数据交换平台OceanBase等技术解决方案,这些都是构建大规模数据挖掘平台的关键组件。 在数据应用格局方面,淘宝通过数据魔方...

    ppt-章文嵩

    - **OceanBase**:淘宝自主研发的分布式数据库系统,支持大规模数据处理,能够处理千亿条记录级别的数据库,并支持事务处理。 #### 三、具体实例分析 - **图片存储系统的演变**:早期淘宝采用商用存储解决方案,但...

Global site tag (gtag.js) - Google Analytics