分享：集群吞吐量以 1 抵 5，车企 MySQL 八大痛点的解决方案

本文来自社区分享，仅限交流探讨。原文作者：李婵玲，某智能车企 DBA。欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/

最近一年，我们完成了从 MySQL 到 OceanBase 的替代过程，既降低了架构复杂度和存储成本，又提高了扩展性和吞吐量，而且再也不用担心数据不一致问题了。故而将我们遇到的痛点问题、解决方案、技术选型过程总结成此文，供大家参考。

一、业务增长凸显 MySQL 八大支撑瓶颈

相信很多企业都会因为业务快速发展，数据成指数级增长带来一些新的需求或系统瓶颈。我所在的国内某知名智能车企也面临这样的问题，特别是我们的业务监控数据和信号数据在近几年爆发式增长，我们过去使用的 MySQL 数据库越来越难以应对，主要体现为以下八个方面。

1. 性能瓶颈：单台服务器难以承受大规模数据和请求访问，导致数据库性能下降，只能通过部署多套集群解决。

2. 水平扩展困难：单集群容量达到瓶颈时，无法实现无缝扩展，需要停机维护，影响业务运行。

3. 数据一致性难以保证：多集群数据合并的时候，数据更新同步难度大，易出现数据不一致的情况。

4. 多活实现困难：多活场景下，无法保证业务双写。

5. 实效性差：多集群的跨节点 join 操作需要内存运算，或者大数据整合后提供，时效性无法保证。

6. 容易造成集群数据或流量倾斜。

7. 各集群之间数据调度麻烦。

8. 运维压力大：需要定期备份归档数据，排查数据问题。

为了解决上述八个问题，我们需要制定高效的数据库解决方案，于是开始了数据库的调研、选型、替换之旅。

二、分布式数据库选型十要素

根据业务需求分析，我们决定拥抱分布式数据库，并以十个方面为考虑因素对市面上的分布式数据库产品展开调研。

1. 数据模型：支持的数据模型是否丰富？能否满足各种应用场景？

2. 性能：性能是否足够优秀？理论读写性能、事务能达到多少？并发能力和水平扩展能力如何？

3. 可用性和容错性：RPO、RTO 能达到多少？容错机制怎么样？备份与恢复能力如何？通过什么样的机制保证数据的高可用和可靠性？集群管理和运维能力如何？

4. 安全性：安全策略有哪些？能否对数据进行加密？身份验证如何和？访问控制如何？

5. 生态环境：生态如何？基本工具如何？社区与商业支持如何？

6. 成本效益：开发对接成本如何？同样需求的部署成本如何？同等数据量的存储成本如何？以及后续扩容的成本和运维成本如何？采购成本如何？

7. 可扩展性：节点数量有无限制？使用什么分布式架构？集群是如何管理的？

8. 应用场景：需要了解数据库的适用场景和行业应用，是否有成功案例？

9. 是否自研：全自研？还是部分自研？

10. 是否支持单元化场景？

（一）TiDB 与 OceanBase 多方面对比

通过筛选，最终选定两个分布式数据库产品：TiDB、OceanBase，并从分库分表、兼容性、多活容灾、性能、安全性、成本、生态等环境进行对比。

首先，两种数据库类型应用设计方面，都对业务透明，对外表现为一个整体数据库，不需要业务进行分库分表。

其中 TiDB 是自动分区，底层自动使用 region(默认 96M)打散；不支持多租户功能，资源无法隔离，同集群的业务相互影响；提供 TiDB 节点配合负载均衡使用。

OceanBase 可以根据业务规则设计最优数据模型，支持一级分区和二级分区，支持分区裁剪；支持多租户，可做到租户间资源隔离；提供 OBProxy 无状态代理，支持部署在 OB 服务器，对于延时要求较高的服务，可以以 SIdeCar 模式部署在应用 Pod 中，应用本地回环地址访问。

其次，应⽤和数据库解耦方面，Oceanbase 与 TiDB 都高度兼容 MySQL，方便业务平滑迁移。OceanBase3.x 不支持的少许 alter 类型变更在 4.1 已支持（如：int 到 varchar）。

