我所在的武汉东方赛思软件股份有限公司是一家专注于大数据分析、大数据平台软件研发和服务的国家高新技术企业，我们的项目涉及卫生健康、智慧税务、数字政务、市场监管领域，帮助这些企业做好数字化转型。

提起技术选型的起因，还要从我们使用的开源操作系统 Centos说起。由于Centos停止维护，让我们不得不开始思考当国外软件突然不提供服务后，我们的业务该如何稳定进行。为避免后续相关事件对公司项目造成影响，我们决定将所有软硬件都替换为自研方案。

数据库替换背景

在数据库层面，我们正在使用的 MySQL 也需要替换为自研开源的产品。当然，替换原因不止这一点。我们在使用MySQL 的过程中，面临的一些痛点越来越难以解决。

• 痛点一：我们当前的业务系统涉及大量 ETL 数据加工、处理，MySQL 8.0 的性能难以支撑，迫使我们寻求一个性能表现更好的数据库。
• 痛点二：在大型项目中会使用到多套 MySQL 实例及分库分表架构，日常运维与管理非常繁杂。
• 痛点三：由于近期项目中的实时在线数据量非常大，一旦出现节点宕机情况，就会波及业务系统的稳定运行，甚至带来更为严重的后果，因此，寻找一款更为稳定可靠的数据库势在必行。

基于上述痛点，我们开始着手自研数据库的调研，从多个平台了解到，华为OpenGuess、蚂蚁OceanBase、腾讯TDSQL、达梦数据库DB8在国内拥有较好口碑，因此对这几款数据库产品进行测评，包括性能、兼容性、高可用特性等方面，旨在筛选出最适合我们需求的自研数据库。最初，我们计划先在内部 OA 系统的发票报销模块尝试新产品的适配，但经过一番产品调研后，了解到OceanBase不仅兼容MySQL，也支持HTAP混合负载，其高可用能力甚至达到 RPO=0、RTO<8s，这些特性促使我们决定正式测试、适配OceanBase。下文详细介绍我们对各数据库产品的测试过程及数据表现。

数据库产品测试对比

1、TPC-C 基准测试

众所周知，TPC-C 基准测试是衡量数据库整体性能的重要指标。因此，我们首先对 ​OpenGuess 3.0、OceanBase 4.0、TDSQL10.3、DB8等数据库进行了 TPC-C 基准测试，并与MySQL 8.0 的性能作比较。我们以商品销售交易业务为基础设计了 9 张表，并统一设置 TPC-C 的测评参数为10个仓库（数据体量）、10个终端（用户体量），来观察在无硬件资源瓶颈的情况下，各数据库在相同数据体量与用户体量的场景中，OLTP 能力哪家强，测试数据如下图所示。

由测试数据可以看出，在开源软件中，OceanBase 4.0 的表现最好，是MySQL 8.0 的1.2倍左右。​因此，在接下来的测试中围绕OceanBase 4.0，考察其整体表现。

2、场景压测

完成TPC-C的性能测试之后，我们基于当前的一个项目——某省编办环境做数据库产品的场景压测。由于该项目使用的是 DM8 ，因此将 OceanBase 4.0 和 DM8 进行压测对比​，我们​选取了机构修改、用编申请、人员管理三个典型场景，测试环境规格是基于内存 30GB 的单节点环境，通过 web 节点向数据库写入并查询数据，部署 jmeter 进行压测，总共涉及 80+段 SQL，涵盖插入、删除、更新、清单查询、统计查询。测试数据如下图所示。

从测试数据可以看出：在并发 100 的情况下，OceanBase 4.0 能确保平均响应时间少于 3 秒，满足响应时间要求，TPS 远高于 DM8。压测结果符合业务的预期响应时间，性能也满足需求，说明业务可行。

3、高可用测试

为验证在集群节点宕机时 OceanBase 4.0 的表现，我们通过模拟故障的方式，验证在单节点宕机情况下数据库是否还能继续提供服务，以及恢复正常服务要多久。

我们使用 3 台配置为10GB 的服务器部署 1-1-1 3节点集群环境，在测试环境下利用脚本，持续分批写入数据​，每秒向数据库指定表插入 2000 条数据，查看 QPS 和表写入变化。在集群节点都在线的情况下 Kill 掉其中一个 OBServer 进程，观察脚本分时写入情况。我们发现在宕机时，BI 查询仍然正常，数据写入有短暂的明显降低，但大致3秒写入就自动恢复，可以证实 RTO<8s。 OceanBase 确实具备高可用能力。

4、发票报销系统可行性验证

通过上述测试已经表明 OceanBase 4.0 满足我们的业务需求，那么它是否适合我们的业务呢？我们在内部选择了一个发票报销系统进行可行性验证，验证过程主要是将业务数据从MySQL迁移到OceanBase 4.0，然后将业务流量切换到OceanBase上，运行一段时间观察实际情况。数据的迁移主要使用 MySQLDump 将 MySQL 8.0 的数据离线导出，然后导入 OceanBase 4.0。切换后，对业务的各项功能和数据库的功能再次进行了验证，包括数据库备份恢复及业务各功能模块，目前已稳定运行两个多月，还未发现有功能异常或性能问题，基本验证了OceanBase在后续项目中推广的可行性。

5、OLAP性能对比

目前 OceanBase 4.0 已经在我们 OA 系统的发票报销系统稳定运行两个多月，后续我们计划将整个OA系统都在 OceanBase 4.0 上线，同时也在进一步测试 OceanBase 4.0 的 AP 能力。我们选取了基于往期项目中的经济户口表改写而成的 10 条典型统计类 SQL，主要可以反映数据的批处理能力以及复杂查询性能。由于我们多数业务使用Oracle支撑，因此将 Oracle 与 OceanBase 4.0 进行对比。本次测试两个环境分别使用一台配置为 125GB、56核CPU 的机器，硬件条件相同。

通过测试发现，在查询方面，OceanBase 4.0 的实测数据大幅优于 Oracle，在统计查询类 SQL 中 ，Oracle 耗时分别是 2s、7s、9s，OceanBase 4.0 均在 1s 内，极大地超出了我们预期。

经验总结

以上是我们在数据库选型道路上的尝试过程，总体而言已经满足了我们的业务需求，后续会进行更多的实践测试，在测试过程中，我们遇到了两个问题，在此也分享出来供大家参考。

• 第一，在数据迁移过程中我们发现 ​OceanBase 4.0 对 MySQL 8.0 的视图并不完全兼容，视图迁移失败，使用 MySQL 5.7 时视图迁移成功。由此可知，OceanBase 4.0 对 MySQL 5.7 兼容性更好，希望后续对MySQL8.0的支持能够更进一步。
• 第二，在与 Oracle 的压测对比过程中，我们发现OceanBase 4.0 暂不支持 Oracle 的递归查询语法，后续我们通过定制函数解决了该问题，目前OceanBase已支持MySQL8.0的递归语法。

希望后续我们的业务 BI 系统和后台分析系统可以在 OceanBase 中实现所有数据的一站式处理，优化内部数据架构。同时我们也希望 OceanBase 社区可以开放更丰富多元的社区用户奖励机制，鼓励更多的用户参与到社区的建设中，最后希望 OceanBase 社区越来越红火。