手记

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

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

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

数据热点问题——Key Visualizer

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

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

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

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

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

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

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

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

现在我们启用了 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 的一个新的优化功能就是 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)。

0人推荐
随时随地看视频
慕课网APP