OceanBase数据库创始人阳振坤分享征战6088万tpmC的艰辛之路

前言:中国人民大学常被誉为是“中国人文社会科学的最高学府”,其实人民大学也是“中国数据库的发源地”。由中国人民大学教授萨师煊与王珊合作编写的《数据库系统概论》是国内第一部系统阐明数据库原理、技术和理论的教材,也被公认为是国内数据库领域的经典权威教材。

近期,蚂蚁金服高级研究员、OceanBase团队创始人阳振坤受邀在人民大学分享了分布式关系数据库OceanBase如何登顶国际TPC-C benchmark排行榜,并对这一突破背后的技术创新进行了深入的解析。

数据库:技术和市场的“死亡之谷”

数据库的概念最早源自上个世纪60年代。到了70年代,关系模型已经诞生。80年代关系数据库逐渐成为整个社会的信息基础设施。2000年伊始,随着互联网的发展,业务系统对数据库的需求发生了很大的变化。在过去,传统的数据库并发访问量从几百到几千。进入互联网时代后,并发访问量骤增,达到百万至千万的级别。越来越多的公司发现根据现有的并发量和数据量,不仅他们买不起传统商业数据库,而且传统商业数据库也无法容纳和处理他们的数据量和访问量。

从2006年开始,大量新的非关系型数据库如雨后春笋般涌出,在整个数据库行业掀起了一场空前盛大的NoSQL革命。最早在 2006年,Google Bigtable发表,随后HBase,HyperTable,MongoDB,Redis相继问世。火热发展的云计算带来了对更大规模数据库的需求。过去的业务大多类似商场开业,从选址、装修到IT设备的采购,至少需要一个季度甚至半年时间。如今业务部门从采购到上线,时间缩短至数小时,甚至很多业务要求像租用云计算服务一样,能够即拿即用。

云计算改变了已有模式,这时候传统关系数据库的缺点也进一步凸显:不能水平扩展、容量小、处理能力不够、成本又非常高。甚至很多人断言,关系数据库正在走向末路,然而时至今日,关系数据库依然是整个社会的信息基础设施,承载着整个社会重要程度最高、访问量最大的数据。 

关系数据库从诞生起已经有几十年的时间了,但基本上它的市场格局没有太大的变化。最早的几家霸主直至今天依然占据着统治地位。关系数据库虽然很重要,但是它在整个IT系统的成本里却并占据非常大的比例。关系数据库处在整个产品或者产业链最底层的位置,替换风险很大,迁移的成本很高,因此非常难以被替换。这就导致了数据库变成了一个门槛极高、强者恒强的领域,后来者很难居上。

谈到关系数据库,准确地说用于在线交易处理的关系数据库,在我看来这是所有软件中最难的。首先一个重要的难点在于它需要支持数据库事务即ACID,其次在于SQL优化器,这两点就占据了数据库中很大部分的工作量。同时,在线交易处理关系数据库的技术门槛也非常高,我们常说有三个“要”:1)既要:数据一条不能错;2)又要:服务片刻不能停;3)要:交易处理高并发。基于如此高的技术门槛,这也意味着在线交易处理数据库注定是一个非常艰难的领域。 

前有先行者挡道、后有NoSQL追赶,在大部分人看来,很多人都觉得这不是做自研关系数据库的好时机。但仔细分析后,会发现这是个千载难逢的好机会

天时地利人和铸就OceanBase开创性的革新

2010年加入阿里巴巴后,当时很多人都看到单机数据库已经走到了尽头,我想如果能将分布式的核心理论揉到数据库里,解决单机数据库的水平扩展问题,对当时整个互联网的基础设施乃至整个社会的信息基础设施都会是一个非常好的机会。我当时找了几个同学想要一起做这件事,跟我一样,这几个同学都有分布式背景。尽管研制关系数据库充满了挑战,但我们得到了千载难逢的天时地利与人和的机遇。

