分享：两年两度升级数据库，我们经历了什么

本文来自社区分享，仅限交流探讨。原文作者：陈雄军，上海芯昌盛供应链科技有限公司运维负责人，负责集团数据库、IT 资产等运维管理工作。拥有多年数据库运维经验，负责集团 MySQL、MongoDB、SQL Server、OceanBase 等数据库的运维工作。

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

一、企业背景

上海芯昌盛供应链科技有限公司，是一家国际供应链管理服务公司，公司业务包括仓储托管、一件代发、定制包装、质量检验、协助选品、退货签收 &查验、国际货物运输代理等。目前已与多家知名电商平台合作，包括 Shopee、Wish、Tiktok、唯品会等。

二、业务背景

随着近几年公司的快速发展，业务所产生的数据越来越多，之前一直使用的 MySQL 数据库已经无法支撑业务的快速增长，每天产生的车辆运行轨迹数据、订单物流状态等数据非常庞大，存储在 MySQL 上已经出现明显问题：

• 单表数据量过大，查询出现明显的性能下降，很多稍微复杂一些的查询就直接卡死；

• MySQL 高可用能力差，我们只用了 MySQL 的主从，主节点出现故障，切换到从节点经常需要补数据；

• 随着数据量越来越大，MySQL 这类单体数据库很难实现快速的扩展，只能通过增加主机的配置，成本太高；

• MySQL 做了分库分表之后，带来的运维复杂度和维护成本也随之提高。

基于以上几点，我们不得不寻求更好的解决方案。

三、数据库选型

2020 年，当时的 OceanBase 还没有开源，我们对业务进行数据库选型，因为业务原本使用的主要是 MySQL 数据库，所以在选型中，以兼容 MySQL 协议为首选条件，然后考察数据库的查询性能、扩展性以及高可用能力，另外开源也是一个重要条件。当时经过一段时间的调研，我们发现市面上有几款比较适合的数据库产品，但是考虑到未来国产化需求，当时我们选择了 TiDB 作为我们的选型目标。

选择 TiDB 数据库主要有以下几点满足我们当前需求：

• 基本完全兼容 MySQL 协议，业务从 MySQL 迁移到 TiDB 基本不需要修改；

• TiDB 作为分布式数据库，可以承载更大的数据量；

• 迁移到 TiDB 之后，相比 MySQL 查询性能也有一定的提升；

但是，随着我们使用的时间越来越久，问题也逐渐凸显出来。

• TiDB 上有的 SQL 查询时间有时候会突然变的很长，影响业务使用体感；

• 对集群进行扩容比较麻烦，扩容操作经常出现不成功现象；

• 另外 TiDB 整体组件还是比较多，维护起来也有一定难度，PD 存在单节点瓶颈等。

不过，这些都还能够接受。

直到 2021 年 10 月份，一次偶然机会，我参加了一个技术大会，在大会上了解到 OceanBase 数据库，作为淘宝、支付宝内部一直在用，并且完全自主研发的分布式数据库，已经运行了好多年，这确实激发了我很强的好奇心。OceanBase 数据库同样在扩展性、性能及高可用方面非常优秀，因此我再次对 TiDB 和 OceanBase 数据库进行了对比，当时使用的是 OceanBase 3.1.2 的版本，TiDB 使用的是 5.0.1 版本。

基于以上几点，我们最终选择将数据库切换到 OceanBase 上，但是因为一些其他原因，这次切换直到 2022 年 11 月份才完成。

四、迁移测试

在最终决定用 OceanBase 数据库替换掉 TiDB 之后，我们便开启了完成整的测试，以及迁移方案的确定。测试主要包括兼容性测试、性能测试、扩展性测试、高可用测试等。

• 兼容性方面：因为 OceanBase 也是完全兼容 MySQL5.7 的语法，我们在测试中发现，基本不需要任何的修改，就可以完全迁移到 OceanBase，业务代码所使用的连接驱动直接用 MySQL 官方驱动就可以；

• 性能方面：最开始我们在使用 OceanBase 时，并没有注意到需要做分区表，所以在测试过程中，发现 SQL 查询的性能反而比较差。后来经过 OceanBase 的工程师指导，我们做了些优化，包括将表创建成分区表，并创建了联合索引之后，性能有了很大提升。

