业务背景
高德，DAU已在亿级，时时刻刻都持续不断地产生着庞大的数据。随着数据量的迅猛增长，对现有的业务数据存储能力构成日益严峻的挑战。
以我所在部门中的某一大型服务为例，其存储在XDB中的数据量往往达到数百TB之巨，且TPS（包括QPS）维持在万级水平。如何高效地管理这些数据，并在保证性能的同时降低未来的扩容、迁移以及长期存储成本，已成为我们急需解决的首要问题。同时，随着高德在做本地服务上越来越深入，如何在业务发展期提前技术布局，保障现在和未来服务可用性和稳定性，以应对未来业务的飞速成长（参考高德打车的业务成长速度），也成为我们的重点关注之处。
综合我们已知的隐患，和在技术上提前布局未来的需求，我们需要解决以下几个问题：
- 透明可扩展性、降低维护成本。如何让数据库能跟随业务的发展而增长容量，可依据业务量动态扩缩容（在业务初期使用小规格的存储，随着业务发展可通过增加机器横向扩展），而减少数据迁移带来的技术风险和迁移成本？
- 节约成本，保持性能。面对大体量的业务（如存储TB级别），如何降低存储成本，同时又保持性能在可接受范围内（比如用ODPS存储TB数据成本低，但读写时间太长，无法做在线业务）？
- 可用性、稳定性、容灾能力。对于DAU过亿的应用，任何故障都会被无限放大，因此服务的稳定性至关重要，如何提高存储的稳定性，提升服务的可用性和稳定性（同城及跨地域容灾能力）？
- 强一致性。面对结算财务类数据时，如何保证强一致性，保障数据不丢失，即使主节点挂掉，主从切换，能保证已写入主节点的数据不会丢失。
- 兼容性、降低改造成本。支持MySQL（XDB）协议，可实现存储平滑升级，降低业务系统的代码改造成本，最好的情况是业务系统不需要更改对存储系统操作的SQL就可以实现改造升级。
面对以上的问题，我们需要达到以下六个目标。
- 提升扩展性，提升数据库弹性扩缩容的能力，使存储横向扩展对上层系统透明，降低数据迁移的风险。
- 可进行数据压缩和数据共享，减少数据占用的存储容量，降低费用成本。
- 提升存储稳定性，使系统拥有高可用和容灾能力，能拥有应对机房级别甚至城市级别的容灾能力。
- 能提供强一致的存储保证，对于结算财务类的数据，可保障较高的一致性，而非用最终一致性的妥协换取其他方面的能力。
- 兼容原有存储（XDB）的协议，至少是大部分常用协议，可极大减少业务系统的改造成本，实现业务系统所用存储的平滑升级。
- 要支持较高并发读写能力。
为了实现以上的预定目标，对市面上比较流行数据库的进行研究和对比，以便选出更适合我们场景的数据库。
数据库方案选型对比
单机版的数据库当然无法满足我们现在的需求，而对于关系型数据库的三个发展方向： Sharding on MySQL 、NewSQL 和Cloud Native DB ，都各有各的应用场景，在选择前先简要介绍下三个方向的技术。
Sharding on MySQL 在应用侧或代理层做分片来管理多个MySQL物理库，来解决MySQL单机容量和性能不足的问题。我们正在使用的TDDL就是该架构，虽然计算存储资源可扩展，但在扩展和数据迁移时，业务系统层面需要做大量的改造和业务数据的灰度，为了保证业务不停机会产生大量的改造成本和数据迁移的风险。
NewSQL 数据库，在国内以TiDB和OceanBase这类原生支持分布式的关系型数据库为代表，主要也是为了解决MySQL的问题，和Sharding on MySQL不同的是，NewSQL将分片功能作为数据库的一部分来实现，并提供了动态扩缩容的能力，且对上层业务透明，具备透明可扩展性。
Cloud Native DB（云原生数据库）在国内以PolarDB为代表，具备池化的资源，也可以实现存储资源的动态扩缩容，其一般采用主备方式来实现高可用，同时其扩容和主备探活等功能需要大量依赖外部系统。
为了解决现有问题，减少开发和维护成本，我们选择了NewSQL和Cloud Native DB作为选型方向，并对代表数据库TiDB、OceanBase和PolarDB进行简要对比。
在对比TiDB、OceanBase和PolarDB前，先介绍下其分别采用的架构知识作为补充。TiDB、OceanBase采用的Shard-nothing架构的每个节点有独立计算和存储功能，且节点之间不共享数据。PolarDB采用的Shared-Storage（即 Shared-disk）架构是在存储层做了统一和共享，但计算节点是独立节点。
选型对比
经过多角度的考虑和平衡，我们最终选择了OceanBase作为数据库升级的目标，下面详细介绍选择OceanBase的原因。
原因一：强一致性保障。OceanBase基于Paxos一致性协议实现数据多副本存储，多数据中心的数据副本同步写入，可以保证数据的强一致性，这样在一个副本挂掉后，其他节点有完整的数据。
原因二：极致高可用。OceanBase采用无共享的多副本架构，系统没有单点障碍，保证系统持续可用。支持两地三中心和三地五中心部署，对于要求CP的结算类业务来说，可保障数据的城市级容灾。
原因三：透明可扩展性。OceanBase是可以动态扩容的，扩容后分区表的数据会自动均衡到新节点上，对上层业务透明，节省迁移成本。在业务高速发展时，数据库的扩容对业务系统透明。
原因四：稳定性。OceanBase可实现业务连续不间断地服务。如果某个节点出现异常，可以自动剔除此服务节点，该节点对应的数据有多个其他副本，对应的数据服务也由其他节点提供。甚至当某个数据中心出现异常，OceanBase可以在短时间内将服务节点切换到其他数据中。
原因五：节省存储成本。OceanBase存储具有高度压缩的能力，数据可以压缩到原有数据到三分之一，对于存储量大的业务会极大降低存储成本。并且OceanBase的租户级别资源隔离，可以多租户共享集群冗余资源，减少资源的预置，降低费用成本。
原因六：性能强劲。OceanBase作为准内存数据库，采用LSM-Tree存储，增量数据操作内存，减少随机写，读写性能超传统关系型数据库，并且OceanBase的TPC-C测试打破了世界纪录。
原因七：兼容性、降低改造成本。OceanBase也支持MySQL协议，可以直接使用MySQL驱动访问，基本上可以把它当成分布式的MySQL使用。
选定OceanBase后，我们就要制定业务方案并迁移。这要求我们对OceanBase的工作原理有清晰的认识。
业务适配与迁移方案
业务方案
我们从OceanBase的工作原理与架构出发，分析并制定最合适的业务方案。
OceanBase数据库采用 Shared-Nothing 架构，各节点之间完全对等，每个节点都有自己的 SQL 引擎、存储引擎，运行在普通PC服务器组成的集群上，具备高可用、可扩展、高性能、低成本、云原生等核心特性。其中，高可用、可扩展的保证主要依赖于其整体架构和OBProxy、OBServer、GTS、RootService等服务，高性能、低成本主要源于其存储引擎。下面一一展开介绍。
OceanBase整体架构
下图是OceanBase的简要架构，基于此介绍OceanBase高可用、可扩展的实现原理。
首先，OBProxy、OBServer、GTS、RootService保证了OceanBase的高可用。
- OBProxy。代理上层应用的请SQL并转发到指定的OBServer，是没有持久化状态到，其工作依赖的所有数据库信息都来自于对数据库服务的访问，因此，OBProxy故障不会导致数据丢失。OBProxy的选择和摘除需由负载均衡组件来决定。云服务的OceanBase不需要用户管理。
- OBServer。OceanBase集群的组成节点（每个节点功能对等，可以比拟TDDL下的XDB物理分库），其上分布着以分区为单位的数据。以Zone方式将OBServer分组，一个Zone有完整的数据副本。同一分区的数据多个副本散落在多个Zone里。其中只有一个副本接收修改操作，叫主副本（Leader），其他副本叫从副本（Follower）。通过Multi-Paxos协议保证副本间数据的一致。并通过Multi-Paxos进行选主操作。
- GTS。GTS用于提供全局时间戳服务。该服务也是高可用的，通过特殊分区保持三个副本，为租户内执行的所有事务提供事务的读取快照版本和提交版本，保证全局的事务顺序。OceanBase 数据库使用与分区副本一致的方案保证全局时间戳服务的可靠性与可用性。
- RootService。相当于OceanBase集群的总控，其也是通过Paxos协议实现的高可用和选举，并可指定其副本数量。RootService通过监听OBServer汇报的心跳包来判断OBServer的状态，并对OBServer活跃或摘除状态的控制，以及其存储的分区副本数据的迁移。
其次，可扩展的保证主要是Zone。OceanBase会将分区表的多个分区均匀分散在每个Zone的所有OBServer上。扩容时只需要为其增加资源节点（在集群维度添加），通过修改租户的资源规格的方式可将资源分配给指定租户。新分配的资源会形成新的OBServer。然后，集群的RootService会调度分区副本在同一Zone内进行迁移，直到各OBServer负载差值达到最小。此外，主Zone的各个分区主副本也会在每个OBServer上进行自动均衡，避免主副本的分配倾斜导致部分OBServer的更新负载过大。
此处，还会涉及一个问题：使用Paxos必然会引入脑裂，那如何避免三地五中心的五个Zone副本在其中一个故障时产生脑裂呢？
为避免极端情况下会产生脑裂的问题。比如SH-1，SH-2为一个网络分区A，HZ-1，HZ-2，SZ-1为一个网络分区B，且SH-1为主时，分区B可能会产生新的主Zone来负责所有的分区主副本。在OceanBase中使用租约的方式来避免脑裂，如果租约的序列号是每个节点自增的话，可能会导致节点序列号很高但日志较晚的情况，最终导致服务不可用。不过OceanBase的选举服务会通过从GTS获取最新的时间戳，保证了新旧Leader的租约是不重叠的，并且新Leader能够保证GTS提供的时间戳不回退。这样就可以保证在同一租约里只有一个有效的主副本 ，避免了脑裂的问题。
需要注意的是，GTS作为选举依赖的关键服务，其高可用性影响了整个OceanBase集群的高可用性。
OceanBase存储引擎
OceanBase的高性能主要源于其存储引擎采用了基于 LSM-Tree 的架构，把基线数据和增量数据分别保存在磁盘（SSTable）和内存（MemTable）中，具备读写分离的特点。对数据的修改都是增量数据，日志顺序写、数据写内存，因此， DML 基本是内存操作，性能非常高。读的时候，数据可能会在内存里有更新过的版本，在持久化存储里有基线版本，需要把两个版本进行合并，获得一个最新版本。
OceanBase的增量数据是写到内存memtable中的，这也是LSM-Tree的结构特性所决定，天然为优化写性能而设计的。但如果读数据时，就需要聚合增量的MEMTable和磁盘上的数据来提供，而磁盘上分级的SSTable读会增大延时。因此，OceanBase在内存中做了RowCache、BlockCache等缓存手段减少直接读磁盘的操作。同时OceanBase推荐使用大内存的规格配置。一方面用于存储更多的增量数据（MEMTable更大），另一方面为更大的内存做数据的缓存。
OceanBase对RowCache构建了布隆过滤器，并对布隆过滤器进行缓存。OLTP 业务大部分操作为小查询，通过小查询优化避免了传统数据库解析整个数据块的开销，达到了接近内存数据库的性能。
当内存的增量数据达到一定规模时，会触发增量数据和基线数据的合并，把增量数据落盘。同时。每天晚上的空闲时刻，系统也会启动每日合并。另外，由于基线是只读数据，而且内部采用连续存储的方式，OceanBase可以根据不同特点的数据采用不同的压缩算法，既能做到高压缩比，又不影响查询性能，大大降低了成本。
OceanBase的迁移架构
为了保障服务数据的平滑迁移，我们选择了通过平台型工具（OceanBase的迁移服务）进行业务原有数据的增全量迁移，下面继续介绍下OB的迁移服务架构，让大家有个基础的认识。
OMS（OceanBase的迁移服务）用于做数据增全量迁移，并且，其支持异构数据的迁移如从MySQL迁移到OceanBase。OMS的主要功能是通过订阅源库的Binlog并将其存储在OMS的Store中，给下游提供订阅来完成源库数据的迁移。而全量数据是需要从原库查询并同步的，订阅binlog的方式只适合增量数据同步。而且迁移服务在迁移时支持结构同步、全量数据同步、增量数据同步、数据校验及反向同步等功能，可实现两端数据库的双向同步。
除了数据迁移功能外，OMS还支持数据订阅，数据订阅是提供客户端使业务方自主处理和消费OceanBase的binlog，以实现自己个性化的需求，比如数据同步到Lindorm，ES等。
如下图所示为增全量的数据迁移和流程。
迁移方案
为了摸清阿里云上的OceanBase落地的套路，也为了积累关于使用新技术的经验。我们选择了影响较小、体量较小的业务——赔付业务系统试水，业务架构图如下。图中红框内部分即本次数据迁移时涉及的系统改造部分，使用Diamond做XDB和OB的数据源路由控制，通过OMS做数据迁移，并使用MAC进行迁移前后两份数据的核验。
我们最开始讨论迁移OceanBase时，它还没有上云。等到OceanBase上云后，我们就在阿里云申请了OceanBase的测网集群并进行了迁移核心功能（DDL和DML）的测试，以便提前发现并解决现有赔付业务系统在迁移时存在的兼容问题。幸运的是，赔付系统涉及的所有CRUD操作及创建表、删除表、修改表、增删索引操作都能正常执行，这样的结果也减少了迁移时的心理压力。
在核心业务SQL兼容问题测试通过后，我们开始着手对OceanBase集群进行压测，因为当时没发现较好的压测平台，所以是通过应用机器间接压测OceanBase测网集群的。
在正式使用OceanBase前，我们对它的性能进行了简单压测。因为手里没有专用的数据库压测工具，是通过应用程序的接口间接压测，也导致了压测的QPS偏低（后续我们会用frodo等专业工具再做一次压测，出具一份更专业的压测报告来全面体现OceanBase的读写性能）。具体压测请看下文。
我们先使用高德压测机对三台4核8G的应用进行压测，间接压测了8核32G的OceanBase数据库。在读3000QPS和写1500QPS下，OceanBase性能仍然较好，RT都在1ms以内，优秀的性能是毋庸置疑的。不过经过分析得出结论，由于OceanBase是准内存数据库，需要的内存较大，在内存中做了缓存并且有增量数据也是在内存中，容易产生热点数据，因此压测OceanBase变成了压测OceanBase的内存中数据，内存性能相比磁盘有千百倍差距，性能好也是理所当然的，就没再继续压测。
从压测数据可以看出，OceanBase的高性能一方面是来源于其内存数据，热点数据几乎都在内存中也就保证了OceanBase在大部分时间内的性能都是优秀的。但如果是比较冷门的数据访问时，可能会需要从磁盘上加载数据，也可能会需要访问到多层的SSTabel，而该请求的RT因测试数据较少，还暂未确定。
此外，我们也了解了携程使用OceanBase的经验：相对于MySQL，OceanBase方案读性能平均提升 2 倍，写性能平均提升 3 倍，性能提升明显；基于数据编码以及存储引擎自带多级压缩技术，使得 OceanBase 方案相比 MySQL 节省 2/3 存储资源，很大程度上降低了硬件成本。
从携程的使用性能截图（下图）可以看到，其OceanBase的读写RT都在1ms上下，和我们的压测结论相近。
完成功能验证和性能的基本验证后，我们就需要着手将赔付系统数据平滑迁移到OceanBase了。为了保证数据的平滑迁移并且线上服务不停机，当时我们考虑使用阿里的DTS平台，可以将原有存储在XDB中的存量数据全量迁移到OceanBase，并通过增量数据方式实现XDB数据向OceanBase的同步，来保证二者数据的一致。但经过深入了解后，我们发现DTS暂时只支持TDDL内的XDB实例数据迁移，不支持异构迁移。因此我们也就无法借助阿里的能力实现业务的快速迁移了。就有了我们后续和OceanBase一起做数据迁移和数据订阅的经历。
业务数据迁移方案演进
OceanBase侧提供OMS作为迁移服务来实现原有存储数据迁移，遗憾的是，OceanBase虽然支持MySQL迁移，但原生MySQL对阿里集团内普遍使用的TDDL方式的库访问模式并没有进行相关集成。此时，我们需要面对两个选择：
- 等待OMS实现适配，业务暂停上OceanBase；
- 先用其他方案绕过OMS，业务侧去保证数据一致，先上OceanBase来验证数据库核心能力。
最终我们选择了业务方（即我们自己）来实现数据的全量+增量同步，绕过OMS，先让业务上线写OceanBase，尽早暴露迁移OceanBase可能存在的问题。
那如果业务方来实现增全量同步时，应该怎么选择方案呢？是这样的，在DTS平台不可支持的情况下，我们了解了同期使用阿里云上OceanBase集群的闲鱼团队及阿里集团以前存量业务使用OceanBase。他们都是使用datax全量+业务侧增量双写方式实现了数据迁移。经过权衡，我们也决定选用该方式实现业务快速上线，尽早验证OceanBase的数据库功能。
确定方案后，我们便不再犹豫，从下图的两个方案（PlanA和PlanB）中选择了PlanB方案来迁移数据，通过Diamond配置来实现数据库的动态切换，使用MAC平台来对XDB和OceanBase数据进行离线校验。
你可能在想：
- PlanA的难点是什么，为什么不能等OMS准备妥当后再迁移呢？
- 此刻使用的OceanBase是怎样连接的，怎么没看到TDDL的身影呢，那业务侧是否要改造呢？
PlanA的难点在于流程和权限问题，因为如果要通过MySQL方式同步，那么需要申请生产环境数据库可用作迁移的账号密码，而这个流程具有高风险，且需要沟通和审批的人比较多，甚至到了高管级别，获批难度较大、获批时间难以预估。另外，即使账号审批下来，后续的迁移流程是否有其他问题（比如没有接口对外调用）也未可知。为了稳妥和效率，我们没有采用PlanA的方案。
我们也确实没有提到TDDL，也没有通过TDDL来访问OceanBase，而是通过MySQL驱动的方式通过账密来访问OceanBase的，此时需要将原TDDL的TDataSource换成其他的MySQL数据源来访问OceanBase。当然也会遇到直接使用账密带来的安全问题。最终，我们还是将直连OceanBase的方式改为了通过TDDL间连，避免账密的明文泄漏问题。
虽然我们的方案并非最优雅的数据迁移方案，却是我们当前经过多方面评估后认为的最合适方案。而我们期望的最优雅的方式是，让OceanBase能完美的与业务中间件平台等结合，避免业务方做大量的非业务相关的工作。
业务上线后是处在应用双写XDB和OceanBase的状态，并通过MAC在T+1时间验证历史所有数据的一致性，如果OceanBase有数据和XDB不一致的情况，再通过ODPS的方式重新同步全量数据到OceanBase，直到OceanBase数据稳定多日与XDB数据一致。
在迁移改造过程中还需要注意的是：
- 不可使用数据库自增ID，因为OceanBase和XDB自增ID不同可能会导致数据错乱，即使初始设置的完全一样。需要通过TDDL的自定义sequence来保证XDB和OceanBase两边数据主键的一致。
- 从写（双写XDB和OceanBase，指定了先写XDB，那么写OceanBase就是从写，反之一样）的库即使失败不可阻塞业务流程，从写的库随时都可以重新全量同步以使得数据与主写的库一致。
容灾演练
为了验证使用OceanBase的容灾能力，我们进行了跨机房的灾备演练（因OceanBase的云上集群现在还不支持跨地域部署，当前不支持跨地域容灾）、集群扩缩容、集群升级等操作。
灾备演练。进行灾备演练时，人为触发OceanBase的切主操作。在切主瞬间，出现了数据库连接的闪断，闪断当时的服务读写数据都失败了，不过秒级恢复了。需要关注的是：对于非用户触发的动作，都应有重试机制，保证在OceanBase切主等场景写失败时，能自动重试，避免丢失数据状态的情况。
集群扩缩容。对于集群可通过增删节点和存储空间扩容的方式进行，虽然OceanBase集群上支持扩容功能，但对于通过内部的公共账号登录申请的OceanBase集群，没有权限实施扩容，阿里云正在积极适配。而对于缩容，只能由OceanBase人员帮忙操作。因此可认为涉及集群扩缩容时，暂时需要联系OceanBase的技术支持人员。
集群升级。建议关闭集群自动升级功能，因为你不知道集群升级后，下游有哪些组件不兼容而导致业务停服的问题发生。由于我们涉及集群降配，降配的前提需要升级集群，因此在升级完集群后，OceanBase为我们业务配置的数据订阅服务LogProxy因版本不支持导致的下游消费binlog停止，幸好非核心业务，否则影响会较大。后经沟通了解到LogProxy只支持与其相同或更低的大版本的订阅，高版本无法支持，目前已升级至3.x版本，可支持订阅OceanBase的3.x及2.x的增量数据。
费用
第一期的试点业务——赔付系统上线后，我们对比了现有XDB和的费用账单，并经过与OceanBase人员的讨论后，认可的一致结论是：相同规格下，即同样算力和数据量存储，OceanBase的价格是XDB是2.46倍。
而我们了解到的，OceanBase在通过数据编码和压缩后，是具有较高压缩比的，正常业务一般压缩到原来的30%左右。而OceanBase的整体价格也是通过数据压缩取胜的。经过和OceanBase人员的换算，在XDB的规格为16核64G，存储使用6TB的情况下OceanBase需要8核32GB，存储只需要1.8TB，以此存储量（即拐点存储量在6TB左右）为基础继续增长则OceanBase的费用会越来越划算。
鉴于OceanBase作为HTAP模式的数据库，具备一定的OLAP能力并做了一定的性能优化，后续可以将Lindorm的数据迁移到OceanBase，用OceanBase代替Lindorm的部分角色。这样既能统一在线数据的存储，又能节Lindorm的使用费用。
总体可以看出，OceanBase的适用场景是大体量（在XDB的存储量超6TB）的业务，对于小体量业务可以和大体量业务同集群共享资源使用，但小体量单独使用OceanBase的集群的费用相对来说比XDB费用要高。
实践小结
由于OceanBase数据库刚刚上云，其他基础设施还未完善。因此我们作为云上的OceanBase系统首批使用用户之一，在使用过程中，OceanBase周边设施也与OceanBase人员一起共建，共同推进OceanBase生态通用解决方案的落地。
在测试过程中，我们主要遇到的问题是OceanBase数据库功能的兼容性验证、业务数据的平滑迁移与回切能力。在实践中，对于赔付系统内的读写等DML操作进行了比较全面的验证，并使用MySQL驱动的方式进行OceanBase的数据库访问，SQL运行良好，无兼容性问题。
我们评估了赔付系统的业务数据量和QPS等系统指标，提出暂时避开OMS体系，业务侧自己实现数据的全量同步和增量同步，并通过MAC系统来验证XDB和OceanBase的数据一致，通过将XDB和OceanBase数据同步到ODPS，然后在MAC上建立对账任务的方式进行核验，以及时发现不一致数据并排查原因。
业务应用系统内实现的XDB和OceanBase的同步双写（低频业务，后台业务性能问题权重不高），主写XDB，从写OceanBase。业务流程强依赖主写，对于从写，如果有操作失败的情况会通过sunfire的监控报警及时发现并修复。待两侧数据多日核验一致后，切换为主写OceanBase，从写XDB，并保持稽核能力和回切能力，以便OceanBase有异常时可快速切换到XDB。
云上OceanBase当前仍然存在的问题
第一，OceanBase线下部署可实现的三地五中心和两地三中心能力在云上暂时无法提供，只提供了一地三机房部署，容灾能力有所折扣，是因异地同步时的跨网络问题导致，OceanBase团队正在积极解决。
第二，云上的OceanBase有监控但无报警，因统一使用了集团的大账号申请，暂时还无权限自主配置报警，还需要OceanBase团队和阿里云团队进行内网平台对接的适配
第三，同样是因账号权限及角色问题，现在无法对云上的集群进行自助扩缩容，有紧急情况需要联系OceanBase处理，应急响应时间会延长。
第四，OceanBase的分区副本数据只支持最终一致，默认通过读写主副本才能实现强一致性。如果读从副本可能会存在数据不一致的情况。
第五，OceanBase在切主时会有闪断，造成连接短暂不可用，RTO为秒级。
第六，在进行OceanBase升级时需要考虑其周边工具的兼容问题，避免OceanBase集群升级后周边工具如LogProxy直接失效。
预期收益
第一，拥有了异地容灾能力，利用OceanBase的三地五中心的部署和强一致特性，业务可实现城市级别的容灾，保证数据不丢，极大提升了业务的稳定性。
第二，利用OceanBase的分布式特性，业务系统的数据存储具备了动态扩容的能力，业务无感知的平滑扩容，保证业务不停机。并节省了业务提量猛增后的数据库扩容和迁移成本，极大降低了数据库容量不足的风险。
第三，平滑迁移云原生的分布式关系型数据库OceanBase，为团队内推广使用云原生数据库积累了宝贵的经验。
第四，相比MySQL，OceanBase读性能平均提升2倍，写性能平均提升3倍。
OceanBase 现已支持 365天 免费试用，点击立即开启 >>