天时”是互联网的爆发式增长对数据库的高并发、大数据量提出了很高的需求,而传统关系数据库难以满足这个需求;“地利”是阿里巴巴内部从淘宝到支付宝拥有大量使用数据库的场景,OceanBase可以从不是特别关键的应用场景开始尝试,一步步地将数据库做到关键系统;“人和”是当时单机数据库已经走到了尽头,下一步一定是走向分布式,而当时团队成员大多是分布式技术背景,做的就是自己最擅长的工作。

 2010年6月25号OceanBase项目正式立项。项目创立之初,我们给自己定了两个小目标:第一是硬件性价比做到Oracle的十倍,第二是做到可水平扩展,因为这是OceanBase的根基。

传统数据库常常被人诟病,因为它有两个本质的缺陷:首先是传统的OLTP数据库不能水平扩展。由于不能水平扩展,机器只能越做越大,价格甚至几何级数的增长。

第二就是主库备库的数据不一致。主备镜像无法做到数据可用性跟一致性两全:主库备库的完全一致意味着每一笔事务都得从主库同步到备库,备库确认后才能应答。假如这中间网络出现问题,或者备库出现问题,所有的同步都会被堵塞,也就是所有的写操作都无法进行。因此主库一旦出问题,数据是有损的,所以企业只能买最可靠的设备,从四个九到五个九,就是为了让这些机器不出一点问题,可想而知这样的设备肯定便宜不了。不论是软件还是硬件都便宜不了,服务自然也便宜不了,这就导致数据库成本非常高。


如果分布式数据库是一条康庄大道,这条路可能早就被无数人踏过。分布式OLTP数据库其实是一条非常难走的路,因为分布式数据库的一个核心问题就是单机故障会引起整库故障。随着机器规模的增大,机群故障率会指数级的提高。由于主备镜像无法做到数据可用性跟一致性两全,因此无法采用主备镜像或类似手段解决分布式数据库的节点故障的问题。 对于银行和企业的业务来说,可用性跟一致性是一个生死两难的问题,要保证同步,就面临着业务不可用的风险。所以银行往往会购买可靠性更高的存储和服务器等硬件。可靠性高的硬件自然价钱也非常高昂。因为分布式里每一个节点在任何时刻都可能会故障,不管这个节点本身的可靠性有多高,它都有故障的可能性。一直以来,我们工作的重点之一,就是围绕如何提升分布式整体的可用性。如果解决了这个问题,不再需要高可靠的硬件,也不用在意主备库是否一致和水平扩展的问题,很多问题都能引刃而解。

所以OceanBase采用了Paxos分布式一致性协议,它也是OceanBase整个分布式数据库里最核心的基础之一。它本质上解决的一个问题就是用不可靠的成员来提供可靠的服务。也就是哪怕单个节点不可靠,只要大部分节点正常工作时这个系统就能正常工作。传统数据库中五个九的设备非常昂贵,OceanBase则基于普通的PC服务器,且不要求设备有很高的可靠性,只要两个九到三个九,整个系统就能够工作得很好,这一创新的技术突破大大提升了性价比

那么,OceanBase是如何用Paxos协议来做成这件事?我们前面简单分析过,不可能既保证高可用,又保证主备库完全一致,因为这两个需求是矛盾的。然而Paxos协议却提供了一个迂回的解决方案,即多数派。举例说明,主库中的每一条日志会同步给两个备库,只要有一个备库收到,就能达成一个多数派协议。简而言之就是三者中有两个同意,少数服从多数,就认为这件事情成功了。那么这种情况下,任何一个节点坏掉,刚才的这笔事务也至少会在剩下两个节点中的其中一个节点有。所以哪怕是主库故障了,那么两个备库会互相握手,相互把缺失的数据快速补齐。恢复时间OceanBase通常不会超过30秒。 