• 扩展性方面：我们尝试给集群中去添加服务器，发现只需要在图形化 OCP 管理平台上简单的操作下，就可以将新机器加入到集群中，非常方便。

• 高可用方面：我们上线的时候使用 OceanBase 3.X 版本，高可用方面我们尝试将一台服务器关掉，发现基本对集群没有影响，只有个别请求会失败，不过在几秒之后重新尝试就能成功，这也应证了官方所说的 RPO=0，RTO < 30s 的指标。

• 数据迁移方面，我们最终由研发人员写了一套工具，不断从 TiDB 集群 select 数据，然后在 OceanBase 数据库中 insert 写入。经过一段时间的同步，两边数据基本上差不多之后，我们找了一个业务低谷时间段，将数据库集群进行了切换。在切换之前我们已经做了充分准备，包括业务连接用的用户账号、连接性、功能性测试等。

五、性能优化

上面提到，最开始我们在使用 OceanBase 时，并没有对表进行分区操作。所以在开始测试时，发现查询性能比较差，在测试环境中，有一张表的数据量大概 8000 多万行，在执行如下查询的时候，用了将近 1min57s。

对此，我们明显感觉没有发挥出 OceanBase 的性能优势，咨询了 OceanBase 的工程师。根据他们的优化方式进行排查，发现我们一方面没有对表进行分区，另一方面索引创建也有一些可以优化的地方。

因此，我们对表重新创建了分区，使用 createtime 字段作为一级分区，用 id 做二级分区：

partition by range(UNIX_TIMESTAMP(createtime)) subpartition by key(id) subpartition template ( subpartition p0, subpartition p1, subpartition p2, subpartition p3, subpartition p4, subpartition p5) (partition p202205 values less than (1654012800), partition p202206 values less than (1656604800), partition p202207 values less than (1659283200), partition p202208 values less than (1661961600), partition p202209 values less than (1664553600), partition p202210 values less than (1667232000), partition p202211 values less than (1669824000), partition p202212 values less than (1672502400))

在对表执行了分区之后，再次执行相同的操作，发现速度非常快，40ms 就返回了结果，这个大超我们预期，比 MySQL 快非常多，而且比 TiDB 也要快很多。

所以这里在使用 OceanBase 的时候一定要注意，因为这种分布式架构，只有对表做了分区之后，数据才会打散到所有的节点上，在做查询计算的时候，才能发挥每个节点的能力。并且在做了分区之后，我对集群进行扩容，集群在新增了服务器之后，数据会以分区的粒度，自动负载均衡到新的节点上，实现真正了线性扩展。

六、取得收益

• 数据库服务更加稳定：在 2023 年 1 月份的时候，OceanBase 数据库集群中有一台服务器内存条发生了故障，导致机器不可用，当时是凌晨 0 点多，但是查看业务，并没有发生任何错误请求，因为我们是跨境电商业务，晚上也会有很多业务请求，而我们却没有收到任何业务异常的反馈。这个内存条，到第二天中午更换完成，整个过程我们业务都是无感的，这让我对 OceanBase 数据库好感度倍升；

• 数据压缩能力更强：之前在 TiDB 数据库上，我们给每台 TiKV 服务器配置了 10T 的磁盘，但是在迁移到 OceanBase 之前，磁盘空间已经接近告警阈值了，而我们在迁移到 OceanBase 数据库上之后，发现每台机器的磁盘使用率只有 2T 左右，所以看下来，OceanBase 数据库的数据压缩能力要好很多。

• 运维成本更低：目前我们只用一套 OceanBase 数据库，就解决了之前需要维护多套 MySQL 主从的运维成本问题，并且高可用方面 OceanBase 原生具备，不需要人为过多干预，节点发生故障也会自动实现切换，我们可以有更多时间聚焦业务。

七、对产品的展望

目前 OceanBase 使用下来整体感觉还是很丝滑，不过个人觉得还是有些地方可以再优化些，例如 OceanBase 的错误日志目前还是比较难看懂，日志打印太多了，有用信息有时被淹没在日志里。

未来我们还将对 OceanBase 做更多的探索，当前我们的 AP 报表业务数据库用的是 SQL Server，OceanBase 具备 HTAP 的能力，一套集群可以同时支撑 TP 和 AP 查询，因此未来我们也计划将这个业务切换到 OceanBase 上。最后希望 OceanBase 数据库越来越强大。