本文来自社区分享，仅限交流探讨。原文作者：李婵玲，某智能车企DBA。欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/
最近一年，我们完成了从MySQL到OceanBase的替代过程，既降低了架构复杂度和存储成本，又提高了扩展性和吞吐量，而且再也不用担心数据不一致问题了。故而将我们遇到的痛点问题、解决方案、技术选型过程总结成此文，供大家参考。
一、业务增长凸显MySQL八大支撑瓶颈
相信很多企业都会因为业务快速发展，数据成指数级增长带来一些新的需求或系统瓶颈。我所在的国内某知名智能车企也面临这样的问题，特别是我们的业务监控数据和信号数据在近几年爆发式增长，我们过去使用的MySQL数据库越来越难以应对，主要体现为以下八个方面。
-
性能瓶颈：单台服务器难以承受大规模数据和请求访问，导致数据库性能下降，只能通过部署多套集群解决。
-
水平扩展困难：单集群容量达到瓶颈时，无法实现无缝扩展，需要停机维护，影响业务运行。
-
数据一致性难以保证：多集群数据合并的时候，数据更新同步难度大，易出现数据不一致的情况。
-
多活实现困难：多活场景下，无法保证业务双写。
-
实效性差：多集群的跨节点join操作需要内存运算，或者大数据整合后提供，时效性无法保证。
-
容易造成集群数据或流量倾斜。
-
各集群之间数据调度麻烦。
-
运维压力大：需要定期备份归档数据，排查数据问题。
为了解决上述八个问题，我们需要制定高效的数据库解决方案，于是开始了数据库的调研、选型、替换之旅。
二、分布式数据库选型十要素
根据业务需求分析，我们决定拥抱分布式数据库，并以十个方面为考虑因素对市面上的分布式数据库产品展开调研。
-
数据模型：支持的数据模型是否丰富？能否满足各种应用场景？
-
性能：性能是否足够优秀？理论读写性能、事务能达到多少？并发能力和水平扩展能力如何？
-
可用性和容错性：RPO、RTO能达到多少？容错机制怎么样？备份与恢复能力如何？通过什么样的机制保证数据的高可用和可靠性？集群管理和运维能力如何？
-
安全性：安全策略有哪些？能否对数据进行加密？身份验证如何和？访问控制如何？
-
生态环境：生态如何？基本工具如何？社区与商业支持如何？
-
成本效益：开发对接成本如何？同样需求的部署成本如何？同等数据量的存储成本如何？以及后续扩容的成本和运维成本如何？采购成本如何？
-
可扩展性：节点数量有无限制？使用什么分布式架构？集群是如何管理的？
-
应用场景：需要了解数据库的适用场景和行业应用，是否有成功案例？
-
是否自研：全自研？还是部分自研？
-
是否支持单元化场景？
（一）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 | TiDB |
|---|---|---|
| 数据模型 | 关系型、半结构化、非关系型、图、时序 | 非关系型、半结构化、关系型 |
| 数据库性能 | 以优异的成绩经过TPC-C 测试，经过阿里系双十一的验证 | 未经过互联网高并发核心业务的验证 |
| 可用性与容错性 | 4.0支持6级容灾标准（RPO=0,RTO<8s）,支持三地五中心 | RPO=0,RTO<30s，支持两地三中⼼ |
| 安全性 | 租户资源隔离，租户内的操作只会影响租户、租户管理 | 无资源隔离，使用时集群内会相互影响 |
| 生态环境 | 生态稍微差些，但是企业配套极为丰富，且经历了多少核心场景验证 | 开源社区活跃，生态较为健全 |
| 成本效益 | 兼容MySQL与Oracle，改动极小，租户按需配置资源,最小需要3obproxy,3observer，存储成本降低70%~90% | 兼容MySQL5.7，整个集群一套，无资源隔离，部署成本相对较高（需要3pd-server,2tidb-server,tikv-server） |
| 可扩展性 | 存算一体,支持数千个节点，单集群数据量超3PB，最大单表行达万亿级，使用Multi-Paxos，数据可以动态漂移； | 存算分离,使用Multi-Raft， |
| 应用场景 | 支付宝、网商银行 | 大多都是OLAP场景 |
| 是否自研 | 全自研 | Tikv基于RocksDB进行数据存储 |
经过综合对比，我们倾向于使用OceanBase，那么，OceanBase真能解决MySQL的痛点吗？我们接下来看下OceanBase和MySQL有哪些实际区别。
MySQL 与 OceanBase压测对比
我们尽可能使用同样的配置进行测试对比，数据如下。
硬件配置与软件版本
硬件配置
| 服务类型 | 实例数 | 机器配置 | 租户配置 |
|---|---|---|---|
| OceanBase 数据库 | 3 | 56C238G，35T本地SSD | 20C90G |
| Sysbench | 1 | 16C32G | |
| ODP | 1 | 46C258G | |
| MySQL | 1 | 32C128G，SSD800G |
补充说明一下，MySQL的机器配置虽然是32C128G，实际上我们通过参数配置最后和Oceanbase的20C90G保持一致；
软件版本
| 服务类型 | 软件类型 |
|---|---|
| OceanBase 数据库 | OceanBase V3.2.3.1 |
| ODP | obproxy V3.8 |
| MySQL | MySQL5.7.31 |
| Sysbench | sysbench 1.0.17 |
| OS | CentOS Linux release 7.5.1804 (Core) |
压测结果对比
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
从监控数据可知：
- 压测期间机器的CPU大约50%左右，未达到瓶颈。
- 响应时间较慢，对于other类型需要100ms以上。
- 等待事件也较多，其中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给我们 的业务带来了七方面的明显提升。
-
降低了业务系统的复杂度，集群从有状态变成了无状态，服务的稳定性提高，开发运维成本降低。
-
在流量倾斜时，我们可以动态的切换主从副本，从而快速的实现流量转移。
-
当有突发流量的时候，我们可以快速的扩展，提升整体的吞吐量。
-
集群内join操作，通过表组优化后，能实时提供。
-
我们一套OceanBase集群写吞吐量是之前MySQL集群5套的总和。
-
使用OceanBase的压缩功能后，我们的存储由16TB降到了4-5TB，整体成本降低了70%。
-
再也不用帮业务排查数据不一致的问题了。
OceanBase为我们分区分表提供了非常好的一个开端，避免了使用分布式中间件 sql的不兼容、维护繁琐问题。目前，我们还有业务单元化的需求，也已经经过了测试和验证，后续会逐渐应用到生产环境中。
此外，在使用OceanBase过程中也遇到了几个小问题，希望官方在后续版本中支持OCP平台自动检测分区表并添加分区，以及集群磁盘占用百分比可以调大也可以调小。