有同学肯定会问,你们用的都是廉价的服务器,万一三台中坏了两台怎么办?虽然在实际生产中三台坏两台的概率特别小,但是其实也有过类似的事故。所以接下来在生产系统中,大部分都换成了五节点。五个节点里需要有三个日志写成功,这种情况下,即使同时坏了两个节点,生产系统也完全不受影响。虽然提高了成本,但是比起整个系统的可用性来说,是一个能够接受的代价。接下来就是怎么解决分布式事务的问题。分布式事务两阶段提交模型虽然看起来相当美好,但是实际上一旦节点在第二阶段出现故障,则事务既无法提交也无法回滚,只能被挂起,在实际生产系统中,这会导致数据库的连接迅速被耗尽,从而使得服务中断。OceanBase做了一个小小的改变:我们把原来的每一个物理节点换成一个Paxos组,相当于换成一个虚拟节点,这个虚拟节点背后有三/五个物理节点。根据多数派成功协议,三/五个节点里有两/三个节点写成功这个事务就被判定为成功实际上使用了这样一种方式解决了我们提到的万一有一台机器故障,两阶段提交就没办法推进下去的问题。我们就是通过这样一些看上去相对简单的方式解决了分布式事务的问题。其实,无论是主库备库不一致还是分布式事务的缺陷,根本的原因是传统关系数据库软件自身高可用的缺失,即传统关系数据库都是通过外部硬件来保证可用性,而没有从数据库系统内部来解决问题。

OceanBase征战TPC-C的艰辛之路

TPC-C benchmark诞生于上个世纪80年代,ATM自动提款机问世以后,数据库厂商都希望推销自家的在线交易处理系统。各个数据库厂商在在线交易处理的benchmark上各自为政,一直没有一个统一的规范,既缺乏足够的说服力,用户也无法在各个系统之间进行参照和对比。

就在这时,Jim Gray联合多位学术界、工业界的权威人士提出了DebitCredit标准。标准虽然出台了,但是数据库厂商却并没有严格按照标准测试,而是肆意篡改标准让自己跑出更高的结果。这就好比有了法律却没有执法的队伍,每个人都按照自己的理解来解释法律和执行法律。

Omri Serlin非常了不起,他说服了8家公司成立TPC组织,并且制定了TPC系列标准,相当于立法;同时TPC组织还负责监督审核测试过程和测试结果,相当于执法。从这之后,数据库领域各自为政的benchmark才有了一个统一的标准。

目前,TPC-C benchmark在国际上被认为是最重要、最权威的标准之一。TPC-C模型本身看起来很简单,就是五种事务的模型。但即使在今天在各个行业,包括电子商务、银行、商场、交通、通信、政府、企业里等等这些业务的抽象依然都是TPC-C模型。

当我们完成了TPC-C的优化工作以后,我们发现今年双11的OceanBase的性能目标已经提前达成,这也是因为TPC-C是实际生产系统很好的抽象,尽管实际的生产系统更复杂。TPC-C制定了五种事务的百分比,分别是:订单创建(<=45%)和订单支付(>=43%)以及订单查询、订单配送和库存查询各(>=4%)。其中,还有一些限制,比如规定每个Warehouse最多只能贡献12.86tpmC(tpmC即订单创建每分钟所执行的数量)。所以这会导致一个直接的结果,性能与数据量成正比,也就是要跑更高的性能,自然需要更多的仓库。每个仓库的数据大概是70MB,同时TPC-C还要求满足60天压测的存储容量。OceanBase跑了6088万tpmC,对应的存储空间是PB级别的。

TPC-C的测试和审计是一个特别严格的过程,OceanBase团队前前后后花了接近一年的时间才完成。TPC-C审计要求首先做功能的验证,也就是数据库事务的ACID。等功能验证通过了以后,才能跑性能。跑性能则有两个要求:第一,要求8小时稳定运行,没有任何人工干预的运行;第二,性能采集至少进行2小时且期间的性能波动不超过2%。这些都是实际生产系统的要求。

整个测试不限硬件和软件,只要能够通过测试(需要公开系统组成和价格)。

