OceanBase是一款完全自主研发的金融级分布式关系数据库，超过100万行的核心代码都由OceanBase团队的同学一行行敲出来。
从2010年立项到今天，过了8年；在最近4年多时间里，一直服务于金融核心业务。2014年，OceanBase开启了支付宝核心业务去Oracle的进程，在当年的“双十一”，支撑了10%的交易流量；最终在2017年，成功完成支付宝交易、支付、账务、会员等全部核心业务的去Oracle的工作。这在中国乃至全球都是一个标志性的事件。
对比一下美国的情况，前段时间有报道称亚马逊准备在2020年彻底去除对Oracle数据库的依赖，立刻引来了Oracle创始人的反击，他表示亚马逊已经尝试过很多次，但从未成功，足以见得去Oracle这件事对于企业而言的难度之大。
同样在2017年，OceanBase和蚂蚁金融科技的其他产品一起帮助南京银行建立了互联网金融核心系统。从去年开始截止到今天，OceanBase已经在6家外部金融机构上线，包括商业银行和保险机构。全球前三名的支付平台，两家的核心系统都在使用OceanBase数据库。
为了满足业务快速发展以及持续可用的要求，系统架构从集中式转向分布式是大势所趋。在数据库层面，要相应地从单机数据库转向分布式数据库。
今天，我们发布OceanBase 2.0版本，这是OceanBase数据库自身发展的里程碑，也是我们参与金融行业向分布式架构转型的关键一步，用数据库技术创新为业务架构转型奠定基础，解除行业发展的后顾之忧。
在架构转型过程中，技术决策者往往会碰到三大挑战：
第一大挑战：技术风险
第一个是技术风险，传统单机数据库系统经过几十年的发展，运行在可靠的专用硬件和存储上，在金融行业得到充分锻炼，整体稳定。分布式数据库系统运行在普通商业硬件上，采用廉价存储，运行环境和传统方式有很大差异，保证系统可用性和可靠性的手段也大不相同；同时在某些基本行为方面和传统单机数据库也有差异。比如要获取一个系统一致性快照，对单机数据库是一件很轻松的事情，但在分布式系统中，却没那么容易。如果不能提供一致性快照，业务系统就被迫要做相应的改造和调整，调整就会带来风险。可以说：对于一些基本特性，分布式数据库系统相对于传统数据库的每一个行为上的差异都增加了架构转型的不确定性，很有可能就是在转型的道路上埋了一个雷。
第二大挑战：迁移实施成本
传统数据库是功能的集大成者，分布式数据库由于发展时间较短以及分布式架构自身的复杂性，在功能上比传统数据库有所欠缺。如果缺少的正是业务系统需要的功能，往往就要通过修改业务系统来解决。除了系统改造成本，还有运维成本，人员知识结构更新带来的成本，等等。
第三大挑战：新产品的质量和服务
最后一点是新产品的质量和服务能否满足金融业务的要求。数据库产品和其他产品的重要差异在于它关乎企业的核心数据资产。数据库新产品的质量不能仅仅依靠测试报告来保证，而是要看有没有经过实际业务的长期锻炼。对于应用过程中出现的任何问题，技术研发和服务团队有没有能力限期解决。
上述的三个问题，是技术决策者需要思考和解决的。
OceanBase 2.0的发布，在一定程度上就是为了解决上面的三个问题，减轻技术决策者的决策风险。今天的报告分成如下六个部分，分别介绍OceanBase2.0在减少分布式架构对业务的影响、提高数据可用性、增强运维能力、提升性价比和产品兼容性方面的进展，最后还会谈一谈2.0版本在今年“双十一”大促中将要承担的任务。
业务透明的分布式系统
对分布式数据库而言，如果对业务能表现成一个具备动态伸缩能力、功能完备的高可用单机数据库，那基本上就达到了向业务屏蔽分布式架构复杂性的目标。把分布式架构实现的复杂性留给了自己，把便利性提供给了业务。为了这个目标，OceanBase 2.0版本实现了全局一致性快照，支持了全局索引，丰富了负载均衡策略。
1. OceanBase的整体架构
先来看一下OceanBase的架构，从1.0版本就确立下来的对等节点无共享存储分布式架构。集群中的每一个节点都是对等的，包含完备的SQL、事务、存储引擎，负责管理一部分分区，并响应客户端的请求。
在所有的节点中，有部分节点承担了集群全局性的管理功能，图例中的Root Service节点，略微有点特殊，但是这个管理能力是其他节点都具备的，在必要的时候可以随时接管。
为了高可用，数据通常有多个副本，分布在不同的可用区，图例中部署有三个可用区，单节点故障、单可用区故障都不会影响系统和数据的可用性。在9月20日ATEC主论坛中演示的“三地五中心”高可用架构，在发生城市级故障的时候数据不丢失，26秒恢复业务，用的数据库就是OceanBase。OceanBase也是云数据库，单个集群服务多个租户，租户之间数据和资源隔离。
2. 全局一致性快照
在没有实现全局一致性快照之前，分布式数据库在功能上是有比较大的欠缺的。有两个典型问题：一个是无法实现跨节点的一致性读，另一个是无法保证因果序。
无法实现跨节点的一致性读，对于应用系统设计和开发人员是很有挑战的，他们得保证在一条SQL语句中访问的多个表、多个分区都在同一个节点上，否则这个查询就会出错。
无法保证因果序的一个表现是：用户在两个事务中分别修改了位于两个节点上的两张表，先修改了源表，再改了目的表。但在另外的一个观察者看来：后修改的表已经在查询中反映出来了，但源表还没有变。这对于依赖操作顺序的业务系统，简直是个灾难。
OceanBase 2.0版本实现的全局一致性快照，从根本上解决了这些问题。相对于Google Truetime基于原子钟的硬件实现，OceanBase的全局时间戳（GTS）服务是纯软件实现的。不依赖特定的硬件设备，也不对客户方的部署环境提额外的要求，使得OceanBase能够服务更广泛的专有云客户。
全局时间戳（GTS）服务是系统的基础服务，该服务的性能和可用性对系统有很大的影响。OceanBase 2.0的单个全局时间戳服务1秒钟内能够响应2百万次以上的时间戳获取请求，满足单租户百万级TPS的要求。在系统满负荷运行的情况下，对性能的影响不超过5%。时间戳服务的高可用机制和数据分区高可用机制相同，后者在过去几年中经历了支付宝生产系统严苛的检验，非常稳定。
2.0版本的全局时间戳服务缺省打开，跨节点读写、因果序的行为和单机数据库完全一致。对于数据都集中在一台机器上的小租户，或者对性能有极致要求的租户，可以选择关闭自己的全局时间戳服务。
3. 全局索引
全局索引是单机数据库的常用功能，在分布式数据库中比较难实现。对于分区表来说，全局索引的价值在于为不带分区键条件的查询提供一种性能提升手段。在没有全局索引的时候，不带分区键条件的查询性能是比较差的，要在每一个分区上做一遍这个查询，而大部分分区上根本没有满足条件的记录。
我们看到，有些业务不能接受这么长的查询响应时间，就会创建另外一张表来模拟全局索引的功能，这个额外创建的表的维护就会带来很多问题，数据一致性、以及在何种情况下使用这个表都需要应用系统去管理。
全局索引功能将业务从这些问题中解脱出来。在全局索引的创建和使用上，OceanBase都基于代价做选择，在创建的时候，可以基于基本表，也可以基于另外一个索引。大表的索引创建通常耗时较长，对于大规模的分布式系统，设备故障也并不少见，为了提高创建索引成功率，在发生错误的时候采用子任务级别的重试。
对于查询优化器来说，何时采用哪一个全局索引也是基于代价计算的，目前索引回表查询是通过在计划上生成基础表和全局索引表的连接操作来实现的，代价模型也和一般查询相同。对有全局索引表的DML和查询操作很容易产生分布式查询和分布式事务，为了提升性能，在实现上做了很多细节优化，比如对于分布式查询，将任务的粒度从之前的分区级提升到节点级，以便减少RPC的次数。
4. 负载均衡
在负载均衡方面，2.0版本丰富了均衡策略。租户内的负载均衡让该租户上的工作负载能比较平均地分配在租户的多个节点上，对于数据装载和分析型的查询，可以有效地减少响应时间。此外，还可以设置租户间的亲和关系，实现将负载高峰出现时段相同的租户分布在不同节点上，峰值时段不同的租户分布在同一个节点上，充分地利用系统资源。除了提供给用户可配置的手段，负载均衡还结合CPU、Mem、存储等资源的使用情况，在负载差异超过阈值的时候，自动平衡节点间的负载，简化运维操作。
数据持续可用
在9月20日下午蚂蚁金服副CTO胡喜的主题演讲中，演示了OceanBase三地五中心城市级故障无损容灾方案，树立了金融核心业务高可用新标杆。
这一场三地五中心方案的现场演示是我们1.4版本支持的特性。在提升数据可用性方面，2.0版本也有了显著改进，索引实时生效、闪回查询、在线分区分裂，这三个新特性，每一个都解决了业务使用中的痛点。
1. 索引实时生效
了解OceanBase之前版本的同学都知道，索引生效和每日合并是强绑定的，普通索引的生效要经过一次每日合并，唯一索引要经过两次。有的时候，索引创建失败了，业务还不知道，造成了很大的困扰。
在2.0版本中，索引创建和每日合并解耦，索引基于数据的一个全局快照创建，再合并后续的变更，创建成功即可使用。如果出现错误，也能及时给用户反馈，提升了用户体验。通过先在一个数据副本上创建索引，成功以后再通过复制的方式生成其他的副本，避免同时在多个副本上创建索引造成的系统资源浪费。支持创建全局唯一索引，进行全局唯一性检查；在数据一致性校验方面，和之前的版本一样，会检查索引和表中的相同列的一致性。
2. 闪回查询
闪回查询功能，可以指定查询某个历史时间点的数据，对减少用户误操作造成的影响很有帮助。假如用户不小心删除了一些有价值的数据，可以通过指定删除之前的时间点来查询之前的数据。
在OceanBase的实现中，内存中的修改记录原本就是多版本的。为了支持闪回查询，要求转储到外存中的数据也要保留多个版本。至于保留多长时间范围内的版本，用户可以根据自己的需要进行配置，每一个表都可以按需单独配置。为了减少多版本转储对存储的压力，存储层也将数据编码和通用压缩应用在转储上，有效地减少存储消耗。同时，在执行查询语句时，如果指定了快照版本号，查询也可以在从副本执行，分担主副本节点的压力。
3. 在线分区分裂
另外一个提高数据可用性的功能是在线分区分裂，该功能对系统扩容很有帮助。在业务早期设计表的时候，对未来的增量很有可能预估不足，所以业务发展起来以后，就需要把单个分区再拆分，分成多个分区，再用多台服务器来服务这些分裂出来的分区，达到系统扩容的目的。
如果需要拆表的业务不能停服务，拆分操作就需要在线完成。在2.0版本中，分区分裂分成两个步骤，逻辑拆分和物理拆分，逻辑拆分是在表模式上把单个分区变成多个分区，完成表的元信息更新。物理拆分是把原先单个分区中的数据移动到新生成的分区中去。逻辑拆分在用户的DDL语句返回的时候就完成了，物理拆分是后台运行的。在物理拆分没有最终完成前，仍然会用到之前分区的数据。
在分区分裂的过程中，也控制了存储空间的使用，旧分区某一个宏块的数据全部被转移到新分区了，该宏块空间就被回收了。
在分布式系统中，分区大小对负载均衡、副本迁移、复制都有影响，把分区控制在较小的规格是有价值的。在线下OceanBase 2.0测试集群中，单个节点能够服务百万个分区；线上生产系统单节点服务十万个分区。满足分区拆分以及云环境下对单节点分区服务能力的要求。
可运维性增强
分布式数据库相对于单机数据库，无论是部署还是运维都要复杂一些，所以提高系统的可运维性也是2.0版本的一个重要目标。今天主要讲三个方面：DB Replay功能、在线升级以及新运维管控平台OCP2.0。
1. DB Replay
DB Replay是一个很有用的功能，一方面可以降低系统升级的风险，另一方面也可以用来做压测，保障大促。DB Replay主要分成三个部分：线上流量抓取，要求不能影响线上系统的服务能力；第二部分是流量分析，因为真实系统的流量非常大，抓取的数据量也很大，对分析的性能要求高，同时为了更接近抓取时的Session并发情况，在并发语句相关性分析上，粒度是行级而不是同类产品通常采用的表级；第三个部分是流量回放，保持和线上系统同样的会话之间的关系，并且可以通过调整语句之间的时间间隔来放大或者缩小对系统的压力，达到压测的目的。
2. 在线升级
作为长期支持核心业务的数据库系统，对升级的要求就是平滑、可灰度、可回滚。版本之间的数据格式是兼容的，新版本的程序能理解老版本的数据。同时通过可用区轮转升级，可以做到在线升级；在升级的过程中可以灰度切流验证，在出现异常的情况下可以回滚，不会对系统造成严重影响。
3. 新版云管控平台
数据库运维管理一直就不是一件容易的事情，对于分布式数据库更是如此。“工欲善其事、必先利其器”。OCP（Open Cloud Platform）2.0就是一款专门用来管理OceanBase数据库集群的管控平台，通过OCP平台，可以一键安装、部署、升级OceanBase集群，监控集群的运行状态，创建和维护运维任务。
相对于1.0版本，2.0版本进行了架构上的改造，提升了服务的可用性，去除了对HBase、JStorm等外部组件的依赖，减少了最小化部署对服务器资源的消耗，从原先的3台物理服务器到2个Docker，非常适合对成本敏感的专有云客户。同时提供SDK供第三方定制管控平台。在服务能力方面，OCP集群能够动态扩展，每秒能够响应百万次的http请求，充分满足运维需要。
性价比提升
针对性能，我们主要做了两方面的工作：提交协议的优化和工程实现层面的优化。提交协议优化指的是对分布式事务二阶段提交协议的优化，在这一方面，目前在申请相关的专利，这里暂时不展开。在工程实现优化方面，我们做了大量细致的工作，包括内存分配、临界区、数据类型转换等。在降低存储成本方面，通过对静态数据进行编码，有效地减少了存储使用。通过这一系列的改进，在OLTP场景的实际应用中，2.0版本相对于1.4版本，性能提升了50%以上，存储下降30%。
兼容性提升
最后说说2.0版本的兼容性，我们花很大的力气做兼容性，就是要减少数据库迁移造成的业务系统改造，降低迁移成本，同时使得业务数据库设计人员、开发人员、数据库管理员原先积累的知识和经验能够在新系统中复用。
1. 两种兼容模式
在1.x版本中，我们主要做的是MySQL兼容。2.0版本支持两种兼容模式：MySQL和Oracle，目前Oracle兼容还比较有限，不久之后会有一个显著的提升。同一个集群中的多个租户，可以采用不同的兼容模式，在租户创建的时候指定，后续不能更改。对兼容性的要求，不仅仅是语法层面的兼容，还有语义方面、异常情况下的行为、并发行为、甚至于性能，都可以看作兼容性表现的一部分。
试想一下，同样的语句，新系统的响应时间是原系统的10倍，哪怕是语法兼容做得再好，也根本无法满足业务要求，又有什么用呢？
2. 存储过程功能
在功能方面，2.0版本实现了一个标志性新特性—存储过程。我们实现存储过程，有两个方面的目的：一个是兼容性，我们了解到，在传统行业中还是有不少系统是基于存储过程实现的。通过支持存储过程可以显著降低这部分系统的迁移成本。另外一个是高可用，通过使用存储过程，可以显著减少业务系统和数据库服务器之间的交互，如果业务流程的几十条、几百条SQL语句通过一个存储过程来实现，即便出现跨城的业务对数据库的调用，也不会对用户体验有明显的影响，系统的容灾将会更容易实现，稳定性也会更高。在为数不多的原生分布式数据库产品中，OceanBase是第一款支持存储过程功能的。
存储过程也支持MySQL、Oracle两种模式。如果业务不想让数据库来管理代码，也可以采用匿名块的使用方式，既有开发灵活性，又能获得存储过程带来的好处。存储过程采用LLVM编译执行，效率比解释执行高；支持基本调试功能，方便对大规模存储过程的开发和调试。
OceanBase 2.0的第一个“双十一”
作为阿里系的产品，不经过“双十一”的考验是不完整的。今年是天猫的第十个“双十一”，也是OceanBase 2.0经历的第一个“双十一”。
虽然刚刚出道，也要堪当大任。2.0版本将要承担一大部分支付宝的核心业务，同时，借助于2.0的在线分区分裂技术和全局索引功能，业务核心表要实现拆分，从非分区表拆成若干个分区表。
今年大促的峰值流量预计会大幅增加，但数据库服务器的成本不能增加，要靠提升数据库性能来帮助实现“零新增成本大促”这个目标。
听到这里，大家应该明白了，2.0版本所做的技术创新和产品改进，都来自于业务的真实需求，也会很快接受业务的检验。这是推动OceanBase数据库不断向前发展的原动力，也是OceanBase区别与市场同类产品的最大不同。我们输出到外部市场的产品都是经过内部业务严格检验过的，每年的“双十一”大促都是对OceanBase数据库独一无二的压力测试。
最后，以OceanBase 2.0相关的几个数字来作为结尾：
“1”
第一个支持存储过程的原生分布式数据库系统
“30｜50”
存储减少30%，性能提升50%
“100万”
单台服务器的分区服务能力达到100万个
“200万”
单个租户GTS服务能力达到每秒200万次
