关于数据库:分享集群吞吐量以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 平台自动检测分区表并增加分区，以及集群磁盘占用百分比能够调大也能够调小。