TPC-C benchmark记录分为几种:in-review,active,history。当结果刚做出来,审计通过之后,在网站上的状态是in-review,即公示期,这个公示期是60天。在公示期之内,任何人都可以对该结果提出质疑,测试厂商必须要解释清楚这个质疑,甚至有可能再跑一遍benchmark。与此同时,TPC也规定一旦进入in-review的状态,厂商已经可以对外宣传。当然与此同时,厂商也需要承担一定的风险:如果最后的结果被人质疑并且没有通过,这个结果是会被撤销的,被撤销的结果在TPC网站上是查不到的。

所以在整个测试过程中,OceanBase用的都是最最保守的方式,用最高的要求,比如性能采集,OceanBase使用的不是2小时而是8小时,在整个8小时中性能波动不是<2%而是<0.5%,这使得OceanBase最后测出的性能曲线几乎是一条直线全球一共有3位TPC-C的审计员,都在美国,这次OceanBase的TPC-C测试是由其中的两位审计员联合审计通过

还有一种记录是active,就是公示期结束之后的结果,这时用户可以用披露书上价格买到整套系统。另外一种记录是history,记录依然是有效的,但由于时间等原因系统的部分组件(特别是硬件)不再有售,因此整套系统不再完整有售。

肯定会有人好奇,在整个TPC-C的历史上, IBM也曾经高居榜首几个月,然后很快被Oracle超过了。为什么Oracle结果已经出来九年多了,这个期间没有厂商测出更高的tpmC,包括Oracle自己?

第一个原因是测试TPC-C benchmark的投入。进行TPC-C测试需要投入人力和物力,传统数据库厂商要测出一个较高的tpmC,高端服务器和高端存储是一笔不小的投入。这个投入不是披露书中的成本,后者是整个系统三年的总体拥有成本,比如OceanBase披露的大约是3.8亿,这实际上是整个系统三年所有的成本,包括软件、硬件和服务的总体拥有成本。得益于阿里云公有云虚拟机的按需租赁,OceanBase实际的测试成本跟这个三年总体拥有成本相比有不止一个数量级的差距

第二个原因是即便参与,如果最后的结果依然不如Oracle,主流厂商很可能宁可不测。没有挑战,那么Oracle自己也没有必要和动力去刷新这个记录,况且做更高的tpmC至少要花千万计的美元,是一个不菲的成本。Oracle在这9年多的时间也不是什么都不做,它至少做了两件事:第一,2012年Oracle用X2-8 x86Server单机测出500万tpmC,第二,又过了一年,2013年Oracle用T5-8 SparcServer单机测出850万tpmC。Oracle在测出3000万tpmC时用了27台服务器的RAC,500万tpmC乘以27,甚至850万乘以27,哪怕结果做不到线性,也会是一个上亿的结果。竞争对手如果没有把握,就不会轻易去挑战。OceanBase之所以敢于挑战,就是因为自身的分布式水平扩展能力,而RAC的有效节点数是十分有限的。

坦率的说,OceanBase跟Oracle比在功能上还有不小的差距,单机的性能也有距离, OceanBase最大的优势是可以用多个廉价的服务器达到昂贵高端硬件所能达到的极致性能以及更高的可用性

从OceanBase立项第一天起,我们的目标就是做一款通用的数据库。当我们在解决了内部用得好的问题以后,我们就把更多的精力投入到外部市场上。所以OceanBase自2017年对外商用以后,今天已经在几十家商业银行落地应用。未来,OceanBase还有很长的路要走,比如在走访客户的过程中我们发现,绝大部分业务既需要OLTP又需要OLAP,而这正是OceanBase的产品目标:同时支持OLAP和OLTP,即HTAP。TPC-C是一个很好的起点,我们也希望基于这个起点能够不断磨砺产品,让这样一款通用型的数据库未来能够为整个社会提供更好的服务。

Image placeholder
思维Владимир
未设置
  65人点赞

没有讨论,发表一下自己的看法吧

推荐文章
谷歌两位创始人双双“退位”,皮猜升职Alphabet帝国CEO独揽大权

