TiDB 4.0 新特性在电商行业的探索

Easter79
• 阅读 665

作者介绍:冀浩东,转转公司数据库负责人,负责转转公司整体的数据库运营。

初引入 TiDB 解决了哪些问题?

转转使用 TiDB 主要解决了两个问题,一个是分库分表问题,另一个是运维复杂度。

分库分表是一个非常普遍的问题,会增加我们业务逻辑的复杂性,并且多维度的 mapping 可能导致我们整体性能的下降。有了 TiDB 我们可以不用再考虑分库分表,不再需要写那么多的复杂逻辑。

对于运维复杂度来说,TiDB 可以做到快速的水平扩展,无需 DBA 进行复杂的数据搬迁,也无需业务进行流量迁移,并且大表的 Online DDL,基本上对于业务感知力度不大。

产生的新问题

引入 TiDB 后,随之也带来了一些新的问题。

  • 部署慢、管理难。TiDB Ansible 在管理多个 TiDB 集群的时候,会有各种各样不同的异常,这会极大的增加我们的运维复杂度。

  • 热点无法快速定位。对于电商场景,数据热点是一个比较常见的问题。因为 TiDB 节点众多,无法快速定位热点 KEY,需要查询各个节点的日志, 逐步排查, 排查成本较高。

  • 无法快速查看集群状态。监控项太多,并且日志都比较分散,某一时间我们要确认集群状态,只能是一步一步来,慢慢的分析,无法迅速对集群异常进行定位。

  • 数据抽取会增加线上响应延时。这是一个非常常见的问题,因为数据抽取也影响我们 TiKV 的性能。

  • 超大集群无法做到有效的备份。对于超大集群的快速的备份和恢复,其实是一个亟待解决的问题。之前,我们在数据量规模非常大的情况下才会用到 TiDB,这个时候备份其实是非常迫切的。之前我们一直是逻辑备份,但是逻辑备份对于我们来讲有效性并不高。

  • TiKV 线程池的配置复杂及对业务的影响。部署 TiKV 时会配置线程数量,需要配置 3 个优先级;对于不同业务的场景需要配置 readpool.storage / readpool.coprocessor 两个 readpool 线程池;。随着我们业务的发展与迭代,我们的 SQL 也都不一样,所以在使用 readpool 的时候,方式也不一样,并且如果调整线程配置,会不同程度的影响业务访问。

TiDB 4.0 解决了哪些问题?

那我们接下来看一下 TiDB 4.0 版本可以解决哪些问题。

集群部署管理问题——TiUP

TiDB 4.0 新特性在电商行业的探索

之前在使用 TiDB Ansible 管理的时候,其实是比较困难的,并且 TiDB Ansible 自身也存在一些问题。TiDB 4.0 开发了一个全新的组件管理工具——TiUP,这个工具目前在体验上是非常好的,我们在一分钟内就可以部署完成 3 个 TiDB,3 个 PD, 3 个 TiKV 和 1 个 TiFlash,这个效果是非常惊艳的,而且 TiUP 也有大量的参数可以查看我们集群的状态。我们要特别提醒一点,TiFlash 的端口管理非常复杂,有特别多的端口,大家在使用的时候一定要做好 TiFlash 端口管理。

数据热点问题——Key Visualizer

TiDB 4.0 新特性在电商行业的探索

在早期,热点问题我们只能通过各种日志去排查,然后慢慢的分析,再找到它。现在有一个新的可视化工具叫 Key Visualizer,它可以快速直观的观察我们整个集群的热点情况。如上图所示,我们将线上集群,通过数据和流量的复制过来以后,把新的流量导过来。我们可以看到任意时间点集群的写入情况,例如我们可以看到当前情况下,字节写入量,哪个库,哪张表,以及它的 rowkey。在右图,通过集群的明亮程度这个判断指标,就可以看到我们整体 KEY 的一个繁忙程度,这张图整体来讲,这是一个比较符合预期的状态,写入整体比较均匀。如果是热点的话,可能会出现一条线,可以明显的看到我们的热点 KEY,有了一个工具,我们可以快速的找到热点 KEY。

快速查看集群状态问题——TiDB DashBoard

针对集群状态无法快速定位的问题,TiDB 4.0 有一个新的组件叫 TiDB DashBoard。通过 TiDB DashBoard 以及 TiDB 的集群的诊断报告,我们可以快速拿到集群的基本信息、负载信息、组件信息、配置信息以及错误信息,这些信息其实已经非常的丰富了,对于我们来讲是非常有效的,可以稳准狠的找到我们的集群的异常。

