阿里巴巴|阿里的分布式数据库OceanBase:帮公司省了几百个亿( 二 )


数据库的功能大致可以分为两类——OLTP和OLAP 。
OLTP指“在线事务和交易处理”,也就是“记账” 。买家的每一笔支出、商家的每一单销售,在平台上产生的每一条数据都要分门别类记载清楚 。
OLAP指“在线分析处理”,也就是“数据分析” 。分析用户偏好、分析运营数据等能力都位列其中 。
数据库的用户既有“记账”的需求,又有“分析”的需求,但这两种需求却通常需要以两个不同的数据库系统来分别满足,市场上少有可靠的、一站式的解决方案 。操作两种系统,成本和难度自然更高 。
如同左脑和右脑,“记账”和“分析”是两种不同的数据处理方式 。“记账”需要实时与系统交互,数据要“逐行”存储;而分析则需要纵向对比,数据要“逐列”存储 。 
OceanBase做的,就是把“左脑”和“右脑”合并了起来,形成了一站式的解决方案 。方便,而且便宜 。说起来简单,将“行存”和“列存”做到一起并非易事,而分布式的架构设计又为HTAP模式提供了技术上的可行之处 。
体系设计虽好,但实话说,2年真的不太够用 。
OceanBase在头两年的成果难说让人满意,阳振坤自然深知这一点 。在2012年底的时候,功能还有许多没能实现,团队也不够完备 。在产品的第一关,OceanBase就输了 。
缺乏业务也是OceanBase遇到的又一个难题 。阿里内部的各业务群也当然并非“一心同体”,业务老大们要背自己的业务指标,总部做决定也要考虑到他们的利益,数据库是底层系统,不能强制他们“说换就换” 。在部门墙之下,OceanBase初来乍到,还没有与各业务部门建立起信任感,只能自下而上地“推销”自己的产品,自然事倍功半 。
眼见2年之期将至,OceanBase面临着随时可能被公司关停的状况 。
内外交困下,阳振坤还是获得了第二次机会 。
传说中,还是阳振坤特意飞去杭州阿里总部,找到了他在微软的老同事王坚 。王坚时任阿里CTO,当时也是他在阿里云最难的时候 。他深知阳振坤在阿里从事科研的难度,也能看到OceanBase在未来数据库竞争中的潜力,于是在和相关领导协商后,发下了一纸调令 。
不久后,OceanBase就被调整到了支付宝体系下 。
但问及这段时间,阳振坤心中第一个想到的是现任阿里的CTO程立,花名鲁肃 。在阳振坤和团队来到支付宝后,作为阿里技术人心中“神一样的人物”,鲁肃也看好原生分布式数据库的前景,于是帮助阳振坤在支付宝站稳了脚跟,这也为OceanBase在日后的崛起埋下了伏笔 。
二、2014,逆袭的号角吹响
2014年,在支付宝,阳振坤和OceanBase终于等到了千载难逢的机会 。 
当年,双十一的交易量预期又将创下纪录 。面对又一次大考,支付宝内部的数据库工程师如临大敌,又如火如荼地开始了数据库跑量的压力测试 。
大敌当前,阳振坤和他的团队却还在坐冷板凳 。多次主动请缨,支付宝却仅让OceanBase承担1%的业务流水 。又是一年的失望,属于OceanBase的翻盘点似乎还遥不可及 。
前文也提到了,OceanBase的功能和结构都比Oracle要强劲很多,为什么支付宝没有全面推广OceanBase应用呢?
IOE体系就是数据库界的PUA 。你明知它贵,你明知它不好用,你明知有更便宜、便捷的解决方案,但你愿意相信它 。在ToB生意里,信任最为难能可贵 。
“你如何保证OceanBase不弄丢支付宝用户的一分钱?”鲁肃的这句话也曾问懵过阳振坤 。
IOE虽然种种不好,但IOE胜在稳健 。许多技术负责人不愿用新的技术和产品,用老产品出问题可以怪产品,用新产品出问题就只能怪自己了 。
归根结底,没信任就没有使用,没有使用也就没有信任 。OceanBase就在这样一个死循环里苦苦挣扎 。
就在OceanBase的未来仍不明确的时候,一个“坏”消息传来:Oracle崩了!
原来,在跑量测试时,一直在蚂蚁内处于主导地位的Oracle竟然屡次崩溃,可承压能力仅有预期的90% 。
已经顾不上OceanBase是否可靠,在这时行不行都得上 。技术团队不得不做出了一个艰难的决定:紧急启用OceanBase 。
双十一的流量逐年都在增加,集中式的Oracle总会有一天跌落神坛 。阳振坤早就在等着这一天,OceanBase逆袭的机会来了!
于是OceanBase临危受命,接下了支付宝2014年双十一10%的流量 。
这是机遇,可又何尝不是重于泰山的压力?阳振坤深知,他和他的团队但凡出了一点差池,那么他和OceanBase在公司里就将永远失去信任,再没人敢用 。哪怕后面能够给业务带来好处,也无济于事 。


推荐阅读