OceanBase设计规范与数据架构指南v213.docx

OceanBase设计规范与数据架构指南
版本
文档修订历史
版本号
作者
备注
修订日期

泓影
初稿
2017-06-29

泓影
修正细节
2017-07-13
简介
,关系数据库便以其易于使用的接口、完善的功能和生态而成为了IT领域必需的基础设施,广泛应用在各行各业,包括金融、电信、房地产、农林牧渔、制造业等等。关系数据库经过了40多年的发展,涌现了Oracle、SQL Server、DB2等优秀的商业数据库产品,开源领域也不乏MySQL、PostgreSQL这样的精品。
但是,随着互联网行业和大数据的兴起,数据量和并发访问量呈现指数级的增长,囿于关系数据库的架构,原先运行良好的关系数据库遭遇了严峻的挑战:极度高昂的总体拥有成本、捉襟见肘的扩展能力、荏弱无力的大数据处理性能等等。
于是NoSQL应运而生, Hbase、Cassandra等系统如雨后春笋般冒出,这些系统多采取分布式架构,易于扩展及容灾,结合大数据处理系统如Hadoop等,可以很容易处理量级非常大的数据, 这一时让NoSQL风光无两,大有取代SQL之势,让人看不清NoSQL系统的边界。很多公司尝试将核心系统迁移到新兴的NoSQL系统上, 比如Facebook就尝试将部份核心系统迁移到Cassandra。在迁移过程中,人们发现NoSQL所获得针对SQL的优势其实是以牺牲一些非常重要的功能来获取的, 如NoSQL一般不支持事务或只支持非常有限的事务, 这极大的增加了业务系统的复杂度, 在传统的OLTP领域采取NoSQL系统基本上是不可以接受的。
阿里巴巴/蚂蚁金服的关系数据库使用场景极其严苛,有着全球最大的并发量需求, 在可靠性方面需要做到单机、机架、机房甚至是地区级别的容灾恢复能力。早期使用共享存储、小型机等高端硬件也只能部分满足我们在性能和可靠性上的需求, 而且随着业务的发展,这种IOE架构很快就成为瓶颈。
我们能不能结合新兴分布式系统和传统关系型数据库的优点, 既拥有传统关系型数据库在功能上的优势,同时具备分布式系统的可扩展性、高可靠性等特征? OceanBase即是以此为出发点,开始打造一个分布式关系型数据库。OceanBase 从2010年6月份立项开始到今天已经发展了六年多的时间,构建在普通服务器组成的分布式集群之上,具备可扩展、高可用、高性能、低成本以及多租户等核心技术优势。目前已经成功应用于蚂蚁金服的会员、交易、支付、账务、计费等核心系统和网商银行等业务系统。OceanBase 经历了多年(2011-2016)双十一的严格考验,特别是在刚刚过去的2016年双十一, 用户每一笔支付订单背后的数据和事务处理都由OceanBase完成,创造了每秒12万笔支付峰值的世界记录。
OceanBase架构及优势
互联网对传统关系型数据库的挑战主要有两个方面:
一是可扩展性。传统关系型数据库本质上是单机系统,其扩展方法一般为向上扩展,即换性能更好的机器, 阿里巴巴/蚂蚁金服随着业务的发展,也一路扩容到小型机,但这种方式对于互联网行业来说,其扩容周期短,成本很高。另外一种方法为水平拆分,即分库分表,这也是目前广泛应用的扩展方式,这极大的增加了业务复杂度, 相当于将数据库的一部份工作转嫁到业务方,从各大公司都有自己的中间件来处理这一层业务即可见一斑。
二是可靠性。传统关系型数据库一般采取主备形式来解决高可用的问题。主备之间数据同步主要有两种方式, 一是最大保护模式,需要主备均写入成功后才算成功,这样可以保证数据一致性,但一旦备机宕机或网络抖动即可造成不可用。另外是最大性能/最大可用模式,这种模式下只要主写入成功即可算成功, 此时如果主机宕机,但有数据尚未同步到同机,即可造成数据不一致或丢失。解决这个问题的传统方案是采取高端商用硬件如共享存储,通过高可靠的硬件来解决软件上的不可靠,但这样也会存在一些问题, 比如共享存储无法解决或很难解决机房容灾问题。
OceanBase 的目标是要解决这两方面的问题,设计原则:
使用普通PC服务器,不使用共享存储、小型机等高端硬件。
磁盘、服务器、网络、机房甚至是某个地区的IT基础设施并非持续可用。
关系型数据库,支持传统关系型数据库的功能,比如SQL、跨行跨表事务。
可水平扩展,扩展时对应用透明。
高可靠、数据强一致,单机、机房甚至地区故障时可自动恢复。
高性能。
根据目标,OceanBase 需要解决三个方面的问题:
一是传统关系型数据库的功能。 传统关系数据库经过多年的发展, 功能极其丰富,SQL的表达能力、事务支持等对应用非常友好,并且形成了自己的生态。