TiDB 4.0 新特性在电商行业的探索

TiDB DashBoard 是 TiDB 4.0 特别有亮点的一个功能,它可以实时的获取到我们集群的信息。上图是 DashBoard 概况页面,里面包含了 QPS、响应延迟、节点的状态,以及告警相关的一些内容。通过概况, DBA 可以迅速的查到集群的状态,快速定位问题,提高了应用性,可以说 TiDB 4.0 整体的应用性已经非常高了。

TiDB 4.0 新特性在电商行业的探索

慢查询可以说是里程碑的一个功能。之前一直在吐槽 TiDB 慢查询的问题,我们从 1.0 吐槽到 4.0,但是 4.0 有了 DashBoard 后,可以指定数据库,查看不同的慢查询,也可以快速的定位我们的慢查询。我们不再需要自己 ETL,也不需要自己再上机器,就可以快速的定位到慢查询,而且包含排序、执行时间等信息,这是对于即将要使用 TiDB 的公司来讲,一个非常利好的消息。

TiDB 4.0 新特性在电商行业的探索

我们可以通过慢查询找到我们的慢查询的列表,有了列表之后,我们就可以知道具体的 SQL 语句。SQL 语句信息包含 SQL 语句的模板、指纹 ID、样例、执行计划,以及事物相关的一些指标,这个指标对我们来讲是非常难得的。在我们自己做 ETL 的时候,其实很多指标和信息是拿不到的,但是现在通过 SQL 语句分析,我们可以看到慢查询的各个执行阶段,也可以看到各个阶段的执行时间,提高了我们整体 SQL 分析的体验。

TiDB 4.0 新特性在电商行业的探索

现在还添加了日志搜索功能。在早期我们做 ETL 的时候,需要检索各种各样的日志,然后再去分析,现在有了这个日志搜索这个功能,我们不再需要登陆机器了,也不再需要去做对应的系统来分析日志,这会极大的降低我们的人力成本和开发成本。有了这个工具以后,我们可以指定时间段,指定日志等级,还可以指定它的节点,通过节点可以检索到我们最新的一些日志,这个对我们来讲是非常友好的。

数据抽取增加线上响应延时问题——TiFlash 节点

TiDB 4.0 新特性在电商行业的探索

现在我们启用了 TiFlash 节点来解决数据抽取会增加线上响应延时的问题。TiFlash 的特性包括异步复制、一致性、智能选择和计算加速,具体原理就不讲了,我们主要讲一下在转转的使用场景。在转转主要的使用场景是供数节点和物理隔离,相当于在新的机器上加了一个 TiKV 的节点,我们做了一个分离,不同的请求走不同的后端数据节点,这样在进行数据抽取的时候,它不会影响到整体的线上性能。并且这是智能选择的,可以根据我们业务、SQL 的复杂度,自己去判断该走 TiKV 还是走 TiFlash,线上的就走 TiKV,线下的就走 TiFlash,这个是强制的。

超大集群无法做到有效备份——Backup & Restore

分布式备份恢复工具 Backup & Restore 解决了超大集群无法做到有效备份的问题。通过我们做的测试,在万兆网卡的环境下,300GB 的数据,限速 120MB/s 的情况下,备份到网络文件系统,耗时不到 10 分钟。在同样限速 120MB/s 的条件下,通过网络文件系统进行数据恢复,我们测试的结果是耗时约 12 分钟,可以说是极大的降低了我们备份恢复的时间。并且还有一个关键因素,就是备份的速度完全取决于我们 TiKV 的多少,TiKV 越多,我们的备份速度越快,恢复的速度也越快。

TiKV 线程池的配置问题——unified read pool

TiDB 4.0 新特性在电商行业的探索

TiDB 4.0 的一个新的优化功能就是 unified read pool 的线程池。在 4.0 之前,我们的 readpool storage 和 coprocessor 是需要自己配置的,调整的时候也是自己动态去调整,而且每次调整可能会影响到业务,这个是比较痛的一个点。unified read pool 将 storage 和 coprocessor 这两个进行了一个合并,合并到一个线程池里面。我们使用 storage 还是 coprocessor 是由我们的 SQL 自己来判断,如果说我们需要用 storage,那我们就用 storage,需要 coprocessor,我们就用 coprocessor。这不仅提高了我们的使用体验,也解决了我们资源分配不均匀的问题。上图展示了我们如何开启 unified read pool 的线程池的配置。