大数据文摘出品两位创始人双双“退位”,Alphabet刚刚赢来了新阶段。美国时间周二12月3日下午,谷歌联合创始人拉里·佩奇(LarryPage)和谢尔盖·布林(SergeyBrin)宣布辞职,从即日

写速度提升20%,Elasticsearch 创始人给腾讯云发感谢信

近日,Elasticsearch的创始人兼首席执行官ShayBanon向腾讯云发出了一封感谢信,专程对腾讯团队为Elasticsearch开源社区做出的贡献表示了感谢。据了解,腾讯工程师通过提交代码,

大神程序员,夜夜coding到天明?Python之父昼伏夜出,PHP创始人24小时都在线

栗子鱼羊 发自凹非寺转自量子位 |公众号QbitAI大神程序员,夜夜coding到天明?有位名叫IvanBessarabov(简称“伊万”)的好事者,刚刚统计了各路大佬的代码提交(gitcommit)

YC中国创始人陆奇:人工智能时代,芯片和底层软件基本都要重做

大数据文摘出品作者:陆奇编辑:周素云2019年5月18日,在YC中国举办的YC中国创业者见面会上,YC中国创始人及首席执行官,YC全球研究院院长陆奇进行了以“技术驱动创新带来的创业机遇”为主题的精彩分

Stack Overflow上188万浏览量的提问:Java 到底是值传递还是引用传递?

在逛StackOverflow的时候,发现了一些访问量像阿尔卑斯山一样高的问题,比如说这个:Java到底是值传递还是引用传递?访问量足足有188万+,这不得了啊!说明有很多很多的程序员被这个问题困扰过

TPC-C解析系列02_OceanBase如何做TPC-C测试

导语:蚂蚁金服自研数据库OceanBase登顶TPC-C引起业内广泛关注,为了更清楚的展示其中的技术细节,我们特意邀请OceanBase核心研发人员对本次测试进行技术解读,共包括五篇:1)TPC-C基

企业上云的背后 看新数科技如何推动数据库创新?

随着云时代的来临,特别是公有云的快速发展,给后起云厂商提供了一个难逢的机遇,使他们可以抛弃传统架构的束缚,采用新技术来重新设计数据库,从而更好的满足云计算时代下用户的需求。企业上“云”已然不是一个趋势

对话OceanBase资深总监韩鸿源:数据库是技术能力,云是使用方式,两者不应是竞争关系

5月10日,在第十届中国数据库技术大会(DTCC2019)上,蚂蚁金服的金融级分布式关系数据库OceanBase2.0,在经过200名数据库领域三年以上的从业者投票和专业评委的评选下,高分荣获了“年度

数据基础设施重定义 华为AI-Native数据库全球发布

2019年5月15日,华为公司在北京面向全球发布了人工智能原生(AI-Native)数据库GaussDB和分布式存储FusionStorage8.0。发布会上,华为常务董事、ICT战略与Marketi

双11、TPC-C?OceanBase的征程在哪里?

蚂蚁金服自研的分布式关系数据库OceanBase登顶TPC-C一个月后,便迎来了2019年双11大考,团队相信“TPC-C只是双11的虚拟预演,双11才是一次真实场景的TPC-C。”OceanBase

如何理性看待蚂蚁金服OceanBase刷新TPC-C纪录

OceanBase这两天霸屏朋友圈!一派是浮夸的宣传,超越Oracle,世界第一,过度解读,全面否定对手,引起了技术圈内人士的反感,因为刷新TPC-C纪录并不能说明OceanBase现在就超越了Ora

Oracle数据库不同损坏级别的恢复详解

墨墨导读:在DBA的日常工作中不可避免存在着数据库的损坏,本文将主要介绍Oracle数据库遇到不同损坏级别下的应该采用的恢复方法,供读者在遇到此类情景时,能的找到适合自己的恢复方法,提高工作效率。数据

走进龙岗“智慧大脑” 见证IOC的最佳实践

