2010年我们为什么选择从零开始做OceanBase数据库
2016 年双 11 ，支付宝核心交易、支付、计费、会员、账务等核心数据链全都运行在阿里巴巴 / 蚂蚁金服从零开始自主研发的分布式关系数据库 OceanBase 上。为什么阿里巴巴 / 蚂蚁金服不是基于开源数据库，而是从零开始研发 OceanBase ？
【 2010 年数据库对淘宝 / 支付宝的制约】
【关系数据库的门槛】
【 OceanBase 的机会】
【为什么 OceanBase 没有基于已有的开源数据库进行开发】
【小结】
【 2010 年数据库对淘宝 / 支付宝的制约】
2010 年的淘宝 / 支付宝（现在的阿里巴巴 / 蚂蚁金服）正在重构业务代码，以便把业务系统从商业数据库迁移到开源的 mysql 上，数据库的硬件也从中高端服务器（小型机）和中高端存储（共享存储）迁移到普通 PC 服务器上。根据我当时的理解，原因有几个：
第一，昂贵的商业数据库软件成本。迅速发展的淘宝 / 支付宝，需要的数据库实例，在迅速增加。
第二，昂贵的商业数据库硬件（小型机和共享存储）成本。迅速发展的淘宝 / 支付宝，小型机和共享存储同样在迅速增加，硬件及其服务成本，也十分高昂。
第三，在高可用的要求下，数据库的主备镜像无法做到主库与备库完全一致。如果必须保证主库与备库完全一致，那么一旦备库异常或者主库备库之间的网络异常，数据库系统的写入就会被卡住；反之，如果允许主库与备库之间的事务不同步，一旦主库异常，则备库的数据通常就不完整。如果没有使用高可靠的硬件（例如高可靠服务器和高可靠存储），这个问题会频繁发生。
第四，传统数据库越来越无法容纳和处理互联网带来的飞速增长的数据，传统数据库这个“小引擎”无法容纳和处理这些海量的数据。
第五，业务发展被数据库严重制约。作为互联网 / 互联网金融公司，淘宝 / 支付宝需要对市场做出快速反应，数据库高昂的软件硬件成本使得其服务能力不能有很大的余量，小型机与共享存储的三个月甚至更长的购买、安装和调试周期成为了业务发展的严重桎梏，许多的促销或新业务因为数据库性能不足而被迫妥协甚至取消。
【关系数据库的门槛】
从关系数据库本身的特征来看，像 OceanBase 这样从零开始研制一款全新的关系数据库，看起来并不那么明智：
首先，关系数据库是一个非常成熟的产品，上个世界 90 年代中期之后，关系数据库的理论和产品都没有新的突破和大的变化。
其次，关系数据库是企业信息系统和生产经营系统的基石，关系数据库的任何异常，诸如功能失效、性能异常，都会妨碍企业的生产运作甚至使之陷入停顿，更不用说关系数据库的崩溃或者数据错误、数据丢失。
第三，关系数据库功能十分丰富、系统非常复杂，正确性与稳定性的挑战很大。商业的关系数据库和开源的商业数据库的正确性稳定性经过了 20~30 年的沉淀，数据库正确稳定与用户使用的关系类似于鸡与蛋的关系：没有被证明是正确稳定的数据库用户不愿意使用，而数据库的正确稳定只能通过用户使用来证明。
第四，关系数据库的性能挑战非常大，主要关系数据库厂商在性能提升上耗费了大量精力，投入了大量的资源。
因此无论是正确性、稳定性、功能还是性能几个方面来看，关系数据库都有很高的门槛（不是“门”，更多的是“槛”），“新玩家”进入十分困难：
从这个角度来讲，从零开始做一个数据库通常并不是一个好的选择。
【 OceanBase 的机会】
换一个角度来看，上述情况也正是 OceanBase 的机会：
第一， 2010 年数据库对淘宝 / 支付宝的制约，其实反映了以互联网为代表的新兴社会生产力对数据库的需求，例如传统的商业银行和商业门店，开业后连接数据库的终端数量是确定的，店面扩展、新开分店可能要半年甚至更长时间，对应数据库系统的扩容有足够的时间窗口。而互联网则完全不同，访问的用户数量无法确定，并且可能在几天甚至几小时内增长数倍，传统数据库的垂直扩展方式根本无法应对。
第二，数据库软件的正确性稳定性非常关键却又十分困难，但淘宝 / 支付宝有数以千计的数据库生产系统，完全能够把一个有价值的自研数据库打磨得非常稳定可靠。
第三， PC 服务器和分布式技术给 OceanBase 提供了在大幅度降低数据库硬件成本的同时，进一步提升数据库可用性的机会，比如三副本和 Paxos 协议完全可以在单机 / 单机群故障的情况下避免数据丢失，并且保证服务持续可用（至多若干秒的服务中断）。
第四， PC 服务器机群天然的水平扩展能力解决了数据库的小马（数据库引擎有限的容纳和处理能力）拉大车（海量数据）的尴尬局面，也消除了数据库对淘宝 / 支付宝的业务发展的制约。
第五，服务器内存的增加和固态盘（ SSD ）的普及为 OceanBase 提供了很好的机会。传统的数据库需要对硬盘进行大量的随机读和随机写， SSD 擅长随机读而不擅长随机写，大量随机导致写入放大严重影响性能，同时影响 SSD 寿命，当前最新的“读写型” SSD 则以增加成本和降低容量为代价。 OceanBase 采取了数据库的基线数据在硬盘（特别是 SSD ）、增量数据（增删改数据）在内存（辅以事务日志写盘）的模式，消除了硬盘的随机写，提升了性能。例如即使数据库一天 10 亿笔写事务，每笔 1KB ，总容量也不过 1TB ，分配到 10 台机器上，单机 100GB ，这个容量单机内存完全能够支撑。每天 OceanBase 的三个机群（ zone ）轮流地把内存数据批量整合到硬盘（称为每日“轮转合并”），正在整合的机群不对外提供服务（但接收事务日志并且参与 Paxos 投票），消除了每日合并对业务的影响。这个方案使得 OceanBase 得以使用比“读写型” SSD 性价比高得多的“读密集型” SSD ，降低了成本，却没有影响性能。每日合并批量写盘也对 SSD 十分友好，降低了 SSD 的故障率。
【为什么 OceanBase 没有基于已有的开源数据库进行开发】
基于成熟的开源数据库做二次开发，投入小、见效快，项目周期短、风险小。然而，由于开源数据库在技术方案上与商业数据库一脉相承，商业数据库厂商已经有了几十年的技术和生态积累， OceanBase 在人力物力的投入上比领先商业数据库厂商低不止一个数量级，作为后来者在类似技术方案下在性能等方面超越先行者十分困难，这就好比在同样的路线上骑自行车去追赶跑车：
此外，基于已有的开源数据库进行二次开发，还会使得 OceanBase 丧失自己的一些关键优势，例如 :
消除随机写盘带来的性能提升。
“读密集型” SSD 带来的成本节省。
传统关系数据库使用定长数据块，而 OceanBase 使用边长数据库，使用完全一样的数据压缩方法， OceanBase 通常能够有 50% 的存储空间节省。
传统关系数据库在刷脏页到硬盘的同时还在提供读写服务，而 OceanBase 每天轮转合并（参见“为什么 OceanBase 架构特别适合双十一”）的机群只接收事务日志和进行 Paxos 投票（其他机群提供读写服务），对 CPU 和硬盘 IO 消耗不敏感，因此不需要复杂的刷盘策略，也可以使用压缩速度较慢但压缩率较高的算法（通常还需要兼顾解压缩速度），以得到更好的压缩效果。
【小结】
从 2010 年 5 月调研、 6 月 25 日立项开始， OceanBase 的目标就是商业关系数据库，虽然说一开始 OceanBase 的关系数据库的功能很弱： 2012 年底才支持简单的 SQL ， 2014 年也只支持比较有限的 SQL ，直到 2016 年基本兼容了 MySQL ，对 SQL 的支持才比较丰富。
时至今日， OceanBase 的关系数据库内核才有了初步的模样，这使得 OceanBase 的架构优势开始显现，例如准内存数据库的性能优势，读密集型 SSD 的成本优势，三副本的高可用性优势，变长数据块的存储空间优势、每日合并时压缩倍率更高的压缩算法等等。这些都得益于 OceanBase 从零开始的研发以及对应的全新的架构。