未来规划

TiDB 4.0 版本发布了很多实用性的功能,例如 TiDB Dashboard、TiFlash、unified 线程池等,提高了 TiDB 整体的易用性,转转未来将全面计划升级到 v4.0, 一定程度的释放人力资源,降低我们的运维复杂度。

本文整理自冀浩东在 TiDB DevCon 2020 上的演讲,大会相关视频可以关注官方 Bilibli 账号主页(ID:TiDB_Robot)。

点赞
收藏
评论区
推荐文章
blmius blmius
3年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
皕杰报表之UUID
​在我们用皕杰报表工具设计填报报表时,如何在新增行里自动增加id呢?能新增整数排序id吗?目前可以在新增行里自动增加id,但只能用uuid函数增加UUID编码,不能新增整数排序id。uuid函数说明:获取一个UUID,可以在填报表中用来创建数据ID语法:uuid()或uuid(sep)参数说明:sep布尔值,生成的uuid中是否包含分隔符'',缺省为
待兔 待兔
2个月前
手写Java HashMap源码
HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程22
Wesley13 Wesley13
2年前
Java日期时间API系列31
  时间戳是指格林威治时间1970年01月01日00时00分00秒起至现在的总毫秒数,是所有时间的基础,其他时间可以通过时间戳转换得到。Java中本来已经有相关获取时间戳的方法,Java8后增加新的类Instant等专用于处理时间戳问题。 1获取时间戳的方法和性能对比1.1获取时间戳方法Java8以前
Stella981 Stella981
2年前
Asp.NetCore 3.1 EFCore处理Mysql的分库分表
一、什么情况下需要分库分表?Mysql单表数据量超过500万条。二、Asp.netCore技术栈,分库分表的解决方案有哪些?1、阿里云的DRDS2、Mycat 数据库分库分表中间件;3、TiDB;三、以上3种解决方案各自的特点:1、阿里云DRDS是收费的商业版,价格稍贵,但是比S
Easter79 Easter79
2年前
Twitter的分布式自增ID算法snowflake (Java版)
概述分布式系统中,有一些需要使用全局唯一ID的场景,这种时候为了防止ID冲突可以使用36位的UUID,但是UUID有一些缺点,首先他相对比较长,另外UUID一般是无序的。有些时候我们希望能使用一种简单一些的ID,并且希望ID能够按照时间有序生成。而twitter的snowflake解决了这种需求,最初Twitter把存储系统从MySQL迁移
Wesley13 Wesley13
2年前
TiDB 4.0 新特性在电商行业的探索
作者介绍冀浩东,转转公司数据库负责人,负责转转公司整体的数据库运营。初引入TiDB解决了哪些问题?转转使用TiDB主要解决了两个问题,一个是分库分表问题,另一个是运维复杂度。分库分表是一个非常普遍的问题,会增加我们业务逻辑的复杂性,并且多维度的mapping可能导致我们整体性能的下降。有了
Easter79 Easter79
2年前
TiDB 在转转的业务实战
作者:陈维,转转优品技术部RD。开篇世界级的开源分布式数据库TiDB自2016年12月正式发布第一个版本以来,业内诸多公司逐步引入使用,并取得广泛认可。对于互联网公司,数据存储的重要性不言而喻。在NewSQL数据库出现之前,一般采用单机数据库(比如MySQL)作为存储,随着数据量的增加,“分库分表”是早晚面临的问题,
Easter79 Easter79
2年前
TiDB 分布式数据库在转转公司的应用实践
作者:孙玄,转转公司首席架构师;陈东,转转公司资深工程师;冀浩东,转转公司资深DBA。公司及业务架构介绍转转二手交易网——把家里不用的东西卖了变成钱,一个帮你赚钱的网站。由腾讯与58集团共同投资。为海量用户提供一个有担保、便捷的二手交易平台。转转是2015年11月12日正式推出的APP,遵循“用户第一”
Wesley13 Wesley13
2年前
MySQL部分从库上面因为大量的临时表tmp_table造成慢查询
背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_
Easter79
Easter79
Lv1
今生可爱与温柔,每一样都不能少。
文章
2.8k
粉丝
5
获赞
1.2k