再次，对于异地多活架构，二者均可实现两地三中⼼多活部署，以及同城的两中⼼双活。不过 OceanBase 采用的 Paxos 协议对于复杂⽹络环境的容忍性比 TiDB 采用的 Raft 更强。

最后，在运维管理方面，OceanBase 和 TiDB 都具备查询慢 SQL、执行计划、终止异常 session 等。OceanBase 提供 OCP 平台进行管理集群，OBD 黑屏命令辅助，TiDB 提供 dashboard 平台和 Tiup 黑屏命令进行集群管理。

此外，我们针对产品调研时关注的十个方面也进行了详细对比，数据如下表。

经过综合对比，我们倾向于使用 OceanBase，那么，OceanBase 真能解决 MySQL 的痛点吗？我们接下来看下 OceanBase 和 MySQL 有哪些实际区别。

MySQL 与 OceanBase 压测对比

我们尽可能使用同样的配置进行测试对比，数据如下。

硬件配置与软件版本

硬件配置

补充说明一下，MySQL 的机器配置虽然是 32C128G，实际上我们通过参数配置最后和 Oceanbase 的 20C90G 保持一致；

软件版本

压测结果对比

TPS/QPS 对比如下：

压测结论

• 线程数 < 200 时，MySQL 在 TPS、OPS 方面表现更好；

• 线程数 > 200 时，OceanBase 在 TPS、OPS 方面表现更好；

• OceanBase 的 3 个节点的集群能达到 20w 的 qps；

经过压测，OceanBase 的高可用、高并发能力完全能满足我们的业务需求，同时，我们在压测的时候进行故障模拟，能达到官方所说的 RPO=0，RTO<30s（我们压测的 3.x 的版本，4.x 的 RTO 可以达到 8s 以下）。另外，动态扩容基本上也无感知，通过租户管理让业务数据隔离；我们用 OMS 将业务压测的测试数据同步到 OceanBase 上，能够实现业务在测试环境无缝切换到 Oceanbase 上。所以我们决定部署 OceanBase。

三、业务迁移过程及注意事项

经过压测，我们发现 OceanBase 在高并发的情况下，除了 QPS 的性能不错外，还使用了 LSM-Tree 的存储结构（主要分为两方面：MemTable 代表内存、 SSTable 代表磁盘）。理论上只要服务的内存足够大，基本上都是内存写（转储的时候，性能会有一定的下降），这比较适合我们的业务监控数据和信号数据。同时，OceanBase 支持单张万亿级数据的表，完全能满足我们的需求，还不需要做数据的归档。

我们的业务监控数据和信号数据，以接收为主，主要是写，前端应用会有一些场景通过 id 去查基线数据。在平台端，根据监控数据做指标计算，以流的方式处理。我们的信号数据也差不多类似的场景，OceanBase 的压测情况，完全能满足我们的需求。

第一步，分区表设计

首次设计分区表的表结构如下：

