关于数据库:分享软件全面国产化替代10款数据库TPCC测评哪家强

1次阅读

共计 2953 个字符，预计需要花费 8 分钟才能阅读完成。

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/

本文来自 OceanBase 社区分享，仅限交换探讨。原作者风华流沙，武汉西方赛思数据部总负责人

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

提起技术选型的起因，还要从咱们应用的开源操作系统 Centos 说起。因为 Centos 进行保护，让咱们不得不开始思考当国外软件忽然不提供服务后，咱们的业务该如何稳固进行。为防止后续相干事件对公司我的项目造成影响，咱们决定将所有软硬件都替换为国产计划。

在数据库层面，咱们正在应用的 MySQL 也须要替换为国产开源的产品。当然，替换起因不止这一点。咱们在应用 MySQL 的过程中，面临的一些痛点越来越难以解决。

痛点一：咱们以后的业务零碎波及大量 ETL 数据加工、解决，MySQL 8.0 的性能难以撑持，迫使咱们寻求一个性能体现更好的数据库。
痛点二：在大型项目中会应用到多套 MySQL 实例及分库分表架构，日常运维与治理十分繁冗。
痛点三：因为近期我的项目中的实时在线数据量十分大，一旦呈现节点宕机状况，就会波及业务零碎的稳固运行，甚至带来更为严重的结果，因而，寻找一款更为稳固牢靠的数据库势在必行。

基于上述痛点，咱们开始着手国产数据库的调研，从多个平台理解到，华为 OpenGuess、蚂蚁 OceanBase、腾讯 TDSQL、达梦数据库 DB8 在国内领有较好口碑，因而对这几款数据库产品进行测评，包含性能、兼容性、高可用个性等方面，旨在筛选出最适宜咱们需要的国产数据库。最后，咱们打算先在外部 OA 零碎的发票报销模块尝试新产品的适配，但通过一番产品调研后，理解到 OceanBase 不仅兼容 MySQL，也反对 HTAP 混合负载，其高可用能力甚至达到 RPO=0、RTO<8s，这些个性促使咱们决定正式测试、适配 OceanBase。下文具体介绍咱们对各数据库产品的测试过程及数据体现。

家喻户晓，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，考查其整体体现。

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

从测试数据能够看出：在并发 100 的状况下，OceanBase 4.0 能确保均匀响应工夫少于 3 秒，满足响应工夫要求，TPS 远高于 DM8。压测后果合乎业务的预期响应工夫，性能也满足需要，阐明业务可行。

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

咱们应用 3 台配置为 10GB 的服务器部署 1-1-1 3 节点集群环境，在测试环境下利用脚本，继续分批写入数据，每秒向数据库指定表插入 2000 条数据，查看 QPS 和表写入变动。在集群节点都在线的状况下 Kill 掉其中一个 OBServer 过程，察看脚本分时写入状况。咱们发现在宕机时，BI 查问依然失常，数据写入有短暂的明显降低，但大抵 3 秒写入就主动复原，能够证实 RTO<8s。OceanBase 的确具备高可用能力。

通过上述测试曾经表明 OceanBase 4.0 满足咱们的业务需要，那么它是否适宜咱们的业务呢？咱们在外部抉择了一个发票报销零碎进行可行性验证，验证过程次要是将业务数据从 MySQL 迁徙到 OceanBase 4.0，而后将业务流量切换到 OceanBase 上，运行一段时间察看理论状况。数据的迁徙次要应用 MySQLDump 将 MySQL 8.0 的数据离线导出，而后导入 OceanBase 4.0。切换后，对业务的各项性能和数据库的性能再次进行了验证，包含数据库备份复原及业务各功能模块，目前已稳固运行两个多月，还未发现有性能异样或性能问题，根本验证了 OceanBase 在后续我的项目中推广的可行性。

目前 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 社区越来越红火。

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/

正文完