这里,拥有全球首例地铁5G超宽带车地无线通讯;这里,借助AI、5G、物联网等技术推动工地现场科学化和智能化管理;这里,构建了开放兼容的统一政务云平台;这里,建设了先进、安全、智能的标杆园区;这里,就是

分布式存储时代,横空出世的OceanBase

数据,被誉为新时代的石油。几乎任何一个企业的IT管理者,都会在演讲、采访或其他形式的交流分享中强调数据的重要性。获取洞察、行为预测、市场分析、业务转型升级……数据能够为企业带来巨大的商业价值。但与此同

史上最全Oracle数据泵常用命令

导读:expdp和impdp是oracle数据库之间移动数据的工具,本文简单总结了数据泵的常用命令,希望对大家有帮助。前言expdp和impdp是oracle数据库之间移动数据的工具。expdp和

OOW2019 :Oracle数据管理技术创新盘点

Oracle作为传统关系型数据库的霸主,不管是数据库性能还是商业上,一直以来都是全球各大数据库厂商致力追赶的对象。近年来,全球云数据库市场迅速发展,Gartner预测,到2023年,世界上四分之三的数

0103-springmvc的基本流程

背景现在的it研发,已经从管理系统时代迈入了互联网系统时代。页面开发已经从基于JSP+struts转变为为前后端分离的方式(springMVC+JS);思想MVCmvc框架不仅适用于java的开发,也

互联网是如何把“原始人”逼成“机器人”

【导读】互联网快速发展的这十多年,我们见证了企业软件架构的多次迭代和演变。初期阶段都使用JSP+Servlet,工程师感觉代码直接写在jsp页面上不优雅,也不方便调试。后续发展为JSP+Javabea

对话蒋杰、丁奇,腾讯云数据库之路

此前,笔者曾经就腾讯云数据库战略升级一事写过一篇文章,对腾讯云数据库聚焦“云原生”“自治”“超融合”三大方向背后原因,以及怎样理解腾讯云数据库战略升级与五大新品、三大方向的关系进行了分析。近日,在腾讯

国产自研数据库DM8发布 看冯裕才的四十年“达梦”之路

5月8日下午,借助第十届中国数据库技术大会(DTCC2019),国内知名数据库管理系统和大数据平台软件及解决方案提供商、武汉达梦数据库有限公司(以下简称“达梦”)发布了新一代数据库产品–DM8。这一天

从网络接入层到 Service Mesh,蚂蚁金服网络代理的演进之路

本文作者:肖涵(涵畅)上篇文章《 诗和远方:蚂蚁金服ServiceMesh深度实践|QCon实录》中, 介绍了ServiceMesh在蚂蚁金服的落地情况和即将来临的双十一大考,帮助大家了解Servic

GoWeb教程_08.1. Socket 编程

在很多底层网络应用开发者的眼里一切编程都是Socket,话虽然有点夸张,但却也几乎如此了,现在的网络编程几乎都是用Socket来编程。你想过这些情景么?我们每天打开浏览器浏览网页时,浏览器进程怎么和W

GoWeb教程_08.2. WebSocket

WebSocket是HTML5的重要特性,它实现了基于浏览器的远程socket,它使浏览器和服务器可以进行全双工通信,许多浏览器(Firefox、GoogleChrome和Safari)都已对此做了支

哈登vs字母哥,看AI怎样预测今年NBA最有价值球员!

想必篮球爱好者们都非常关注今年的NBA季后赛,MVP的奖项投票结果尚未出炉,但估计各家球迷们心中各有定论了。所以我们来用机器学习预测一下今年MVP奖项的结果。 哈登(JamesHarden)和字母哥(

TPC-C解析系列04_TPC-C基准测试之数据库事务引擎的挑战

OceanBase这次TPC-C测试与榜单上Oracle和DB2等其他数据库在硬件使用上有非常大的不同,OceanBase的数据库服务器使用的是204+3台型号是ecs.i2.16xlarge阿里云E