个推分享两个调优技巧,让TiDB性能提速千倍!

个推技术实践
• 阅读 643

个推“大数据降本提效”专题,正是通过总结分享自身在大数据实战过程中的踩坑经验、调优技巧等,为从业人员开展大数据实践提供参考。本文是“大数据降本提效”专题的第三篇,将为大家分享个推通过调优,实现TiDB千倍性能提升的实战经验。

个推分享两个调优技巧,让TiDB性能提速千倍!

个推与TiDB的结缘

作为一家数据智能企业,个推为数十万APP提供了消息推送等开发者服务,同时为众多行业客户提供专业的数字化解决方案。在快速发展业务的同时,公司的数据体量也在高速增长。随着时间的推移,数据量越来越大,MySQL已经无法满足公司对数据进行快速查询和分析的需求,一种支持水平弹性扩展,能够有效应对高并发、海量数据场景,同时高度兼容MySQL的新型数据库成为个推的选型需求。

经过深入调研,我们发现“网红”数据库TiDB不仅具备以上特性,还是金融级高可用、具有数据强一致性、支持实时HTAP的云原生分布式数据库。因此,我们决定将MySQL切换到TiDB,期望实现在数据存储量不断增长的情况下,仍然确保数据的快速查询,满足内外部客户高效分析数据的需求,比如为开发者用户提供及时的推送下发量、到达率等相关数据报表,帮助他们科学决策。

完成选型后,我们就开始进行数据迁移。本次迁移MySQL数据库实例的数据量有数T左右,我们采用TiDB自带的生态工具Data Migration (DM)进行全量和增量数据的迁移。

  • 全量数据迁移:从数据源迁移对应表的表结构到TiDB,然后读取存量数据,写入到TiDB集群。

  • 增量数据复制:全量数据迁移完成后,从数据源读取对应的表变更,然后写入到TiDB集群。

个推分享两个调优技巧,让TiDB性能提速千倍!

个推将MySQL数据迁移到TiDB

当数据同步稳定之后,将应用逐步迁移到TiDB Cluster。把最后一个应用迁移完成之后,停止DM Cluster。这样就完成了从MySQL到TiDB的数据迁移。

注:DM的具体配置使用详见官方文档。

陷入TiDB使用的“反模式”

然而,当应用全部迁移到TiDB之后,却出现了数据库反应慢、卡顿,应用不可用等一系列的问题。

如下图:

个推分享两个调优技巧,让TiDB性能提速千倍!

登陆数据库时遇到卡顿

通过排查,我们发现有大量的慢SQL都是使用load导入数据的脚本。

个推分享两个调优技巧,让TiDB性能提速千倍!

慢SQL的导入耗时几十分钟

和业务方沟通后,我们发现有些导入语句就包含几万条记录,导入时间需要耗时几十分钟。

对比之前使用MySQL,一次导入只需几分钟甚至几十秒钟就完成了,而迁到TiDB却需要双倍甚至几倍的时间才完成,几台机器组成的TiDB集群反而还不如一台MySQL机器。

这肯定不是打开TiDB的正确姿势,我们需要找到原因,对其进行优化。

个推分享两个调优技巧,让TiDB性能提速千倍! 单个服务器负载过高

通过查看监控,发现服务器负载压力都是在其中一台机器上(如上图,红色线框里标注的这台服务器承担主要压力),这说明我们目前并没有充分利用到所有的资源,未能发挥出TiDB作为分布式数据库的性能优势。

打开TiDB的正确使用姿势

首先优化配置参数

具体如何优化呢?我们首先从配置参数方面着手。众所周知,很多配置参数都是使用系统的默认参数,这并不能帮助我们合理地利用服务器的性能。通过深入查阅官方文档及多轮实测,我们对TiDB配置参数进行了适当调整,从而充分利用服务器资源,使服务器性能达到理想状态。

下表是个推对TiDB配置参数进行调整的说明,供参考:

个推分享两个调优技巧,让TiDB性能提速千倍!

重点解决热点问题

调整配置参数只是基础的一步,我们还是要从根本上解决服务器负载压力都集中在一台机器上的问题。可是如何解决呢?这就需要我们先深入了解TiDB的架构,以及TiDB中表保存数据的内在原理。

在TiDB的整个架构中,分布式数据存储引擎TiKV Server负责存储数据。在存储数据时,TiKV采用范围切分(range)的方式对数据进行切分,切分的最小单位是region。每个region有大小限制(默认上限为96M),会有多个副本,每一组副本,成为一个raft group。每个raft group中由leader负责执行这个块数据的读&写。leader会自动地被PD组件(Placement Driver,简称“PD”,是整个集群的管理模块)均匀调度在不同的物理节点上,用以均分读写压力,实现负载均衡。

