关于数据库:分享两年两度升级数据库我们经历了什么

本文来自社区分享，仅限交换探讨。原文作者：陈雄军，上海芯繁荣供应链科技有限公司运维负责人，负责团体数据库、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 数据库越来越弱小。