今天我会围绕以上几个方面展开：首先，为什么要选这个项目来做，我自己没学过数据库，而且在当时也没用过。项目诞生之后很快就遇到了生存危机，危机之后找到一些发展机会。我经常跟很多人讲，数据库跟图书馆书架特别像，数据库其实就是个数字图书馆，大家想想看在一个块里插一套记录，是不是就相当于插一本书进去把别人的书往后挪一下。
李国杰院士跟我讲：“最好的东西就是ACID，最糟糕的东西也是它”。之所以糟糕，是因为最不好做，最难的也在这里。关系数据库能做很多事，它的核心是具备了三个能力——记账、转账、算账，因为数据库就是在这个领域诞生的，它主要做的也就是这两大类事情，一个交易处理，一个分析处理。
从业务的角度上看，数据库要保持稳定，要高性能，不能宕机，所以这样一个系统其实它又处在最底层，门槛很高，技术复杂，而且业务场景比较苛刻。像支付宝以及所有的蚂蚁集团数据库都在OceanBase上，我们有数万台，最低谷时候的交易可能都有几百笔每秒，所以系统一旦停止运行几秒钟，最少也会影响到几百个人的使用。
Oracle、IBM的服务器，EMC2的存储，数据库确实看起来存在一些局限，为了满足ACID要用的集中式的存储，它就变得难以扩展且要满足高可用。因为需要高可靠的服务器和存储，所以就变得非常昂贵。而且还需要备库，但是主备库其实做不到一致，根本原因是它的可用性跟一致性其实是不可兼得的。
至于分布式数据库，理论上它是正确的，可它实际中不能用。因为节点会出现故障，只要有一个节点有故障，数据库的行为就是不可知的。所以，这么多年来分布式数据库从来没有真正在生产中使用过。
关系数据库的另外一个局限，是OLTP跟OLAP是分开的。一个是按一条条交易记录进行，一个是按列做属性的分析。这两个很不一样，无形之中带来了很大的成本提升。暂且不论高成本，就一个延时，大多数的报表只能在第二天才看得到，所以大家经常在分析里面听到一个词叫t+1，现在做的好能做到t加几个小时，但大部分还是t+1天。另外就是复查，哪怕表面有调整，那么不只是你的业务要调整，你的传输链路和分析系统都要做调整。
此外，分析系统的数据会变得无穷大，因为每个做报表的人都要按照自己的维度来抽取数据做转换。没有一个企业愿意用新的数据库，因为这对业务系统来讲是个很大的风险。另外，还有大量的业务场景，其实数据库就是实践中用出来的，没有一个软件你能证明它是正确的，你只能证明它是错误的。所以从关系模型出现到现在的数据库，都是出现了很多问题后，慢慢变得稳定和成熟。
互联网对数据库的使用与传统企业对数据库的使用有一个很大的差别。第一，不管是商场还是酒店的数据库系统，甚至当时没有互联网的银行系统，只有几个柜台和操作员，所以并发量、访问量、数据量都在那不会有什么变化。互联网是完全不一样的境界，而且关键是原来的数据库贵，用的是高端服务器，要有这么大的访问量，还要买这么多的机器跟设备，所以其实是一个特别好的机会。我2010年到了淘宝之后就立项做了这件事情。大家给我的反馈就是说小马拉大车，业务跑得很快，发展得很大，但是数据库就那么大，而且关键是他们最大的抱怨是当时数据库都用的是小型机存储，是你要下单人家才生产的，从你下单到生产，最少要三个月才能完成，但这在互联网公司根本不可能。
所以有两个办法解决：马小车大一共就两类，一个就是把车改小，这个就是淘宝跟天猫后来做的，把原来一个大数据库拆成好多个，后来单个表都不够了，在一个库里放不下，又把这个表拆开。这个事情对于业务的改造影响挺大，这么改造之后join就没有办法用，这个办法不是普适的办法。
还有一个是想办法把数据库做大，用多匹马来拉车。第一个是有需求才有机会，而且最大的好处是说那时候大家都没觉得数据库有这么重要，所以我们有足够长的时间能够让数据库慢慢地成熟起来。第二个最大的原因就是有业务场景，因为数据库做出来了，想让它稳定成熟，就要使用。第三个原因就跟我自己有关，我是做分布式系统的，数据库单机的尽头，肯定得走向分布式，所以有一波分布式的人一起来做这件事情，机会更大一些。
后来有个业务愿意采用——淘宝的收藏夹。这个业务比较特殊，它很简单。每次打开收藏夹，商品都得刷新一次，因为有些商品可能下架了也可能降价了，平均一个人大概收藏100件商品，所以商品库就得刷100次，一刷后边数据库就垮掉了。我们打算把这个表做成个冗余的，把价格等这些信息都给他拽过来，放在这个表里，但即使这样还不行，因为有了冗余之后，你每次还得去看那张商品表有没有变化。所以我们当时用了一个数据库里大家从来不用的办法，把修改放在内存里面，修改的增量不写到数据库里面去，后边做个大合并。这个东西就像图书馆有个大书架，大家在这借书新的书进来了，我先不动大书架，我在旁边放个小书架，我就不整理新来的书，先放在小书架上，但每次要查书的时候，大小书架都得看会麻烦一点，但是至少解决掉了这个问题。因为这样修改的数据总是少的。第二，它在内存里面能查得出来，跟他们讲了这个方案之后，他们就愿意改。
后来支付宝那边在找数据库，就把我们整个团队调过去了。支付宝想把Oracle去掉，一个原因是成本，还有一个是硬件设备的故障。因为支付宝的系统大了之后，也做了拆库，但数量太多放不下。设备出故障成了一个经常性的事情，但是金融里面涉及到钱，而且随着设备不断增加出问题的概率就越大，所以他们提的核心就是能否解决掉这个问题。
这是当时给他们做的方案图，假如这是一个数据库，我们正常的主备库其实就是做一笔事务同步一次。我们前面讲过主备库做不到既保证完全一致，又保证高可用，因为要保证完全一致就可能牺牲可用性。只要有一台坏了，这个系统就会出问题。所以我们当时的做法这个词叫Paxos。我用一台主库两台备库，我们至少有两个节点成功，其实消耗的CPU很小。如果真的是主库坏了，所有的数据在这两台上，所以这两台中只要有一个选择主库跟另外一个做同步，就能把数据很快的补齐，所以当时我们做到了30秒自动恢复。有人说万一两台同时坏了怎么办？理论上还存在有一定的概率，所以支付宝的重要的业务都是用的5台机器，1台要做、另外的4台显示，所以要求有3台成功，同时三台坏的概率毕竟还是太低了。因为每台机器其实网络都是互通的，现在变成了是三台机器在工作，这样其实是把分布式事务里面一个最基础的问题解决掉了。经过一段时间运行之后，大家发现再也不用后半夜起来了，因为机器出故障，它是自动会恢复的，只要应用程序重试一下数据库就正常了。
当时在交易库没上线的时候，团队的大部分同学就抽出去做1.0，把自己做成了真正的分布式数据，1.0做得很难，整整两年从开发到互联网版本的提交，而且做完了之后就用到了支付宝的账户库。升级版其实是个全新的版本，第一次又用在了最核心的账目上。
2015年当时的网商银行考虑之后选择全部用OceanBase构建他们的系统，那时候还没有1.0，所以他们用的0.5。到2016年1.0出来了之后，整个系统的稳定性状态都会变得好了很多。但是同时对于团队来讲，其实我们又到了一个天花板，那时候支付宝的整个系统还有好多没有迁到OceanBase上，但是它只是个时间问题了。走出去肯定是个必然的选择，而且这个项目从第一天立项起，我们就要做一个通用的数据库。
现在有了开源的数据库，大家为什么还要买一个商业数据库？除了特别大的互联网公司，还有一些大银行大金融机构之外，其他的很多机构或者说它的大部分业务单机就够了，而且现在的单个计算机处理能力越来越强，存储的容量也越来越大，所以只有少部分的企业的少部分业务才需要用分布式，如果我们做一个分布式，就是给这么少量企业少量的业务用，这个价值也是不大的。第二就是主备库，主备库的作用还有，但是它不像以前了，因为有了这种三个副本以后，它很大的程度上解决了原来的备库的角色，所以主备库不等的这个问题其实也减少了很多。第三个就是因为有了三个部门，现在的数据库大家都用普通的PC机了，所以他也不需要高端的硬件了。还有一个没解决的就是TP/AP是两套系统，这个问题还存在，所以我们从16年底的时候，看能不能找到我们这个系统有用的机会，如果我们要解决这个问题，原来是两套，有没有可能把它变成一套。
如果用行存的话列的分析效率很低，所以大家想那我就用列存，但是用列存的问题在于，如果要新插入一条记录，我画的这个表只有4个列，你只要修改4处，如果这个表100列、1000个列，那就要修改100处修改1000处，这个代价是做交易处理不能接受的。但是我们有好处，有小书架的优势，你插进来的记录，哪怕你是列存我可以先不改数据库本身，先记到增量修改的增量，修改的增量大部分情况下内存够用，如果内存不够，就用虚拟内存放在硬盘上，读的话可以考虑用一些缓存，用这样的一些机制来缓解。如果我们用这个办法来做，我们是有可能用一个数据库把两件事情都完成，而且还能解决它的实时分析的问题。所以我们还是在想办法当下能够帮助用户能做一些什么事情，怎么能够踏进这块市场。第一个是扩容。虽然说是少部分用户的少部分业务有分布式的数据库的需求，这样他不用改业务。
比方说大家看这个企业的业务图，在中午或晚上这个点它的业务流量比较高，其他的时间业务流量比较小。你给他一个大的服务器，确实能把业务流量都支撑起来，但是这个服务器它不是什么时候都满负荷的，其实是浪费。如果我们用分布式是有机会做这件事情的，就是他平时的业务流量小的时候，我可能给他一个小的虚拟节点，他业务流量大的时候给他增加这些节点，等他业务流量再小的时候，又把这个节点再缩容缩回去。传统的数据库要做在线的数据库替换，这个事情是很难的，但分布式数据库干这件事情也难。所以从这一点上来看的话，我们是有机会把企业的这些普通的小的业务或者中小企业这种业务的成本降低起码一半。第二件事情是我们吸引用户很重要的一点，我们今天做的业务里面有很大的比例是因为两件事，一个就是我们做了Oracle的兼容，还有一个就是我们在MySQL的压缩的基础上，我们还能再压3~6倍，在实际生产数据中我们大概是5~10倍的压缩率。
中国人寿把它的整个核心系统全部搬到OceanBase上来了，结果他的机架空了2/3，这个价值还是很大的，因为存储还是挺贵的。还有比方说用户决定要用我们了，如果他要把对业务做大的改动，没有人愿意来做这个事情，所以我们一早就做了这两件事，我们没有自己定义SQL，没有自己的语法，最早做的是MySQL，后来做了Oracle，因为蚂蚁也有这个需求，蚂蚁有很多MySQL和Oracle的业务，没有一个人愿意去把业务迁过来，所以我们做的就是让他不改业务。你只要把数据库重定向到我们这，系统就整个迁过来了，而且对于外部的用户来讲，这还有一个好处，哪一天你觉得我们做的不好了，还可以迁回MySQL、迁回到Oracle去。
我们当时决定一件事情要做开源，因为大家看PG跟MYSQL这两个数据库成长起来，开源功不可没。17年迎来了第一个愿意尝试的用户就是南京银行。他们当时考察了好几个数据库，到最后选到了我们。我们遇到的困难，第一个是功能缺失，因为数据库的功能你做了，但是如果没有大量的使用那个功能，它的各种方面的情况都得不到考验。所以我们除了蚂蚁集团用到的功能之外，其他的很多功能都是不完善的。第二个是质疑，大家觉得做个数据库就很难，你们还做了个分布式数据库，全世界谁都没做出来的，就你们做出来了，想一想这个事情就不靠谱。
那怎么证明我们的数据库是稳定可靠的数据库？从我们的角度来讲，那时候我们的团队人员快上百号人了，做TPC-C。18年的8月份启动，直到第二年的5月份才做出来，这里面有各种困难。
我们现在有一些国外的业务，但目前来讲金融的业务还是占了超过一半多一点，那么非金融的业务现在也接近一半，确实这三年来业务这块发展得很快，可能就觉得形势大好，其实不完全是这样。现在全世界数据库收入最大的公司不是Oracle，是微软。因为它的云上数据库业务卖得很好，而且全世界不管是中国还是美国，还是整个全世界，就是公有云上的数据库的销售收入已经远远的超过了线下的数据库的收入。公有云确实带来了很大的好处。很多企业，特别是这种发展中的中小企业，他不用去关注太多的数据库，不用去关注太多业务之外的东西。
数据库电商就是一个服务，一个工具，他想用付费就可以用，扩容和收容都是一念之间，所以这一块来讲，在全世界范围内的公有云的业务都发展得很快。但是OceanBase其实在之前这方面做的不够，因为那个版本主要就是给蚂蚁集团用，因为只有蚂蚁集团的那些用的功能一些特点才得到了优化。我跟大家举个例子，我们刚出来的时候，我们要用的服务器外面的企业都没有，大家说你们用了很多特殊的服务器吗？不算特殊，就是内存很大，CPU很多，我们的内存是768G。大家说你们蚂蚁为什么要买这么大的容量的服务器，跟它的业务有关？第一它的访问量要很大，还有一个原因，我们绝大部分机房都是租的，很贵，机架4年下来比一台机器都贵，所以你在那台机架上你放越高档的服务器，处理能力越强越合算，这样我们的程序是在这种高配置下性能跑的特别好，低配置下装都装不上去。我们大家做很多的调整，把程序做一些改动，来适应这些低配置的服务器。
我们要做一个新的版本有很多从原来的基础上来继承的。我们要想做到两件事情，第一，我们不能只是一个分布式数据库，一个分布式数据库是需要多台机器需要高配置，我们要做成一个单机跟分布式都能够兼容，业务小的时候是单机，业务大了，它能够扩容到分布式，单机的时候，它可能有更好的性能，而且要能在很低配置的机器上可以运行。另外还要做一件事情，我们要把交易跟分析要逐步做成一体化，所以这个版本是能做这两件事的。
另外就是SQL的优化器，对于数据库来讲几乎是一个无底洞，写得好的SQL能跑很快，这个是Oracle做得非常好的地方，Oracle的优化器不见得每一条它都是优化到最好。所以这样他对业务的要求就降低了对业务人员的要求。另外是像我们在我们这个系统下，分布式给SQL的优化其实是带来很大的挑战，它要在所有的节点综合起来的好，你一个节点很好，另外的节点很差，这个结果也不好。还有我们这种特殊的存储结构，其实给优化器带来了很大的挑战，因为原来的数据库它是一种渐进的。整个优化器的统计信息也是在缓慢的变，背景不是每天做一次大合并，合并之前的数据它的分布是不一样的，基线的数据是稳定的，增量的数据是另外一种表现形态，那么做完了合并之后优化器其实很多信息统计是变化的，对这个也是我们面临的另外一个挑战。
还有就是隔离，因为数据库今天单台机器的处理能力也越来越强，大公司它有很多小业务，我们有一个机群可能有几百个业务，它里面分很多个租户，把很多个业务都放在这一个小租户里面，因为不少业务的用户很少，你又没办法把它关掉，我们就把它放在租户里面，那么租户与租户之间的隔离，其实跟虚拟机一样。
物理界的隔离最好最安全，但是成本高，这些年发展过去虚拟机容器的隔离已经做得越来越好，这个是我们一直在努力的方向。我们现在的系统里面TP跟AP都有，他们两个之间的隔离也是需要的，因为一个大的AP查询，可能把很多CPU内存都消耗掉了，因为CPU是对响应时间很敏感的事物，需要快速的响应。
另外是自动的故障恢复。当年支付宝的交易库第一次的时候，我们提了一个标准，就是30秒自动恢复，这个东西今天已经成了中国金融界的一个标准，大家都是提30秒，我们这次到4.0把它做成了8秒，其实8秒对于用户也是不够的，我们接下来目标是我们能做到一秒或者500毫秒，但是这个是很大的一个挑战。
还有易用性，最早我们的系统刚出来的时候，我们自己的开发人员都跑了十几趟才把它装上。那么到今天有了开源这些之后，几分钟就能够装上了，但还是要变得更简单。数据库在使用的过程中遇到了问题，你怎么能够快速的定位，只有做到了这些，用户才能够更好的使用这个系统。
简单总结，如果回头来看的话，OceanBase数据库大概就走了这么几年（见上图）。到了我们2020年成立了现在的OceanBase公司，就是专门做数据库业务，然后做了开源和4.0。
我自己也说一说感受，这些年做软件的开发，我自己觉得三条比较重要。技术不是那么高大上，比方说像MySQL兼容，Oracle兼容，它对于技术上来讲很繁琐，但是它对于用户有很大的价值，所以我们坚持做业务小步快跑，第一个版本只做了主备库，有个中心写入节点，第二个大的版本是做了三个副本，第三个大的版本才做到分布式，到现在第四个大的版本或者第五个大的版本，才真正的做到了一些更多的东西交易分析一体化，分布式单机的一体化。所以如果要想做一件事情，在这个业务上取得成功，在产品上取得成功，最要记住的是说你的这件事情的初心是整个用户的群体。第二，我们也做了一些技术上比较牛的东西，比方说像Paxos选举算法，如果主库突然宕掉之后，剩下的几个备库没有一个能确定主库，因为有可能是他自己的网络坏掉了，所以大家要做选举，这个选举其实是随机的。但是对于用户来讲，特别是对于一些重要行业的用户，必须要确定万一主库突然坏了，多长时间能恢复。所以我们有个承诺，原来是30秒，很大一部分是考虑到这中间的一些某种随机程度发生，但我们这中间其实是用了一个确定性的选举算法，就我最坏的情况下确保多少时间能选举出来。
第三，要能够坚定不移。当年选这个项目，第一它技术难度很大，如果我做得出来，别人要想来追也会很难。这个产品的价值又很大，如果真能把它做到普遍实用，社会价值经济价值都会很大。
我觉得这样的事没有捷径，开源是个很好的东西，就作为一个普通的用户，你可以用开源数据库，但如果是数据库厂商，你用别人的开源数据库来做，我觉得应该是难的。一旦有了捷径，这个捷径就对所有的人都适用了。数据库其实从立项的第一天起，我们跟大家的目标好像不同，因为数据库本质上没有国界。所以这几年我们也开始慢慢地往国外走，而且公有云给我们一个很好的机会，实际上公有云走到哪个国家，我们都得在当地有一个很大的团队。但如果在公有云上，这部分资源可以减少。
我就汇报到这里，谢谢大家。
校对：林亦霖
1613
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
