共计 3451 个字符，预计需要花费 9 分钟才能阅读完成。
作者介绍：冀浩东，转转公司数据库负责人，负责转转公司整体的数据库经营。
初引入 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）。
