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