-- 分区字段是create_time，类型TIMESTAMP  CREATE TABLE biz_monitor (  id bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',   biz_name varchar(50) NOT NULL COMMENT '业务名称',   event_type varchar(50) NOT NULL COMMENT '事件类型',   ....,   create_time TIMESTAMP NOT NULL COMMENT '创建时间',   PRIMARY KEY (id,create_time)  )AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8mb4 COMMENT = '业务监控数据表'  PARTITION BY RANGE(UNIX_TIMESTAMP(create_time))  (   PARTITION M202301 VALUES LESS THAN(UNIX_TIMESTAMP('2023-02-01')),   PARTITION M202302 VALUES LESS THAN(UNIX_TIMESTAMP('2023-03-01')),   PARTITION M202303 VALUES LESS THAN(UNIX_TIMESTAMP('2023-04-01'))  );

为了保证业务上线 OceanBase 后的稳定性，我们根据业务场景对 OceanBase 进行了压测。 期间遇到了问题：压测期间机器的 CPU 大约 50%左右，说明未达到瓶颈，但 QPS 一直压测不上去，TopSQL 也没有特别慢，大约 30ms 左右。

最后的租户配置是 12C40G*4unit

从监控数据可知：

1. 压测期间机器的 CPU 大约 50%左右，未达到瓶颈。

2. 响应时间较慢，对于 other 类型需要 100ms 以上。

3. 等待事件也较多，其中 other_wait 最多。

而且配置由 6C20G * 4(primary zone)改为 12C40G * 4(zone1,zone2,zone3)未见 QPS 由提升，最多的 QPS 只有 2.5w 左右。

经过分析，发现业务存在单独使用表 id 进行查询的情况，查询耗时 30ms 以上，执行次数较多，导致 CPU 总耗时较长，具体信息如下图 TopSQL 所示。

针对分区表直接使用 id 查询的情况，我们调整了分区表的结构（如下所示），将主键调整为分区字段在前，id 在后的形式，再加入一个单独的 id 全局唯一索引。表结构调整后，该 sql 的性能得到了极大提升，从 30ms 降低至 5ms 左右。

-- 分区字段是create_time，类型TIMESTAMP,将主键调整为分区字段在前，id在后的形式，然后再加入一个单独的id全局唯一索引 CREATE TABLE biz_monitor (  id bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',   biz_name varchar(50) NOT NULL COMMENT '业务名称',   event_type varchar(50) NOT NULL COMMENT '事件类型',   ....,   create_time TIMESTAMP NOT NULL COMMENT '创建时间',   PRIMARY KEY (create_time,id),  UNIQUE KEY `uniq_id` (`id`) global )AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8mb4 COMMENT = '业务监控数据表'  PARTITION BY RANGE(UNIX_TIMESTAMP(create_time))  (   PARTITION M202301 VALU，ES LESS THAN(UNIX_TIMESTAMP('2023-02-01')),   PARTITION M202302 VALUES LESS THAN(UNIX_TIMESTAMP('2023-03-01')),   PARTITION M202303 VALUES LESS THAN(UNIX_TIMESTAMP('2023-04-01'))  );

第二步，使用 OMS 进行数据迁移

将数据从 MySQL 迁移到 OceanBase 的时候，我们选择了 OceanBase 数据库一站式数据传输和同步的产品 OMS（如下图），它支持多种关系型数据库、消息队列与 OceanBase 数据库之间的数据复制，是集数据迁移、实时数据同步和增量数据订阅于一体的数据传输服务。使用 OMS 进行数据迁移，极大地简化了 DBA 的工作。

使用 OMS 数据迁移的流程如下。

值得一提的是， 使用 OMS 需要注意两点 ：一是迁移和全量校验对原业务有一定的影响，建议迁移时选择业务低峰期或者从库进行；二是迁移时建议调大租户的内存，避免 Over tenant memory limits 问题。

四、总结

以上就是我们解决 MySQL 痛点的过程，那么替换为 OceanBase 以后真的有效吗？

就目前的使用效果来看，OceanBase 给我们 的业务带来了七方面的明显提升。

1. 降低了业务系统的复杂度，集群从有状态变成了无状态，服务的稳定性提高，开发运维成本降低。

2. 在流量倾斜时，我们可以动态的切换主从副本，从而快速的实现流量转移。

3. 当有突发流量的时候，我们可以快速的扩展，提升整体的吞吐量。

4. 集群内 join 操作，通过表组优化后，能实时提供。

5. 我们一套 OceanBase 集群写吞吐量是之前 MySQL 集群 5 套的总和。

6. 使用 OceanBase 的压缩功能后，我们的存储由 16TB 降到了 4-5TB，整体成本降低了 70%。

7. 再也不用帮业务排查数据不一致的问题了。

OceanBase 为我们分区分表提供了非常好的一个开端，避免了使用分布式中间件 sql 的不兼容、维护繁琐问题。目前，我们还有业务单元化的需求，也已经经过了测试和验证，后续会逐渐应用到生产环境中。

此外，在使用 OceanBase 过程中也遇到了几个小问题，希望官方在后续版本中支持 OCP 平台自动检测分区表并添加分区，以及集群磁盘占用百分比可以调大也可以调小。