我和tidb 的故事
每个人都会有自己的方向，或多或少都会受工作、生活、梦想等等的影响，甚至被左右，深陷其中不知如何选择
序章
我还在上一家公司效力的时候，还是一个资深的“攻城师”，当时公司内部大部分的数据库都是 oracle 和 sqlserver，遇到的业务场景大部分都是一个单库就搞掂了，对于业务要求高点的，集群的方式实现高可用和热备就足够了。 当业务开始有爆炸性增长的时候，这样的方式就玩不转了，最明显的状态就是数据库的主库CPU 和 磁盘都是高得不能在高了，完全没办法满足业务的要求，那这个时候肯定会问咋办呢？
当时最出名的就是 阿里开源的项目 Cobar，但是 Cobar 后面停更了（阿里的开源项目很容易这样子…），不过还有继任者 Mycat，当然给出的方案就是分表分库，当时我对这个处理方式觉得存在一些疑惑，决定深入了解一下，于是加入到了开发组，对于这个处理的方式了解得越深，就发现坑会越大…
- 事务问题
- 查询聚合的问题
- 查询排序的问题
- 分片不足需要扩容
- 磁盘不够需要扩容
- …
ps: 当时为了解决排序和聚合的问题，开发组的大佬们还搞出了一个很强的方案，堆外小根堆排序… ps: 当时为了解决排序和聚合的问题，开发组的大佬们还搞出了一个很强的方案，堆外小根堆排序…
带着这么多头疼的问题，时间进入到了微服务的时代，同时带动了mysql 的流行，似乎一个服务实例挂接一个数据库实例的方式很合理，但是根本上未能解决扩容和资源上限的问题，带着这个问题继续前行，继续寻找
偶遇
时间飞逝，一下就到了2019年，突然发现有一个开源产品 tidb，带来很大的冲击，天生就是分布式的，能够很好的解决资源扩容和读写上限的问题，简直就是最佳答案 ：） 刚好 tidb 社区当时要来武汉举办技术日的活动，必须报名参加；
tech day 2019
现场主持活动的就是三位大佬之一的 崔秋，聊了很多背景，受益良多
当时给我印象最深的是姚婷，分享了存储结构和算法，从B-，B+ 到 LSM Tree，以及相关硬件发展的一个时间历程，带来的变化和挑战（这里比较遗憾，遗失了不少图片）
另外还遇到了 daocloud 的小伙伴，然后一起在聊这个产品，都认为这个对硬件资源要求好高，想要学习这个的投入会十分烧钱钱；
但是一致认为这个是未来最好的一个方向，会继续关注
前行
tidb 在分布式架构层面和工程模型，以及版本管理、发布方式无疑都是最佳实践
正是因为如此，就很像一个超级庞大的汉堡包摆着你面前，甚至都不知道怎么下口，很想每个地方都去咬一下，但是又没办法深入，这种痛苦来源于自己的知识广度和深度都不够，无法找到合适的一个方向，当我无脑寻找方向的时候，2020年 tidb 开始建设开源社区，全方位为tidb 建设整体的生态：
- tidb 知识分类 → 简单传递
- 场景解决方案 → 行业解决方案
- 使用问题收集 → 常见问题解答
- 优化问题收集 → 主线/支线 功能迭代
- 体系认证建设 → 深入传递
ps: 以上关于生态的归类和描述，纯属个人想法… ps: 以上关于生态的归类和描述，纯属个人想法…
当年4月，毫不犹豫的注册进入社区后，发现社区有好多的深度资源，大佬们十分努力分享前期耕耘实践过的方案， 分享的方案对于各种场景存在的痛点，和一些未来的期望，给人有更多更深的思考，大体的方向：
- 如果是你遇到这种痛点，没有更多的指引时，会怎么办？
- 如果资源不太充足的情况下，怎么能更好利用现有的资源来解决？
- 在解决问题的时候，会不会遗留什么坑？是否也会深度思考后续的一个方向？
实事上这些问题都会体现到技术点上：
- 分布式协议和算法
- OLTP 和 OLAP
- 高并发
- 高吞吐
- 负载和调度
- …
当这些技术点慢慢汇聚在一起的时候，就慢慢演变了技术场景，然后需要对这些知识储备，以此来应对未来更多的变化 变化会体现在两个点上：
- 公司业务高速发展，需要更强的技术体系来支撑
- 自己的路应该怎么走，在方向上应该选择更有把握的
写到这里，肯定会有人会问会说，人生苦短这么卷是干嘛？嫌自己不辛苦不够累么？ 若能找到努力的方向是件很庆幸的事情，何况是自己能立刻做的，还是能做好的，为嘛不做？做自己喜欢的事情，而且还能看见好的结果，还会觉得累么？
不找任何借口和理由，继续前行…
如果非要找一个理由，如图：
分享
在asktug 找到方向后，通过学习行业实践的方案，慢慢掌握 tidb 能解决问题的思路，其实最想掌握的是 tidb 能帮我解决什么问题，通过什么方式可以更好的使用…
从架构 到 功能，从原理 到实践，在这个过程中其实也踩了不少坑，当时官方文档还只有 3.x 的版本，对于整个部署过程的难度还是有点高的，特别是部署的工作量，我自己用一台退役的笔记本，直接用虚拟机的方式，然后ansible 方式搭建了 3.X 的tidb 集群，操作起来问题也挺多的，当时搭好后，能跑起来，还是很有成就感的。 没过多久 4.0 就发布了，还发布更加强大的部署工具 tiup，果断把3.X 卸掉（当时还没有 ansible 转到 tiup 上的操作模式），装上了4.0 体会了一下有Dashboard 的感觉，很不错。
这个折腾的期间，asktug 上有好多的小伙伴，都在提各种问题，问题点我做了简单分类：
- 官方文档上有介绍，但是不够详细 （补充说明）
- 对于tidb 架构不够了解，以单点数据库的视角来理解和操作，导致操作结果异常
- 缺少相关的操作指引，不知道每步操作需要注意事项，出现操作问题时，怎么去处理相关的问题
- 建库，建表对于字符集的处理方式，有大小写要求和明确区分
- 建表对于性能要求和普通结构之间的差别 （不过 5.0 的诞生彻底解决了这个问题[聚簇索引]）
- 关于性能优化，特别是 SQL 优化，问题定位都存在比较大的问题（特别是容易出现 OOM的情况）
- 对于复杂 SQL 可能无法按照 oracle 哪种方式来支持，需要从业务的层面需要进行不同层度的拆分满足业务需求
- …
以上其实还有很多很多，然后 CTC 的专家们也在进行解答。我发现我也能解答一部分问题，刚好可以巩固自己学的知识，也刚好总结一下经验能够分享给更多小伙伴，此项历练除了可以增加自己处理问题的能力，也可以收集更多的场景和一些常见的问题，帮助自己来沉淀这些经验，以此满足未来业务发展的要求，从而提炼出最佳实践
历练
PE 是 PingCAP Education 的简称， 当时还只有 3.X 版本的tidb，所有官方的学习资料还属于内部服务，必须报名参加学习； 当时很幸运了参加了一次 9.9元的培训活动：【PCTA的训练营】，当时自己苦于不知道怎么提升，毕竟asktug 上分享的各种经验和资料十分零散，无法更好的掌握这个架构对于问题合适并且合理的处理过程；然后训练营对于每天学习都有很明确的目标。其实当时自己每天的工作也很饱和，但是觉得这个架构十分吸引我，我想看看是基于什么场景下的需求和业务设想，会形成这样的一个架构模式
随着训练营每日计划的推进，慢慢得从各个点，汇聚成了面，从各个面的角度结合资源上的平衡，逐渐形成一条条的线，觉得自己在架构层面又有了一些新的角度和思考的方式，对于 tidb的各项原理和基础服务之间关系的理解也更加清晰
到了考试之日，说实话，第一次参考这种类型的考试，考试题目很多，时间也会比较紧，如果对于大纲或者知识点掌握的不够，很容易挂… 不过，我很幸运，第一次考试的就顺利的通过了，我只是觉得自己的一番努力没白费，还是很庆幸的；缘于这次考试，也认识了不少小伙伴，其实都怀着同样的一个目标，想要更了解 tidb
PCTA 之后，接着就是 PCTP 的学习和考试，对于当时的我，其实都很想放弃 PCTP的考试，
- 对于自己实力的了解，觉得肯定过不了
- 精力有限，之前已经花了大把的时间来掌握PCTA（其实觉得自己还没有那么熟练）
但是学习的机会不能浪费了，即使不参加考试，也得在拼一把，于是继续开始PCTP的学习，这个难度和 PCTA 是天差地别，每天学习也是觉得十分勉强，没有掌握的那么好，到了考试之日，果然挂掉了… 这个时候 4.0 发布了，又开放了新的课程，于是继续学习…
后续我在asktug 特别活跃，坚信帮助他们的同时也是在帮助自己，“表妹”就出现了，问我愿意是否帮助她一起建设社区，答案是肯定的，同时还有更多的小伙伴也慢慢加入了这个团队；
在所有小伙伴一起的努力下，关注社区的人也就越来越多，问题也是五花八门，广度和深度都兼备，有时候觉得好多问题仍然很棘手，但是小伙伴多，不怕～～
目光
自认为是一个自律的人，对知识的渴望和追求从来都不曾停歇，当我遇到“表妹”，加入到社区团队后，才发现有比我更“卷”的小伙伴；
当然，我理解的这个“卷”描述的形式还不一样，形式无非两种：
- 主动推动
- 被动接受
主动努力的去推进一些事情， 总会比被别人来带动，被动接受的效果要好的多，但是想让自己能保持这个状态就很难，不过，这里有一群这样的小伙伴，然后有共同的目标和方向，就会有足够的力量支撑起来，状态就能够保持，继续前行！
- 我们都是追光者，追光而行不期而遇
- 偶遇一颗蓝色的小星球，感谢万有引力，将我拉向你
- 浩瀚宇宙中，我们虽然渺小，却绝不孤独
- in the vast universe , althought we are small , we are not alone