个推分享两个调优技巧,让TiDB性能提速千倍!

TiDB架构图(图片来源于TiDB官网)

TiDB会为每个表分配一个TableID,为每一个索引分配一个IndexID,为每一行分配一个RowID(默认情况下,如果表使用整数型的Primary Key,那么会用Primary Key的值当做RowID)。同一个表的数据会存储在以表ID开头为前缀的一个range中,数据会按照RowID的值顺序排列。在插入(insert)表的过程中,如果RowID的值是递增的,则插入的行只能在末端追加。

当Region达到一定的大小之后会进行分裂,分裂之后还是只能在当前range范围的末端追加,并永远仅能在同一个Region上进行insert操作,由此形成热点(即单点的过高负载),陷入TiDB使用的“反模式”。

常见的increment类型自增主键就是按顺序递增的,默认情况下,在主键为整数型时,会将主键值作为RowID ,此时RowID也为顺序递增,在大量insert时就会形成表的写入热点。同时,TiDB中RowID默认也按照自增的方式顺序递增,主键不为整数类型时,同样会遇到写入热点的问题。

在使用MySQL数据库时,为了方便,我们都习惯使用自增ID来作为表的主键。因此,将数据从MySQL迁移到TiDB之后,原来的表结构都保持不变,仍然是以自增ID作为表的主键。这样就造成了批量导入数据时出现TiDB写入热点的问题,导致Region分裂不断进行,消耗大量资源。

对此,在进行TiDB优化时,我们从表结构入手,对以自增ID作为主键的表进行重建,删除自增ID,使用TiDB隐式的_tidb_rowid列作为主键,将

create table t (a int primary key auto_increment, b int);

改为:

create table t (a int, b int)SHARD_ROW_ID_BITS=4 PRE_SPLIT_REGIONS=2

通过设置SHARD_ROW_ID_BITS,将RowID打散写入多个不同的Region,从而缓解写入热点问题。

此处需要注意,SHARD_ROW_ID_BITS值决定分片数量:

  • SHARD_ROW_ID_BITS = 0 表示 1 个分片
  • SHARD_ROW_ID_BITS = 4 表示 16 个分片
  • SHARD_ROW_ID_BITS = 6 表示 64 个分片

SHARD_ROW_ID_BITS值设置的过大会造成RPC请求数放大,增加CPU和网络开销,这里我们将SHARD_ROW_ID_BITS设置为4。

PRE_SPLIT_REGIONS指的是建表成功后的预均匀切分,我们通过设置PRE_SPLIT_REGIONS=2,实现建表成功后预均匀切分2^(PRE_SPLIT_REGIONS)个Region。

经验总结

· 以后新建表禁止使用自增主键,

考虑使用业务主键

· 加上参数SHARD_ROW_ID_BITS = 4 PRE_SPLIT_REGIONS=2

此外,由于TiDB的优化器和MySQL有一定差异,出现了相同的SQL语句在MySQL里可以正常执行,而在TiDB里执行慢的情况。我们针对特定的慢SQL进行了深入分析,并针对性地进行了索引优化,取得了不错的成效。

优化成果

通过慢SQL查询平台可以看到,经过优化,大部分的导入在秒级时间内就完成了,相比原来的数十分钟,实现了数千倍的性能提升。

个推分享两个调优技巧,让TiDB性能提速千倍! 慢SQL优化结果

同时,性能监控图表也显示,在负载高的时刻,是几台机器同时高,而不再是单独一台升高,这说明我们的优化手段是有效的,TiDB作为分布式数据库的优势得以真正体现。

个推分享两个调优技巧,让TiDB性能提速千倍! 优化后,实现服务器负载均衡

总结

作为一种新型分布式关系型数据库,TiDB能够为OLTP(Online Transactional Processing)和OLAP(Online Analytical Processing)场景提供一站式的解决方案。个推不仅使用TiDB进行海量数据高效查询,同时也展开了基于TiDB进行实时数据分析、洞察的探索。

后续更多“大数据降本提效”的干货分享,请大家持续锁定个推技术实践公众号~

