数据持续可用
在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编译执行，效率比解释执行高；支持基本调试功能，方便对大规模存储过程的开发和调试。
