我和TiDB的故事 | 遇上你是我的缘

【 初闻 】

       作为一名一直混迹于传统行业的*** DBA（毫无前途） ，开源的数据库接触较多可能也就MySQL，对于国产数据库的的态度：都是说的好，也就拿开源的改改而已，核心系统估计用的机会不大。

       不知道哪一年也不知道下了几场雪，偶尔听过TiDB这个数据库都说是比较火开源数据库，估计也就刚刚2.0的时候，有QQ群小伙伴测试了tidb反馈是太慢了，没有想象中好，当时心想可能这辈子不会用到TiDB了。

【 相遇 】

       后来的某一天有TiDB的人员来公司交流了TiDB ，算是对TiDB有了初步的认识，也渐渐的在朋友圈中了解到了TiDB的一些动态，比如像4.0中tiflash发布等等。直到2021年4月份的某天接到一个需求咨询，想要把RDS生产库中的某些表使用kafka同步到一台MySQL供部分查询使用，于是就找了一台只有几块SAS盘的机器，结果上光数据同步就把IO打满了，能否想个其他的方式解决。    

       当他们找到我的时候我想到了TiDB，于是接下来的任务他们去找机器而我去研究TiDB，经过各种腾挪之后终于找到了5台机器，但是哥呀，这5 台机器加起来才12块SAS盘，跑起来估计还不如***盘的笔记本性能好呢，没办法资源就这样了，先上了看看吧，为了尽量的能分散IO，把2台跑 tidb 和 pd ,3台做tikv，每台4块SAS盘做raid0。

       就这样在leader 均衡和RAID 缓存的加持下，轻松抗住了数同步压力，数据量的规模在8T左右，通过主键和唯一键读取的磁盘读在几十ms内，但是碰上大数据量的查询后大量磁盘读时就太慢了。

【 幸运 】

       为了学习TiDB，asktug是一个必经路径，在asktug上提了不少问题，清晰的记得当时为了解决如何在X86和ARM混合模式下如何设置本地镜像问题(系统不能连接外网都是下载安装包后上传服务器)，傲总@ hey-hoho团队熬夜研究了实现方式，并专门写了文章(https://tidb.net/blog/e92230a3),，再次感谢傲总。

       可能是那段时间在tug上比较活跃，突然某一天，收到了表妹的微信消息(终于有美女主动发消息了)问我愿不愿意尝试下做版主，当时的我又喜又恐，喜的是被一定程度认可了，恐的是万一误人子弟不就丢人了，一番心理斗争后就答应了下来，从此开始跟着TiDB的大船远航。

       经过一段时间在tug的摸爬滚打，不仅提升了知识技能，认识了一些大佬，还享受到了帮小伙伴解决问题的快乐，更感受到了分布式和开源魅力，这一切都源自当初表妹的那个邀请，对于我来说这就是一次转折，很幸运遇到了表妹，感谢表妹。

【 布道 】

       其实之所以会推荐TiDB的一个原因是被官方文档的内容所影响，至少到目前为止相比某里等大厂的文档真的是太丰富了，而且还有很多讲解原理的博客文章，asktug上也有很多丰富的案例，这在国产数据库中真的可以用罕见来形容，也被这种开放的态度所折服，随着后来对tidb的了解越来越多，也开始尝试在tug和公司内公众号上写些关于TiDB的文章，在给给自己做个笔记的同时也能做些知识传播。（专栏地址：https://tidb.net/u/h5n1/post/all公司公众号: https://mp.weixin.qq.com/s/56rHLPIAyWAWcEYXeaynTQ ） 。

       为了能让公司内的更多的人了解TiDB，组织了一场内部培训，讲解了TiDB的基本架构、关键特点、行业案例等，为了能吸引更多人听，和表妹申请了一些周边作为抽奖礼品，表妹不仅慷慨相助，还做起了模特，很遗憾的是那次培训仅有78人参加，没有达到预期。

【 祝福 】

       这一年多来见证了TiDB的一次次版本带来提升和变化，也有幸参加了6.0 book rush活动，再一次的感受到了社区的活力，祝愿TiDB这种真正开源数据库也越来越好。另外也对TiDB再提一些建议:

1、  对传统行业的加强

         TiDB目前的主要活跃用户可能在互联网行业较多，在一些传统行业发力不够。另外传统行业中有些安全要求比较多，对于在线镜像文件下载、 PD等组件的安全性、TiUP的权限等可能在传统行业遇到些问题。

2、 官方文档内容加强

         目前官方文档大部分内容还是比较详细的，但仍有些内容比较缺失，比如监控方面，没有详细的说明、面板内的各项指标也缺乏说明和原理性解释，这方面能够详细描述的话对于问题诊断会更有帮助。

3、 提供一些更精细化的指标

           以SQL执行计划为例，执行explain analyze后 TiDB的每个算子能够展示该算子的具体信息比如actRowS、过滤谓词、cop task时间、内存消耗等，大部分情况下还是能够很容易发现问题，但也有很多时候SQL执行时间比较长，但根据执行计划或dashboard看相关算子和执行时间没有什么问他，而监控有30分钟的粒度整体也没有什么问题，导致不能快速和清晰的定位问题所在，如果能降执行过程进一步按阶段细化，比如类似***的等待事件，则能快速分析问题，降低很多人的门槛。

【 镇楼 】

是她，就是她！