自己可以做视频网站吗,wordpress is home,下载住小帮app看装修,河南网站建设找工作作者#xff1a; Billdi表弟 原文来源#xff1a; https://tidb.net/blog/449c3f5b 演讲嘉宾#xff1a;吴记 蔚来汽车Tidb爱好者 整理编辑#xff1a;黄漫绅#xff08;表妹#xff09;、李仲舒、吴记 本文来自 TiDB 社区合肥站走进蔚来汽车——来自吴记老师的演讲… 作者 Billdi表弟 原文来源 https://tidb.net/blog/449c3f5b 演讲嘉宾吴记 蔚来汽车Tidb爱好者 整理编辑黄漫绅表妹、李仲舒、吴记 本文来自 TiDB 社区合肥站走进蔚来汽车——来自吴记老师的演讲《TiDB 在新能源车企的实践MySQL 到 TiDB 的迁移思考》。这次分享将深入探讨新能源车企从 MySQL 迁移到 TiDB 的过程与实践。我们将分享迁移过程中的挑战和动机面对单表数量增长至 20 亿带来的应对策略并详细介绍 TiDB 如何优化多表 Join 场景下的查询效率。此外也将分享使用 TiDB 过程中常见的问题与解决方法帮助大家更有效地应用 TiDB 解决企业数据库管理中的挑战。 活动回顾及 PPT 下载 https://asktug.com/t/topic/1020557 演讲视频实录 https://www.bilibili.com/video/BV1LC4y1C7Yq 企业介绍 蔚来是一家全球化的智能电动汽车公司致力于通过提供高性能的智能电动汽车与极致用户体验。2023 年第三季度中国汽车市场销量 566.8 万辆同比增长 2.4%其中新能源车型销量合计接近 200 万辆同比增长 36%。其中蔚来在中国 30 万元以上的纯电汽车市场中位列第一市场份额占比 45%。 业务挑战 随着业务的快速扩张蔚来公司内部某些业务的数据量急剧增加部分业务的日增数据量达到千万级别。在MySQL数据库中一些表的记录数已超过 20 亿条。在多种业务场景中需要对这些大型表与其他表进行联接查询这导致了严重的性能瓶颈查询效率低下甚至在某些情况下查询经常超时。由于查询需求的多样性传统的基于 hash 的分表策略已无法满足业务需求。 我们目前面临的数据库挑战主要包括 性能问题 在执行包含 20 亿记录的大表与不同规模的其他表百万、几十万、几万的联接查询时性能显著下降特别是对于聚合函数如 count 的查询几乎不可行。 时间维度跨度大 大多查询场景需要结合时间维度进行时间范围查询通常要查询中过滤最近半年的数据但是仍然有对历史数据查询的可能。 表结构复杂性 大型表初始包含 20 多亿条记录拥有 30 多个字段其中约 10 个字段需要与其他三个表进行联接查询。 写入与同步延迟 部分数据库表的单表写入数据量巨大导致主从复制master-slave replication出现延迟影响多个业务流程。 DDL执行缓慢 在MySQL中由于单表数据量过大执行数据定义语言DDL操作变得非常缓慢有时需要数小时才能完成。 为了解决这些问题我们可能需要考虑以下策略 优化查询 重写查询逻辑减少不必要的联接和数据扫描。 索引优化 为常用于联接和查询的字段创建索引提高查询效率。 分区表 根据业务逻辑对表进行分区以提高查询和维护的性能。 读写分离 通过读写分离来减轻主数据库的压力提高查询响应速度。 分布式数据库 考虑使用分布式数据库解决方案以支持水平扩展和负载均衡。 异步处理 对于不需要即时返回结果的查询采用异步处理方式。 为什么选择 TiDB 通过调研蔚来数据应用团队将目光放到了分布式数据库上TiDB 作为一款流行度很广的开源分布式 HTAP 数据库开始进入团队调研和应用的视野。 在调研中蔚来数据应用团队认为 TiDB 作为一款开源 分布式关系型数据库 在线事务处理 在线分析处理 融合型分布式数据库产品具备 水平弹性扩容或者缩容 、 金融级高可用 、 实时 HTAP 、云原生的分布式数据库、 兼容 MySQL 5.7 /MySQL 8.0 协议和 MySQL 生态 等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。 TiDB的多项优势特性有效满足了蔚来数据应用团队在处理大规模数据和高并发事务时的需求 分布式架构 TiDB 采用分布式关系型数据库架构有效突破了单机处理能力的局限提升了整体性能扩展性。 高可用性: TiDB 通过使用 Raft 一致性算法数据在各 TiKV 节点间复制为多副本以确保某个节点宕机时数据的安全性同时具备同城双中心、两地三中心的金融级高可用方案。 水平弹性扩展 TiDB 不仅支持传统关系型数据库的事务和分析功能还具备非关系型数据库的水平扩展能力和灵活性提供了高性能的数据存储解决方案。 分布式强一致性事务处理 TiDB 支持 ACID原子性、一致性、隔离性、持久性事务确保在分布式环境下的数据一致性和完整性。 MySQL 协议高度兼容性 TiDB 与 MySQL 协议高度兼容支持广泛的 MySQL SQL 语法以及 MySQL 生态系统工具降低了从 MySQL 迁移到 TiDB 的学习成本和技术障碍实现了平滑过渡。 灵活的分区功能 TiDB 提供了灵活的分区机制支持 hash、range、list、key 等分区简化了数据管理和维护工作使得业务逻辑与数据分片解耦提高了查询效率。 强大的数据同步工具 DM可以方便的实现数据从mysql(全量增量)同步到TIDB TiCDC 工具支持基于 Binlog 的数据同步允许 TiDB 与 MySQL或者TIDB 之间实现主从复制确保数据的实时同步和一致性。 丰富的生态系统 TiDB 拥有一个成熟的生态系统包括 TiFlash 提供的列式存储引擎优化了分析型查询的性能TiSpark 允许 TiDB 作为存储层结合 Spark 的强大计算能力提供了灵活的大数据处理能力。 通过这些特性TiDB 不仅为蔚来提供了一个高性能、高可用的数据库解决方案还通过其强大的生态系统支持蔚来在数据管理和分析方面的需求推动了业务的持续创新和发展。 架构对比 蔚来数据应用团队从架构、存储层面对比了 TiDB 与 MySQL 的区别与优势 TiDB 架构详细描述 TiDB Server 层 SQL解析与优化 TiDB Server负责接收客户端的SQL请求进行语法解析和逻辑优化生成执行计划。这一步骤是查询优化的关键TiDB Server会利用其优化器来决定最有效的查询执行路径。 分布式协调器PDPlacement Driver PD是TiDB的元数据管理组件负责存储集群的元信息包括数据分布和节点状态。它与TiDB Server交互协调数据的分布和负载均衡。 分布式存储TiKV TiKV是一个分布式的键值存储系统负责存储实际的数据。TiDB Server通过PD与TiKV进行交互获取或写入数据。 执行器 在获取到数据后TiDB Server的执行器负责进行数据的进一步处理包括合并、排序、分页和聚合等操作。 特点 水平扩展 TiDB Server可以轻松地通过增加节点来扩展系统的处理能力。 高可用性 TiDB Server设计为无状态可以快速故障转移保证服务的连续性。 强一致性 通过分布式事务和MVCC机制TiDB保证了事务的ACID属性。 MySQL架构详细描述 传统单体架构 集中式处理 MySQL的所有数据库操作包括SQL解析、查询优化、数据存储和检索都在同一服务器上完成。 单一数据存储 数据存储在本地磁盘或连接的存储系统中没有分布式存储的概念。 垂直扩展依赖 由于是单体架构MySQL通常通过增加单个服务器的硬件能力如CPU、内存、存储来提升性能这称为垂直扩展。 特点 简化管理 由于所有组件都在一个服务器上管理和维护相对简单。 扩展性限制 垂直扩展有其物理限制当达到硬件极限时性能提升会遇到瓶颈。 事务和并发处理 MySQL通过行锁和表锁等机制来处理并发和事务但在高并发场景下可能会遇到性能瓶颈。 结构对比总结 扩展性 TiDB的分布式架构允许其水平扩展而MySQL主要依赖垂直扩展。 容错能力 TiDB通过多节点和副本机制提供高可用性MySQL则依赖于主从复制和故障转移机制。 性能 TiDB通过分布式计算和存储优化了大规模数据集的性能MySQL在大规模数据集下可能会遇到性能瓶颈。 复杂性与灵活性 TiDB的架构较为复杂但提供了更高的灵活性和扩展性MySQL架构简单但在处理大规模和高并发场景时可能需要额外的优化措施。 MySQL 架构图 TiDB 架构图 存储层 MySQL存储架构 InnoDB存储引擎 MySQL的默认存储引擎是InnoDB它是一个健壮的事务型存储引擎支持ACID事务。 所有数据都存储在表空间中表空间可以包含多个数据文件和日志文件。 表数据以B树的索引结构存储这为快速的数据访问提供了基础。 B树索引结构 主键索引和非主键索引都是B树结构其中非主键索引的叶子节点存储主键值用于快速定位到具体的数据行。 B树的每个节点可以存储更多的键值这意味着相比B树B树的高度更低查询效率更高。 事务和MVCC InnoDB通过行级锁定和MVCC机制来支持高并发的读写操作。 通过Undo日志来实现MVCC允许在不锁定资源的情况下读取历史数据版本。 TiDB存储层 TiKV分布式键值存储 TiKV是TiDB的分布式存储层它使用RocksDB作为其本地存储引擎优化了写入性能和磁盘空间使用。 TiKV将数据分散存储在多个节点上通过Raft协议保证数据的强一致性和高可用性。 MVCC版本控制 TiKV使用MVCC机制来处理并发控制和历史数据版本每个事务都会获取一个全局唯一的时间戳TS作为版本号。 通过这种方式TiKV可以支持同一时间点的多个事务读取到一致的数据快照。 数据存储格式 主键数据存储格式为 tablePrefix{tableID}_recordPrefixSep{Col1} 其中 Value 包含了行数据的所有列值。 唯一索引的存储格式为 tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue Value 为对应的行ID。 非唯一索引的存储格式与唯一索引类似但每个索引值后附加行ID Value 可能为 null 。 特点 TiKV的存储层设计为易于扩展可以水平扩展以适应不断增长的数据量。 通过Raft协议TiKV能够在多个副本之间同步数据提高了数据的可用性和容错能力。 存储层对比总结 扩展性 TiDB的TiKV存储层设计为分布式易于水平扩展而MySQL的InnoDB存储引擎通常需要垂直扩展。 并发控制 TiDB使用MVCC和TSOTimestamp Ordering来实现并发控制而MySQL使用行级锁定和MVCC。 数据一致性 TiKV通过Raft协议保证跨多个节点的数据一致性InnoDB则依赖于单个服务器的事务日志和恢复机制。 存储效率 TiKV的RocksDB存储引擎优化了写入性能和压缩而InnoDB的B树结构优化了读取性能。 MySQL 存储架构 TiDB 存储层架构 TiDB索引实现 KV存储模型 TiDB的索引基于键值Key-Value存储模型实现。这种模型非常适合分布式环境因为它允许数据的水平分割和分布式存储。 主键索引 主键索引使用行的主键值作为键行数据的序列化形式作为值。例如如果 Col1 是主键则键可能表示为 tablePrefix{tableID}_recordPrefixSep{Col1} 。 这种映射允许TiDB通过主键值直接访问对应的行数据提供了高效的数据检索。 唯一索引 唯一索引使用索引列的值作为键行的主键值作为值。例如键可能表示为 tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue 值是对应的 RowID 。 这种设计确保了索引的唯一性并且可以通过索引值快速定位到具体的数据行。 非唯一索引 非唯一索引与唯一索引类似但允许同一个键对应多个值。在这种情况下键仍然是索引列的值但值是包含 RowID 的列表。 这允许TiDB处理具有相同索引值的多行数据。 特点 TiDB的索引实现简化了分布式环境下的数据访问通过键值对直接映射提高了查询效率。 由于TiDB的存储层TiKV使用RocksDB索引数据也被优化存储以减少磁盘空间的使用。 MySQL索引实现 B树结构 MySQL的索引基于B树结构这是一种自平衡树优化了读写性能和空间使用。 B树的所有数据都存储在叶子节点内部节点仅存储键值和指向子节点的指针这减少了查找过程中的磁盘I/O操作。 主键索引 主键索引是聚簇索引非主键索引是二级索引。聚簇索引的叶子节点直接包含行数据而非主键索引的叶子节点包含主键值用于快速跳转到聚簇索引。 非主键索引 非主键索引的叶子节点不直接存储行数据而是存储对应的主键值。查询时需要通过主键值回表查询访问聚簇索引以获取完整的行数据。 特点 B树结构减少了查询过程中的I/O操作次数提高了数据访问速度。 聚簇索引和非聚簇索引的设计优化了数据的物理存储减少了冗余和空间使用。 索引实现对比总结 数据访问方式 TiDB通过键值对直接映射数据而MySQL通过B树结构进行索引。 分布式适应性 TiDB的索引实现更适合分布式环境易于水平扩展。MySQL的B树索引则优化了单个服务器上的数据访问。 查询效率 TiDB的索引实现允许快速的数据检索特别是在分布式查询中。MySQL的B树索引通过减少I/O操作提高了查询效率。 存储优化 TiDB的RocksDB存储引擎优化了索引数据的存储而MySQL的B树结构减少了索引的存储空间需求。 MySQL 索引 btree TiDB 中 Rocksdb 分布式 leveldb lsm TiDB事务处理和MVCC TiDB事务模型 TiDB支持两种类型的锁乐观锁和悲观锁以适应不同的业务场景。 乐观锁 适用于写冲突较少的环境通过检测在事务开始后数据是否被其他事务修改来避免锁的争用。如果检测到冲突事务会进行重试。 悲观锁 适用于高冲突环境通过在事务开始时就锁定涉及的数据行防止其他事务修改这些数据。 MVCC实现 TiDB采用MVCC机制来提供在不锁定资源的情况下读取历史数据版本的能力从而提高并发性能。 MVCC通过为每个事务分配一个全局唯一的时间戳TS并使用这个时间戳来确定数据的可见性。 在TiDB中每个数据行都保存了多个版本每个版本都有一个开始和结束的时间戳。查询操作会根据当前事务的时间戳来确定应该读取哪个版本的数据。 MySQL事务处理和MVCC InnoDB事务模型 MySQL的InnoDB存储引擎支持ACID原子性、一致性、隔离性、持久性事务。 InnoDB使用行级锁定机制来处理并发写入确保事务的隔离性。 MVCC实现 InnoDB通过Undo Log来实现MVCC允许在不锁定资源的情况下读取历史数据版本。 Undo Log记录了数据在事务开始前的状态这样即使在其他事务修改了数据之后当前事务仍然可以读取到事务开始前的数据状态。 InnoDB的MVCC主要通过Read View来实现Read View是一个快照包含了在事务开始时所有已提交的数据的可见性信息。 锁机制 InnoDB主要使用悲观锁通过行锁和表锁来处理数据的并发访问防止数据的不一致性。 行锁在SELECT ... FOR UPDATE或INSERT/UPDATE/DELETE操作时自动加锁以保证事务的原子性和隔离性。 表锁在某些特定的操作如全表扫描或某些类型的索引操作中使用。 事务与MVCC对比总结 锁机制 TiDB支持乐观锁和悲观锁提供了更灵活的锁策略而MySQL主要使用悲观锁。 MVCC实现 TiDB使用时间戳和版本控制来实现MVCC而InnoDB使用Undo Log和Read View。 并发性能 TiDB的MVCC机制通过减少锁的争用来提高并发性能特别是在高并发读写的场景下。InnoDB的MVCC通过Undo Log减少锁的使用但在高冲突环境下可能仍然会遇到锁争用。 历史数据访问 TiDB和InnoDB都允许在不锁定资源的情况下访问历史数据版本提高了系统的并发读取能力。 通过这种详细的事务和MVCC机制对比我们可以更深入地理解TiDB和MySQL在事务处理和并发控制方面的差异以及它们如何适应不同的业务场景和性能需求。 TiDB 同时支持了乐观锁和悲观锁模式 MySQL 通过undolog实现 Redo Log、Undo Log、Bin Log TiDB MVCC 的实现 SQL生命周期 TiDB SQL执行 分布式环境中SQL执行涉及多个组件和步骤包括索引使用、存储引擎选择等。 性能分析工具 使用 EXPLAIN 和 EXPLAIN ANALYZE 分析SQL执行计划和实际执行情况。 由于是分布式数据库在 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、List和Hash分区简化数据管理并提高查询效率。 分区表分析 自动分析分区数据分布优化查询计划。 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; //分析表有利于执行计划列式存储 TiFlash 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 Data Migration 将数据同步到 TiDB 中内部各大系统直接使用 TiDB 进行查询大幅优化了查询性能。 同步之后蔚来数据团队用 20 亿单表业务数据作验证分别在 MySQL 和 TiDB 运行进行性能对比 Join 性能 查询耗时稳定性 Count 性能 体验 MySQL 查询的性能比较稳定快平均 5s但是30% 查询条件下超时业务无法接受 join 查询比较稳定 几乎无法 count 分页功能无法使用只能下一页 TiDB 部分条件快部分条件慢大部分条件下在 2-3s 左右95% 的查询 2s 内出结果 稳定 count 比较快 3s 左右 可以分页分页数几十万可能sql内存超限制 在此基础上蔚来数据应用团队又对 TiDB 性能又做出进一步优化如使用分区表缩小减少潜在的查询范围使用 TiFlash 列存进一步优化查询效率等。 经过优化TiDB 的 Join 查询业务上 80% 查询达到 2s 内20% 查询在 5s 内。Count 结果很快用户体验非常好。 总结 目前TiDB 已经在蔚来内部得到了大范围推广有多个业务开始使用 TiDB。业务方反馈 TiDB 真正解决了业务中的很多问题并且在使用中表现非常平稳稳定性超乎预料大大增强了使用国产分布式数据库的信心。 活动回顾
