TiDB在我司的实践

TiDB 是什么？

是什么我们来看TiDB 官网的介绍，介绍如下：

TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP）的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。
一句话总结：TiDB是一个在海量数据下不需要进行Sharding、并且同时具备OLAP和OLTP能力、兼容MySQL协议的分布式数据库。

我们为什么要使用TiDB？

加我们使用TiDB的原因主要有以下几点：

1. 在MySQL层面通过分库分表的方式，拆分出来，但这对业务和 DBA 来说都是不小的工作量，最痛苦的无异于这些大表的改变；
2. 无论是单表上 T，还是分库分表，对一张大表执行 DDL 的代价是非常大的；
3. 针对业务爆发式增长的数据量，我们开始调研选型是否有其他数据库可以代替传统的 MySQL；
4. 通过调研我们了解到 TiDB，迁移平滑，基本上无需业务变动代码，完全的事务 ACID 支持，分布式的架构，自带高可用、Online DDL；
5. TiDB 在公司集团引入的最早时间是2018年中旬，数据仓储前期评估数据量规模在亿级别以下，不需要直接使用TiDB来存储；
6. TiDB 百分之九十九兼容 MySQL 协议，在数据层面业务、开发几乎不用做任何大的代码改动；
7. 我们的业务量暴增，数据太大，想寻求一种在存储层只需要加节点就搞定，不想改造更多的业务代码；
8. 我们业务本身是查询统计这块的业务场景比较多，正好TiDB对于OLAP的支撑很好！
9. 在一些复杂的BI统计需求下，TiDB的查询性能比MySQL更优秀；
10. 前期的好几套业务系统已经基于我们的仓储数据开发了相关的三方业务，如果数据仓库数据结构这块的改动涉及到多方的改动，改造成本太高；

TiDB 的存在是为了解决什么问题？

1. 重点解决MySQL 的单机性能和容量无法线性和灵活扩展的问题；
2. 兼容MySQL协议（对于原始业务SQL无需做改造）；
3. 可在线扩展（数据分片支持分裂和自动迁移，对业务使用方来说无感知）；
4. 强一致的分布式事务保证（支持跨节点、跨分片的分布式事务，并且事务保证强一致）；
5. 支持MySQL二级索引；
6. 支持OLAP+OLTP场景；
7. 跨机房高可用，任何一个机房挂掉，服务自动切换；
8. 支持海量数据存储，不需要在业务层做分库分表，TiDB自身底层支持，业务使用人员关注业务即可，数据 Sharding 的事情交给TiDB来做，数据爆发增长，只需要增加 TiKV 节点即可，TiDB本身支持数据的自动均衡；

TiDB 的原理以及架构是怎样的？

MySQL的一些集群方案和数据库中间件都在视图解决当表条目变大时，查询性能会出现严重下降的问题。TiDB的这套架构适用于大规模数据量的存储和查询，重点关注以下几个核心组件：

PD

• 保存数据库中的逻辑表到真实TiKV节点中数据分布的关系；
• 负责对TiKV集群做调度和负载均衡；
• 分配全局事务ID;
• 负责TiDB集群的元信息数据管理；

TiDB

• 负责接收SQL检查、语法解析；
• 从原始SQL到逻辑查询的转换；
• 借助PD将逻辑查询转换为物理查询；
• 从TiKV节点查询数据后加工、计算并返回；

TiKV

• 分布式KV存储引擎；

使用TiDB的过程中遇到了那些问题，如何解决？

问题1： TiDB线上报 “pd server timeout”
处理：业务测在代码中加上相关超时重试的处理，将 TiDB 机器上 min_free_kbytes 从默认的 66M 调成 512M，留更多内存给内核用。

问题2：TIDB 生产环境发生 OOM问题。
处理方案1： 将OLAP频繁的SQL业务放到一个单独的TiDB集群，与现有的一套TiDB集群进行隔离，防止一个业务的OLAP SQL 影响到其他的业务；
处理方案2： oom-action 配置为 cancel，kill 使用内存超过阈值的 SQL，单条SQL使用的内存阈值调整配置文件；

