TiDB 4.0 新特性在电商行业的探索
作者介绍：冀浩东 ， 转转公司数据库负责人 ， 负责转转公司整体的数据库运营 。 初引入TiDB解决了哪些问题？
转转使用TiDB主要解决了两个问题 ， 一个是分库分表问题 ， 另一个是运维复杂度 。
分库分表是一个非常普遍的问题 ， 会增加我们业务逻辑的复杂性 ， 并且多维度的mapping可能导致我们整体性能的下降 。 有了TiDB我们可以不用再考虑分库分表 ， 不再需要写那么多的复杂逻辑 。
对于运维复杂度来说 ， TiDB可以做到快速的水平扩展 ， 无需DBA进行复杂的数据搬迁 ， 也无需业务进行流量迁移 ， 并且大表的OnlineDDL ， 基本上对于业务感知力度不大 。
产生的新问题引入TiDB后 ， 随之也带来了一些新的问题 。
1.部署慢、管理难 。 TiDBAnsible在管理多个TiDB集群的时候 ， 会有各种各样不同的异常 ， 这会极大的增加我们的运维复杂度 。
2.热点无法快速定位 。 对于电商场景 ， 数据热点是一个比较常见的问题 。 因为TiDB节点众多 ， 无法快速定位热点KEY ， 需要查询各个节点的日志 ， 逐步排查 ， 排查成本较高 。
3.无法快速查看集群状态 。 监控项太多 ， 并且日志都比较分散 ， 某一时间我们要确认集群状态 ， 只能是一步一步来 ， 慢慢的分析 ， 无法迅速对集群异常进行定位 。
4.数据抽取会增加线上响应延时 。 这是一个非常常见的问题 ， 因为数据抽取也影响我们TiKV的性能 。
5.超大集群无法做到有效的备份 。 对于超大集群的快速的备份和恢复 ， 其实是一个亟待解决的问题 。 之前 ， 我们在数据量规模非常大的情况下才会用到TiDB ， 这个时候备份其实是非常迫切的 。 之前我们一直是逻辑备份 ， 但是逻辑备份对于我们来讲有效性并不高 。
6.TiKV线程池的配置复杂及对业务的影响 。 部署TiKV时会配置线程数量 ， 需要配置3个优先级；对于不同业务的场景需要配置readpool.storage/readpool.coprocessor两个readpool线程池； 。 随着我们业务的发展与迭代 ， 我们的SQL也都不一样 ， 所以在使用readpool的时候 ， 方式也不一样 ， 并且如果调整线程配置 ， 会不同程度的影响业务访问 。
TiDB4.0解决了哪些问题？那我们接下来看一下TiDB4.0版本可以解决哪些问题 。
1.集群部署管理问题——TiUP
文章图片
之前在使用TiDBAnsible管理的时候 ， 其实是比较困难的 ， 并且TiDBAnsible自身也存在一些问题 。 TiDB4.0开发了一个全新的组件管理工具——TiUP ， 这个工具目前在体验上是非常好的 ， 我们在一分钟内就可以部署完成3个TiDB ， 3个PD ， 3个TiKV和1个TiFlash ， 这个效果是非常惊艳的 ， 而且TiUP也有大量的参数可以查看我们集群的状态 。 我们要特别提醒一点 ， TiFlash的端口管理非常复杂 ， 有特别多的端口 ， 大家在使用的时候一定要做好TiFlash端口管理 。
2.数据热点问题——KeyVisualizer
文章图片
在早期 ， 热点问题我们只能通过各种日志去排查 ， 然后慢慢的分析 ， 再找到它 。 现在有一个新的可视化工具叫KeyVisualizer ， 它可以快速直观的观察我们整个集群的热点情况 。 如上图所示 ， 我们将线上集群 ， 通过数据和流量的复制过来以后 ， 把新的流量导过来 。 我们可以看到任意时间点集群的写入情况 ， 例如我们可以看到当前情况下 ， 字节写入量 ， 哪个库 ， 哪张表 ， 以及它的rowkey 。 在右图 ， 通过集群的明亮程度这个判断指标 ， 就可以看到我们整体KEY的一个繁忙程度 ， 这张图整体来讲 ， 这是一个比较符合预期的状态 ， 写入整体比较均匀 。 如果是热点的话 ， 可能会出现一条线 ， 可以明显的看到我们的热点KEY ， 有了一个工具 ， 我们可以快速的找到热点KEY 。
3.快速查看集群状态问题——TiDBDashBoard
针对集群状态无法快速定位的问题 ， TiDB4.0有一个新的组件叫TiDBDashBoard 。 通过TiDBDashBoard以及TiDB的集群的诊断报告 ， 我们可以快速拿到集群的基本信息、负载信息、组件信息、配置信息以及错误信息 ， 这些信息其实已经非常的丰富了 ， 对于我们来讲是非常有效的 ， 可以稳准狠的找到我们的集群的异常 。
文章图片
TiDBDashBoard是TiDB4.0特别有亮点的一个功能 ， 它可以实时的获取到我们集群的信息 。 上图是DashBoard概况页面 ， 里面包含了QPS、响应延迟、节点的状态 ， 以及告警相关的一些内容 。 通过概况 ， DBA可以迅速的查到集群的状态 ， 快速定位问题 ， 提高了应用性 ， 可以说TiDB4.0整体的应用性已经非常高了 。
文章图片
慢查询可以说是里程碑的一个功能 。 之前一直在吐槽TiDB慢查询的问题 ， 我们从1.0吐槽到4.0 ， 但是4.0有了DashBoard后 ， 可以指定数据库 ， 查看不同的慢查询 ， 也可以快速的定位我们的慢查询 。 我们不再需要自己ETL ， 也不需要自己再上机器 ， 就可以快速的定位到慢查询 ， 而且包含排序、执行时间等信息 ， 这是对于即将要使用TiDB的公司来讲 ， 一个非常利好的消息 。
文章图片
我们可以通过慢查询找到我们的慢查询的列表 ， 有了列表之后 ， 我们就可以知道具体的SQL语句 。 SQL语句信息包含SQL语句的模板、指纹ID、样例、执行计划 ， 以及事物相关的一些指标 ， 这个指标对我们来讲是非常难得的 。 在我们自己做ETL的时候 ， 其实很多指标和信息是拿不到的 ， 但是现在通过SQL语句分析 ， 我们可以看到慢查询的各个执行阶段 ， 也可以看到各个阶段的执行时间 ， 提高了我们整体SQL分析的体验 。
文章图片
现在还添加了日志搜索功能 。 在早期我们做ETL的时候 ， 需要检索各种各样的日志 ， 然后再去分析 ， 现在有了这个日志搜索这个功能 ， 我们不再需要登陆机器了 ， 也不再需要去做对应的系统来分析日志 ， 这会极大的降低我们的人力成本和开发成本 。 有了这个工具以后 ， 我们可以指定时间段 ， 指定日志等级 ， 还可以指定它的节点 ， 通过节点可以检索到我们最新的一些日志 ， 这个对我们来讲是非常友好的 。
4.数据抽取增加线上响应延时问题——TiFlash节点
文章图片
现在我们启用了TiFlash节点来解决数据抽取会增加线上响应延时的问题 。 TiFlash的特性包括异步复制、一致性、智能选择和计算加速 ， 具体原理就不讲了 ， 我们主要讲一下在转转的使用场景 。 在转转主要的使用场景是供数节点和物理隔离 ， 相当于在新的机器上加了一个TiKV的节点 ， 我们做了一个分离 ， 不同的请求走不同的后端数据节点 ， 这样在进行数据抽取的时候 ， 它不会影响到整体的线上性能 。 并且这是智能选择的 ， 可以根据我们业务、SQL的复杂度 ， 自己去判断该走TiKV还是走TiFlash ， 线上的就走TiKV ， 线下的就走TiFlash ， 这个是强制的 。
5.超大集群无法做到有效备份——Backup&Restore
【TiDB 4.0 新特性在电商行业的探索】分布式备份恢复工具Backup&Restore解决了超大集群无法做到有效备份的问题 。 通过我们做的测试 ， 在万兆网卡的环境下 ， 300GB的数据 ， 限速120MB/s的情况下 ， 备份到网络文件系统 ， 耗时不到10分钟 。 在同样限速120MB/s的条件下 ， 通过网络文件系统进行数据恢复 ， 我们测试的结果是耗时约12分钟 ， 可以说是极大的降低了我们备份恢复的时间 。 并且还有一个关键因素 ， 就是备份的速度完全取决于我们TiKV的多少 ， TiKV越多 ， 我们的备份速度越快 ， 恢复的速度也越快 。
推荐阅读
- |B550超强兼容性PCIe 4.0战未来这才是高性价比
- 华为鸿蒙系统|噱头还是真有用？如何看待PCIe 4.0
- 民生教育(01569)中期母公司拥有人应占溢利约2.36亿元 同比增14.09%
- 光明房产7.5亿元中期票据发行完成 利率4.03%
- 华发集团：7亿元公司债券于深交所上市 票面利率4.03%
- 品车闻百魅|红旗LS5街头再现，“夔龙”格栅气场强劲，还配4.0升V8全铝发动机
- 吉利迈向4.0时代将带来什么
- 英特尔|华擎两款A520主板曝光，确认不支持PCI-E 4.0
- | 腾讯安全天御荣获“联邦学习应用奖”，助力信贷风控开启4.0时代
- ABT RSQ8-R亮相！搭4.0T动力大涨，内饰运动，仅限125台选购