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

相比传统的集中式数据库，分布式数据库可扩展性更强。面对飞速增长的需求，OceanBase不依赖单机，可以做到简单、便宜的扩容。同时，原先的小型机一台也要几十上百万，在OceanBase分布式的构想中，便宜的单机也可以拿来做服务器，从几十万到几万，OceanBase比Oracle便宜了不止一点半点。
分布式数据库容灾性也更强。由于OceanBase“不把鸡蛋放在一个篮子里”，当体系中某个单机出现问题时，数据库仍然能够稳定运行。“三地五中心，同城三机房”，蚂蚁的体系如此设计，只要大多数设备不同时宕机，系统的运行就不会受到影响。
HTAP（混合事务分析处理），这是OceanBase的又一大利器。
数据库的功能大致可以分为两类——OLTP和OLAP 。
OLTP指“在线事务和交易处理”，也就是“记账” 。买家的每一笔支出、商家的每一单销售，在平台上产生的每一条数据都要分门别类记载清楚。
OLAP指“在线分析处理”，也就是“数据分析” 。分析用户偏好、分析运营数据等能力都位列其中。
数据库的用户既有“记账”的需求，又有“分析”的需求，但这两种需求却通常需要以两个不同的数据库系统来分别满足，市场上少有可靠的、一站式的解决方案。操作两种系统，成本和难度自然更高。
如同左脑和右脑，“记账”和“分析”是两种不同的数据处理方式。“记账”需要实时与系统交互，数据要“逐行”存储；而分析则需要纵向对比，数据要“逐列”存储。
OceanBase做的，就是把“左脑”和“右脑”合并了起来，形成了一站式的解决方案。方便，而且便宜。说起来简单，将“行存”和“列存”做到一起并非易事，而分布式的架构设计又为HTAP模式提供了技术上的可行之处。
体系设计虽好，但实话说，2年真的不太够用。
OceanBase在头两年的成果难说让人满意，阳振坤自然深知这一点。在2012年底的时候，功能还有许多没能实现，团队也不够完备。在产品的第一关，OceanBase就输了。
缺乏业务也是OceanBase遇到的又一个难题。阿里内部的各业务群也当然并非“一心同体”，业务老大们要背自己的业务指标，总部做决定也要考虑到他们的利益，数据库是底层系统，不能强制他们“说换就换” 。在部门墙之下，OceanBase初来乍到，还没有与各业务部门建立起信任感，只能自下而上地“推销”自己的产品，自然事倍功半。
眼见2年之期将至，OceanBase面临着随时可能被公司关停的状况。
内外交困下，阳振坤还是获得了第二次机会。
传说中，还是阳振坤特意飞去杭州阿里总部，找到了他在微软的老同事王坚。王坚时任阿里CTO，当时也是他在阿里云最难的时候。他深知阳振坤在阿里从事科研的难度，也能看到OceanBase在未来数据库竞争中的潜力，于是在和相关领导协商后，发下了一纸调令。
不久后，OceanBase就被调整到了支付宝体系下。
但问及这段时间，阳振坤心中第一个想到的是现任阿里的CTO程立，花名鲁肃。在阳振坤和团队来到支付宝后，作为阿里技术人心中“神一样的人物”，鲁肃也看好原生分布式数据库的前景，于是帮助阳振坤在支付宝站稳了脚跟，这也为OceanBase在日后的崛起埋下了伏笔。
二、2014，逆袭的号角吹响
2014年，在支付宝，阳振坤和OceanBase终于等到了千载难逢的机会。
当年，双十一的交易量预期又将创下纪录。面对又一次大考，支付宝内部的数据库工程师如临大敌，又如火如荼地开始了数据库跑量的压力测试。