OceanBase设计规范与数据架构指南版本0.1文档修订历史版本号作者备注修订日期V0.1泓影初稿2017-06-29V0.2泓影修正细节2017-07-131OceanBase1.0简介自从E.F.Codd于1970年首次提出关系数据库模型后，关系数据库便以其易于使用的接口、完善的功能和生态而成为了IT领域必需的基础设施，广泛应用在各行各业，包括金融、电信、房地产、农林牧渔、制造业等等。关系数据库经过了40多年的发展，涌现了Oracle、SQLServer、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万笔支付峰值的世界记录。2OceanBase架构及优势互联网对传统关系型数据库的挑战主要有两个方面：一是可扩展性。传统关系型数据库本质上是单机系统，其扩展方法一般为向上扩展，即换性能更好的机器，阿里巴巴/蚂蚁金服随着业务的发展，也一路扩容到小型机，但这种方式对于互联网行业来说，其扩容周期短，成本很高。另外一种方法为水平拆分，即分库分表，这也是目前广泛应用的扩展方式，这极大的增加了业务复杂度，相当于将数据库的一部份工作转嫁到业务方，从各大公司都有自己的中间件来处理这一层业务即可见一斑。二是可靠性。传统关系型数据库一般采取主备形式来解决高可用的问题。主备之间数据同步主要有两种方式，一是最大保护模式，需要主备均写入成功后才算成功，这样可以保证数据一致性，但一旦备机宕机或网络抖动即可造成不可用。另外是最大性能/最大可用模式，这种模式下只要主写入成功即可算成功，此时如果主机宕机，但有数据尚未同步到同机，即可造成数据不一致或丢失。解决这个问题的传统方案是采取高端商用硬件如共享存储，通过高可靠的硬件来解决软件上的不可靠，但这样也会存在一些问题，比如共享存储无法解决或很难解决机房容灾问题。OceanBase的目标是要解决这两方面的问题，设计原则：使用普通PC服务器，不使用共享存储、小型机等高端硬件。磁盘、服务器、网络、机房甚至是某个地区的IT基础设施并非持续可用。关系型数据库，支持传统关系型数据库的功能，比如SQL、跨行跨表事务。可水平扩展，扩展时对应用透明。高可靠、数据强一致，单机、...
VIP
