2016年11月18日-20日，由CSDN重磅打造的年终技术盛会 —— “2016中国软件开发者大会”（Software Developer Conference China 2016，简称SDCC 2016）在北京京都信苑饭店隆重举行。本届大会云集了100多位国内外顶尖专家和技术大牛，共设新趋势和新实践2大主题会场，12个技术专题，以及2个特色技术活动。面向国内外的中高端技术人员，聚焦最前沿技术及一线的实践经验，助力企业的技术升级和改造、全面提升技术人员的综合实力。
在11月19日上午的Keynote上，蚂蚁金服高级研究员阳振坤带来“关系数据库的困境与出路”主题演讲，着重分享了这些年来基于关系型数据库遭遇困境与挑战的思考，以及团队OceanBase的相关技术实践。毋庸置疑，数据库是最关键的基础设施。关系数据库系统发展至今依旧繁荣，但仔细想来，现存的多为早前建立下来的基础，如今的关系数据库存在诸多问题和挑战。面对这一发展现状，是偏安一隅苟延残喘，还是做出一些大胆的尝试？
实际上，关系数据库仍然有非常大的发展空间。互联网时代迎来信息的大膨胀，传统关系型数据库的缺陷逐渐浮现，甚至一度有关系数据库日落西山的言论盛行。那是什么让其遭遇今日之困呢？其一，为门槛高，这里就类似先有鸡还是现有蛋的问题，因为出一点问题整个系统即无法工作，所以性能对数据库而言永远是巨大的挑战，然而即使能证明性能，做一个新的系统也往往没去用，因为无法证明其稳定可靠。其二，是成本，商业数据库需要负担极高的服务费这一点也是众所周知的。其三是扩展性差，如双十一和 一些爆火的游戏或App都有可能面对访问骤增的问题，难于扩容，小引擎支撑不了大数据，还有主库故障问题等。对此的对策有降低成本、水平扩展以及自动无损恢复等。而OceanBase即是基于以上思考的反传统实践。（PPT下载）
各位来宾，大家上午好！非常感谢CSND给我这个机会给大家做一个分享。
我们蚂蚁金服团队自己一行一行代码写了一个数据库，其实很多人对此有一些疑惑：已经有这么多的数据库了，为什么要花这么多的投入再自己写一个？有的人会说某个人想做一个数据库，所以就做了，事实上大家理性一想，这是不可能的，在公司里面做事情，一定要有价值，对公司有价值，对社会有价值才展开。尤其像数据库这样高成本、长时耗的。我们做OceanBase已经有六年半了：2014年替换了支付宝商业数据库里的交易系统；2015年替换了支付链路、支付系统提；到今年终于将最核心的帐户系统替掉了，这是金融系统中最难的一块。
今天跟大家分享我们这几年对这个问题的一些思考，因为在阿里巴巴、在蚂蚁金服开启这么一个大项目一定有一些原因，所以今天重点和大家分享一些背后的原因，内容大概覆盖以下几点：1）数据库的背景；2）关系数据库面临的困境和挑战；3）针对挑战的解决方案探究；4）分布式关系数据库Oceanbase的实践。
我们今天没有什么东西可以离开数据库，酒店、政府通讯、金融等，无一例外。所以从这个角度来看数据库真的非常繁荣，在社会信息基础里甚至可以称之为最关键的基础设施。所以从这个角度来看又觉得关系型数据整体呈现出一片欣欣向荣的景象。但是仔细想就不难发现，不管是银行电力，还是商业相关，这些数据库系统都是很多年前逐步建立起来的，并不属于今天的发展。没有人会平白无故去创造一个系统，所以之所以出了这么多新型数据库，是因为关系数据库本身是存在一些问题或者是一些缺陷。因此关系数据库较之现状，如今还是有很多发展机会和提升空间的。至于是想蜗居于既有市场安于现状，还是大胆挑战就有思路，这就是需要我们来思考的问题了。
当今关系数据库的困境
门槛高
纵观关系数据库难点，很顽固的一点就是它的高门槛。如前所述，关系数据库很重要，在很多系统里都是极其基础性的东西。因此只要它出一点问题，整个的业务系统可能就没办法工作了。所以，它地位高了就决定了它复杂性，以及性能永远都是一个巨大的挑战。诸多问题叠加拉高了关系数据库的门槛：做新的关系数据客可以，但是没有人会去用，也许它的性能很高，但是却几乎无法证明其是稳定可靠的。所以形成这么一个经典的鸡与蛋的问题：没有人用就不能证明可靠性，没人证明稳定可靠就没人愿意使用。这样就造成了这么几十年来，关系数据库真正的玩家就那么几家，大家进来非常难，而且每一家进来都花了几十年的时间才能让大家觉得这个数据库的内核确实比较靠谱。所以对于关系数据库来讲这个门槛，多数的情况下不是门，是槛，就是让你跨不过去，让多数人跨不过去。
成本高
另外就是成本，我原来在这上面花了很多的美元符号，服务器要钱，存储要钱，商业数据库的软件要钱，（开源是不要钱的），还有巨额的服务费等。提到这一点，我就想起大概在2007年，Google的论文里有这么一句话——“没有这么大的商业数据库，即使有也用不起”，我当时很奇怪，Google那么有钱，一个数据库怎么用不起呢？知道我开始接触这个领域时，我才知道，确实是用比起。
扩展性差
还有数据库的扩展性，我们不是说关系数据库没有扩展性，它有扩展性，但在互联网时代之前，它的扩展性是和商业环境配套的，比如商场。商场在大多情况下，呈现的是一种稳步发展，数据发生和访问量比较稳定，周期通常在半年甚至一年，因此有足够的扩容时间。开始如今这些东西都发生了很大的变化，几天增倍几倍的情况时有发生。比如一个网站，不管是刚才说的京东，还是阿里巴巴，其实没有办法预测或控制今天谁访问，谁买东西，像是双十一，前几分钟很少的访问量，突然某一点就有很高的访问量。还有爆火的游戏或APP，访问骤增的需求很难用传统数据库的方式实现。
小引擎 大数据
还有就是我们刚才其实提到的，数据库除了贵以外还有一个问题就是，现在的数据量变得越来越大，原来数据库只有几条、几万条数据，而现在几亿条进度都不算什么，数据库还是以前的处理能力，故而没有能力来处理这么大的数据量，所以为了处理大家就想很多办法把数据从数据库移出来做分析和处理。
主库故障危机
另外有一点不是做数据库的人很难真正体会到，以大型银行为例，它们确实有很高端的设备，大型机、高端存储，性能极高，但即使如此，遭遇主库计划外的停机也不能马上开业。有人会说主主库坏了，备库升级工作不就可以了？实际上，迄今为止传统的关系数据库都做不到这一点，一主一备无仲裁，备库直接升级难。那么我是否能将主备库连起来？主库一失误传到备库这么简单的情做不到吗？试想万一备库或主库出了问题，传输过程中写就全部阻塞住了，从而导致网站无法工作，这更加严重。这个过程中一旦发生故障，备库的数据就会不完整。大家经常会看到某个网站机房出了问题，但少有银行机房出问题的情况，这可能是由于银行机房数量少，所以花费很高的成本来保证机房的高可靠、高稳定性，因为即使主库所在的机房机器不出问题，存储或机房出问题，结果一样糟糕，所以必须把机房做稳定做可靠，包括对外的电力、通讯，因此要花极高的成本。
关系数据库出路探究
降低成本
关系数据库求发展的首要任务就大幅降低成本。降低成本有以下途径：
- 采用性价比较高的PC服务器；
- 多个用户共享一个数据库的软件，共享一个数据库的服务器，分担成本；
- 共享云服务降低成本。
水平扩展双十一海量不能一直这么多设备 很有可能双十一之前云上租来的——很大的节省
第二个突破口是扩展性，针对这一点数据库原来传统用的方式是拓宽硬件能力，但这种方式注定不可能有很高的时效，另外一种方式是水平扩展。例如双十一的海量数据下，数据库的访问量可能是平时的5倍10倍甚至更高，但不可能一直设置这么多设备，因为如此一来浪费和成本都太多了，对此今天的做法可能是在面临临时性需求时，在云上租用设备多，可以大大节省成本。
自动无损恢复
还有长久以来持续折磨许多互联网从业者的一点是：互联网公司很多人用了NoSQL，许多公司今天可能是成千上万台的PC服务器，可能不是每天但至少每个星期都有数据库机器出故障，出故障要就要去补数据，而补数据目前为止还不能做成全自动化的，因为跟业务相关，所以成了好多人的恶梦。用廉价的硬件是你降低的成本，但是随之而来的结果是要不断去补数据，服务不断受影响，这其实是在另外一个方面付出了成本。
OceanBase实践
2010年，针对对关系数据出现了很多极为负面的评价，有人说关系数据库已是日薄西山，其实主要的原因就是过去人们一直觉得关系数据库能做所有自己想做的事情，但到了互联网时代，信息大膨胀袭来，才发现关系数据库的诸多弊端，所以我们当时看中了这个机会，觉得我们可能能做一点事情。在很多方面我们做了一些在当时看来或许是反传统数据库的尝试。从2010年6月的项目立项，到2011年2月V0.1淘宝收藏夹上线，2012年11月V0.4支持SQL，2014年5月支付宝交易上线，再到今年（2016年）5月支付宝账户上线，从零开始发展至今，兼具水平扩展、MySQL兼容、自动无损恢复、性能数据等特点。
其间我们做的第一件事情就是这种三个机群的方案，数据放在三个机房里，最早做这些事情有很多争议，大家会发现很多地方甚至都找不到三个机房，这怎么办？当时毫无疑地选了互联网公司主流的PC服务器，今天的PC服务器跟小型机比性能上没有什么差距，但是性价比高得，唯一的代价是其稳定性可用性没那么高。再者就是如果想要随时随地地扩容，就必须淘汰共享存储。
数据库本质上是一种存储，既然要存储，对于设备来讲一个很大的挑战就是IO。在机械时代数据库最大的问题就是IO，一秒钟只能提供几百次的IO。我们2010年做了SSD，这是个很好的机会，那时没有今天这么普及，但我们觉得数据库毕竟相对贵一点，我们无法预见今天所有的笔记本、手机都会用，但是我们相信固态盘实际上能够解决一半的IO问题，我们也不是做固态盘的厂商，后来这个方案被批评了很多年，就是说我们把数据库机械放在固态盘，可能一天是不会修改的，但是把这一天之内的数据增删改放在内存，就会有人问，我一天把你内存写爆了怎么办，这个问题其实是存在的，但是今天看来，其实已经不算是问题了。这次过去的双十一，支付宝一天总共是10.5亿支付，如果每一笔要1K，实际上大家知道数据库大量的修改操作，每次操作没有这么大的量，一天就是1T，如果将1T数据分十台二十台机器，每一台机器就没有多少。所以今天看起来这个问题并不并不需要太大成本。因此在今天的OceanBase跟原来的跟传统数据库比还有一个优势就是固态盘本身的优势。传统数据库性能很高，特别是在业务高峰期时，此时的读和写往往会非常重，此时固态盘的IO压力也会变得非常大，但是OceanBase平时只有读，它有顺序地写日志，大家知道写事务的log对于事物的压力不是那么大。而且可以配置到一个独立的容量不需要那么大的盘上。
像刚才提到的，我们是2010年5月开始做调研，6月份立项，走过了几年被很多的外界的同事们不太看好的不像一个数据库的状态，直到今天把支付宝的交易、用户、核心帐务里的商业数据库替换下来的时候，大家终于觉得OceanBase是一个数据库了。