点赞
收藏
评论区
推荐文章
个推分享Spark性能调优指南:性能提升60%↑ 成本降低50%↓
前言Spark是目前主流的大数据计算引擎,功能涵盖了大数据领域的离线批处理、SQL类处理、流式/实时计算、机器学习、图计算等各种不同类型的计算操作,应用范围与前景非常广泛。作为一种内存计算框架,Spark运算速度快,并能够满足UDF、大小表Join、多路输出等多样化的数据计算和处理需求。作为国内专业的数据智能服务商,个推从早期的1.3版本便引入Spark,
TiDB与MySQL的SQL差异及执行计划简析
TiDB作为NewSQL,其在对MySQL(SQL92协议)的兼容上做了很多,MySQL作为当下使用较广的事务型数据库,在IT界尤其是互联网间使用广泛,那么对于开发人员来说,1)两个数据库产品在SQL开发及调优的过程中,都有哪些差异?在系统迁移前需要提前做哪些准备?2)TiDB的执行计划如何查看,如何SQL调优?本文做了一个简要归纳,欢迎查阅交流。
Stella981 Stella981
3年前
Linux上TCP的几个内核参数调优
Linux作为一个强大的操作系统,提供了一系列内核参数供我们进行调优。光TCP的调优参数就有50多个。在和线上问题斗智斗勇的过程中,笔者积累了一些在内网环境应该进行调优的参数。在此分享出来,希望对大家有所帮助。调优清单好了,在这里先列出调优清单。请记住,这里只是笔者在内网进行TCP内核参数调优的经验,仅供参考。同时,笔者还会在余下的博客里面
Stella981 Stella981
3年前
HBase2.0新特性详解
作者|个推大数据运维工程师 行者!(https://uploadimages.jianshu.io/upload_images/4095986efd0b4d43ade1368?imageMogr2/autoorient/strip%7CimageView2/2/w/1240)升级背景个推作为专业的数据智能服务商,在业务开展过程中存
Stella981 Stella981
3年前
JVM性能调优详解
前面我们学习了整个JVM系列,最终目标的不仅仅是了解JVM的基础知识,也是为了进行JVM性能调优做准备。这篇文章带领大家学习JVM性能调优的知识。性能调优性能调优包含多个层次,比如:架构调优、代码调优、JVM调优、数据库调优、操作系统调优等。架构调优和代码调优是JVM调优的基础,其中架构调优是对系统影响最大的。性能调优基本上按照以下
Stella981 Stella981
3年前
Flink 在又拍云日志批处理中的实践
日前,由又拍云举办的大数据与AI技术实践|OpenTalk杭州站沙龙在杭州西溪科创园顺利举办。本次活动邀请了有赞、个推、方得智能、又拍云等公司核心技术开发者,现场分享各自领域的大数据技术经验和心得。以下内容整理自又拍云资深开发工程师张召现场分享:张召,资深开发工程师,目前负责又拍云CDN的刷新预热、日志处理和运维平台开发。熟悉OpenRes
Stella981 Stella981
3年前
4000余字为你讲透Codis内部工作原理
一、引言Codis是一个分布式Redis解决方案,可以管理数量巨大的Redis节点。个推作为专业的第三方推送服务商,多年来专注于为开发者提供高效稳定的消息推送服务。每天通过个推平台下发的消息数量可达百亿级别。基于个推推送业务对数据量、并发量以及速度的要求非常高,实践发现,单个Redis节点性能容易出现瓶颈,综合考虑各方面因素后,我们选择了Cod
个推基于Flink SQL建设实时数仓实践
作为一家数据智能企业,个推在服务垂直行业客户的过程中,会涉及到很多数据实时计算和分析的场景,比如在服务开发者时,需要对App消息推送的下发数、到达数、打开率等后效数据进行实时统计;在服务政府单位时,需要对区域内实时人口进行统计和画像分析。为了更好地支撑大数据业务发展,个推也建设了自己的实时数仓。相比Storm、Spark等实时处理框架,Flink不仅具有高吞
如何使Codis存储成本降低90%?个推:去吧,Pika!
作为一家数据智能公司,个推不仅拥有海量的关系型数据,也积累了丰富的keyvalue等非关系型数据资源。个推采用Codis保存大规模的keyvalue数据,随着公司kv类型数据的不断增加,使用原生的Codis搭建的集群所花费的成本越来越高。在一些对性能响应要求不高的场景中,个推计划采用新的存储和管理方案以有效兼顾成本与性能。经过选型,个推引入了360开源的存储
京东云开发者 京东云开发者
2个月前
大数据从业者必知必会的Hive SQL调优技巧
大数据从业者必知必会的HiveSQL调优技巧摘要:在大数据领域中,HiveSQL被广泛应用于数据仓库的数据查询和分析。然而,由于数据量庞大和复杂的查询需求,HiveSQL查询的性能往往不尽人意。本文针对HiveSQL的性能优化进行深入研究,提出了一系列可行