问题3：TiDB线上内存使用过大
处理：抓取内存 profile 分析，怀疑是 TiDB 2.1.8 版本一个 goroutine 泄漏的 bug 引起，后面通过升级TiDB版本到2.1.11 版本。

问题4：TiKV 热点问题，region 分布不均匀
处理：某一个周末发现有3台TiKV的CPU使用率均达到100%，最终定位到原因为PD各个调度器抢占的问题，升级TiDB版本到2.1.11 版本。

问题5：重启TiKV调整参数，业务侧出现”tikv timeout“的异常
处理：由于强制关闭了tikv集群，造成region 的自动选主，”tikv timeout“属于正常现象。

问题6： Pd Server Timeout
处理：etcd bug引起。TiDB已经向etcd开发提出issue，等待回复及改进。issue地址：https://github.com/etcd-io/et...

问题7：tidb 实例频繁重启
处理：txn-latch-local 是一个关于事务内存锁，缓解事务冲突的功能，这个功能在 tidb 产品后续优化了事务的并发且引入了悲观锁机制之后，已经不再维护了。需要关闭 txn-local-latch ，即设置 txn-local-latch = false

问题8：tidb实例网卡流量巨大20Gbps 持续将网卡打满
处理：改写sql 逻辑，调整每次拉取的记录大小；

问题9：tidb 某些 sql 会出现索引失效
处理：对于发现失效的SQL，使用HINT这种方式强制指定索引解决。

问题10：tidb用户权限问题只有增删改查权限却可以truncate表
处理：truncate权限未做好隔离,问题在2.1.7版本中进行了修复

TiDB 商业版目前已知的一些问题？

1. TiDB 热点问题：从 TiDB 编码规则可知，同一个表的数据会在以表 ID 开头为前缀的一个 range 中，数据的顺序按照 RowID 的值顺序排列。在表 insert 的过程中如果 RowID 的值是递增的，则插入的行只能在末端追加。当 Region 达到一定的大小之后会进行分裂，分裂之后还是只能在 range 范围的末端追加，永远只能在一个 Region 上进行 insert 操作，形成热点。可以通过改造小表为 hash 分区表来保证数据均匀地分散到一定数量的分区来解决。TiDB 4.0 PD 会提供 Load Base Splitting 策略，除了根据 Region 的大小进行 Region 分裂之外，还会根据访问 QPS 负载自动分裂频繁访问的小表的 Region。 4.0 引入 auto_random 特性，彻底解决数据打散问题。
2. TiDB 乐观锁事务提交：事务最终提交 commit 时才会检测冲突,传统的使用声明式事务控制无效。显式事务中 DML 语句返回的 affected rows 不可信。
3. 默认会对唯一约束进行惰性检查。通过在事务提交时再进行批量检查，目的是能够减少网络开销、提升性能。
4. Delete 大量数据，GC 跟不上。现在 TiDB 的 GC 对于每个 kv-instance 是单线程的，当业务删除数据的量非常大时，会导致 GC 速度较慢，很可能 GC 的速度跟不上写入。目前可以通过增多 TiKV 个数来解决，长期需要靠 GC 改为多线程执行。

TiDB 周边

TiSpark

由于我们之前的一个业务，主要负责统计几百个品牌的一些业务统计指标，最开始使用定时任务+SQL定时统计的方式来实现，通过定时任务的分片机制支持更多品牌的并行统计，但是耗费资源比较多，当时使用了10个分片（单个节点：2C2G）。后面通过使用TiSpark来做，只使用了2个节点完成了以前10个节点的功能。

TiFlash

TiFlash底层基于Clickhouse实现，适合于静态海量数据的分析。

> 如需了解更多，weixin 关注"SpringForAll社区" !!!  

本文由博客一文多发平台 OpenWrite 发布！