作者介绍：冀浩东，转转公司数据库负责人，负责转转公司整体的数据库经营。
初引入 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）。