本文来自 TiDB 社区合肥站走进蔚来汽车——吴记老师的演讲《TiDB 在新能源车企的实践:MySQL 到 TiDB 的迁移思考》。
这次分享深入探讨了新能源车企蔚来汽车从 MySQL 迁移到 TiDB 的过程与实践,包括迁移过程中的挑战和动机,以及面对单表数据量增长至 20 亿条时的应对策略;此外,也将分享其使用 TiDB 过程中常见的问题与解决方法,帮助大家更有效地应用 TiDB 解决企业数据库管理中的挑战。
蔚来是一家全球化的智能电动汽车公司,致力于通过提供高性能的智能电动汽车与极致用户体验。2023 年第三季度中国汽车市场销量 566.8 万辆,同比增长 2.4%,其中新能源车型销量合计接近 200 万辆,同比增长 36%。其中,蔚来在中国 30 万元以上的纯电汽车市场中位列第一,市场份额占比 45%。
随着业务的快速扩张,蔚来公司内部某些业务的数据量急剧增加,部分业务的日增数据量达到千万级别。在 MySQL 数据库中,一些表的记录数已超过 20 亿条。在多种业务场景中,对这些大型表进行联接查询导致严重的性能瓶颈,查询效率低下,甚至经常超时。由于查询需求的多样性,传统基于 hash 的分表策略已无法满足业务需求。
我们目前面临的数据库挑战主要包括:
1. 性能问题:在执行包含 20 亿记录的大表与不同规模的其他表(百万、几十万、几万)的联接查询时,性能显著下降,特别是对于聚合函数如 count
的查询几乎不可行。
2. 时间维度跨度大:大多查询场景需要结合时间维度进行时间范围查询,通常要查询中过滤最近半年的数据,但也有可能需要查询历史数据。
3. 表结构复杂性:大型表初始包含 20 多亿条记录,拥有 30 多个字段,其中约 10 个字段需要与其他三个表进行联接查询。
4. 写入与同步延迟:部分数据库表的单表写入数据量巨大,导致主从复制(master-slave replication)出现延迟,影响多个业务流程。
5. DDL 执行缓慢:在 MySQL 中,由于单表数据量过大,执行数据定义语言(DDL)操作变得非常缓慢,有时需要数小时才能完成。
为了解决这些问题,可能需要考虑以下策略:
通过调研,蔚来数据应用团队将目光放到了分布式数据库上,TiDB 作为一款广泛使用的开源分布式 HTAP 数据库,已纳入团队的调研和应用范围。
在调研中,蔚来数据应用团队认为 TiDB 作为一款开源分布式关系型数据库,在线事务处理,在线分析处理融合型分布式数据库产品,具备水平弹性扩容或者缩容金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 /MySQL 8.0 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。
TiDB 的多项优势特性有效满足了蔚来数据应用团队在处理大规模数据和高并发事务时的需求:
1. 分布式架构:TiDB 采用分布式关系型数据库架构,有效突破了单机处理能力的局限,提升了整体性能,扩展性。
2. 高可用性:TiDB 通过使用 Raft 一致性算法,数据在各 TiKV 节点间复制为多副本,以确保某个节点宕机时数据的安全性,同时具备同城双中心、两地三中心的金融级高可用方案。
3. 水平弹性扩展:TiDB 不仅支持传统关系型数据库的事务和分析功能,还具备非关系型数据库的水平扩展能力和灵活性,提供了高性能的数据存储解决方案。
4. 分布式强一致性事务处理:TiDB 支持 ACID(原子性、一致性、隔离性、持久性)事务,确保在分布式环境下的数据一致性和完整性。
5. MySQL 协议高度兼容性:TiDB 与 MySQL 协议高度兼容,支持广泛的 MySQL SQL 语法以及 MySQL 生态系统工具,降低了从 MySQL 迁移到 TiDB 的学习成本和技术障碍,实现了平滑过渡。
6. 灵活的分区功能:TiDB 提供了灵活的分区机制,支持 hash、range、list、key 等分区,简化了数据管理和维护工作,使得业务逻辑与数据分片解耦,提高了查询效率。
7. 强大的数据同步工具:
a. DM 可以方便的实现数据从 MySQL(全量+增量)同步到 TiDB
b. TiCDC 工具支持基于 Binlog 的数据同步,允许 TiDB 与 MySQL 或者 TIDB 之间实现主从复制,确保数据的实时同步和一致性。
8. 丰富的生态系统:TiDB 拥有一个成熟的生态系统,包括 TiFlash 提供的列式存储引擎,优化了分析型查询的性能;TiSpark 允许 TiDB 作为存储层,结合 Spark 的强大计算能力,提供了灵活的大数据处理能力。
通过这些特性,TiDB 不仅为蔚来提供了一个高性能、高可用的数据库解决方案,还通过其强大的生态系统,支持蔚来在数据管理和分析方面的需求,推动了业务的持续创新和发展。
蔚来数据应用团队从架构、存储层面对比了 TiDB 与 MySQL 的区别与优势:
TiDB Server 层:
特点:
传统单体架构:
特点:
<center>MySQL 架构图</center>
<center>TiDB 架构图</center>
InnoDB 存储引擎:
B+树索引结构:
事务和 MVCC:
TiKV 分布式键值存储:
MVCC 版本控制:
数据存储格式:
特点:
MySQL 存储架构
TiDB 存储层架构
B+树结构:
主键索引:
非主键索引:
特点:
KV 存储模型:
主键索引:
唯一索引:
非唯一索引:
特点:
<center>MySQL 索引 b+tree</center>
<center>TiDB 中 Rocksdb 分布式 leveldb lsm</center>
InnoDB 事务模型:
MVCC 实现:
锁机制:
TiDB 事务模型:
MVCC 实现:
通过这种详细的事务和 MVCC 机制对比,我们可以更深入地理解 TiDB 和 MySQL 在事务处理和并发控制方面的差异,以及它们如何适应不同的业务场景和性能需求。
<center>TiDB 同时支持了乐观锁和悲观锁模式</center>
<center>MySQL 通过 undolog 实现( Redo Log、Undo Log、Bin Log ( https://zhuanlan.zhihu.com/p/528575954 ))</center>
<center>TiDB MVCC 的实现</center>
由于是分布式数据库,在 TiDB 中 SQL 的执行和 MySQL 有很大区别,如索引实现、存储机制等。
- 在 TiDB 中查询一条 SQL 是如何执行的,使用的引擎,索引等信息操作如下:
explain yoursql;
explain analyze yoursql; //真实执行
- SQL 语法的兼容性
TiDB 语法兼容了 MySQL 8.0 的绝大部分语法,目前仅发现新版的 MySQL 一些特殊语法不支持,比如 default CURRENT_DATE
;同时新增了一些语法,比如主键索引 auto_random
的类型,基本上业务上一般已经用的 MySQL 的 SQL 基本都支持。
TiDB 当前支持的类型包括 Range 分区、Range COLUMNS 分区、Range INTERVAL 分区、List 分区、List COLUMNS 分区 和 Hash 分区。
- 查看分区的数据
/*查看分区的数据分布*/
SHOW STATS_META where table_name = "table_demo";
/*从分区直接查询数据*/
CREATE TABLE table_demo (
`id` bigint(20) primary key auto_random,
start_time timestamp(3)
) PARTITION BY RANGE (FLOOR(UNIX_TIMESTAMP(`start_time`)))
SELECT * FROM table_demo PARTITION (p1) where xxx;
/* 新增分区 */
ALTER TABLE table_demo ADD PARTITION(PATITION p2 VALUES LESS THAN ( FLOOR(UNIX_TIMESTAMP(`start_time`))
/* 删除分区 */
ALTER TABLE table_demo drop partition p1
- 分区表的说明:
TiDB 每个分区都是单独的一张表,会对每个分区进行统计,如查询的时候进行逻辑优化,推算数据在哪些分区里面;TiFlash 也支持分区。
- 分区表的分析
TiDB 分区表分析有利于统计索引(分区)的分布情况
show variables like '%tidb_auto_analyze_end_time%';set global tidb_auto_analyze_end_time = "06:00 +0000"; analysis table table_name; //分析表,有利于执行计划
TiDB 提供了列式存储引擎 TiFlash,它是 TiKV 的列存扩展,在提供了良好的隔离性的同时,也兼顾了强一致性。
只需在 TiDB 做出一些设置,数据就可以从 TiKV->TiFlash 同步过去。
//增加 tiflash 副本
ALTER TABLE table_name SET TIFLASH REPLICA count;
//查看数据同步进度
SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = '<db_name>' and TABLE_NAME = '<table_name>';
TiDB 可以根据表分析的情况综合索引信息和数据量,自动选择使用 TiFlash 或者 TiKV,也可以在 SQL 内指定使用的存储引擎,且支持多表。
select /*+ read_from_storage(tiflash[table_name]) */ ... from table_name;
原始的 MySQL 数据库中都是用户业务数据,蔚来数据团队为了稳妥采取了先将数据写入到 MySQL,再通过 DM 将数据同步到 TiDB 中,内部各大系统直接使用 TiDB 进行查询,大幅优化了查询性能。
同步之后,蔚来数据团队用 20 亿单表业务数据作验证,分别在 MySQL 和 TiDB 运行,进行性能对比:
经过优化,TiDB 的 Join 查询业务上 80% 查询达到 2s 内,20% 查询在 5s 内。Count 结果很快,用户体验非常好。
目前,TiDB 已被蔚来多个业务部门广泛采用。业务方反馈 TiDB 真正解决了业务中的很多问题,并且在使用中表现非常平稳,稳定性超乎预料,大大增强了使用国产分布式数据库的信心。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。