我和 TiDB 的故事|这里集齐了 34 位社区小伙伴和 TiDB 的故事
这是一个暖心的帖子，从 1024 程序员节故事分享活动帖里，看到了很多 TiDBer 们分享的与社区之间的点点滴滴。有的相遇的开始是听说，有的是偶然，但现在看来，所有的相遇都成了必然。看了大家分享的与 TiDB 的故事，感慨 TiDBer 们不仅是技术大佬还是文学大师的同时，从故事里感受到了一种温暖的力量，在这个帖子里也希望可以传递给所有 TiDBer 们这种温暖凝聚的力量。故事里记录着每一位 TiDBer 跟社区一起走过的每一个脚印，一步一心，一心一步。
故事1 ：来自 @数据小黑 | 命里有时终须有–记与TiDB的一次次擦肩而过
我
我是一个非常有重量的人，买衣服只买迪卡侬，是因为迪卡侬的号大。我曾经崇拜过一个技术大拿，很牛的那种，体重比我还大，所以我很释然，也觉得做技术也许体重大是标配。我是个老头，在社区里面，很自信的说，我的年龄数一数二的大。我也接触过非常多的东西，我曾经搞过ITIL、写过Flex、做过平台架构规划、研究过前端，甚至于现学现卖SEO。最近几年踏踏实实的研究数据，搞搞架构，从Hadoop入门，一直在折腾Spark。
起于2019年的那个夏天
19年我司委托我一个任务，找一个数据库，能够承担起历史数据明细查询，要求有多少数据装多少数据，以较高的并发，以及用户能够忍受的时间（3秒）返回。当时团队里面有个老大哥，对比了几个数据库，有Citus、YugaByteDB、TiDB等等，TiDB是最早开始测试，也是最早放弃的，早期的TiDB部署环境时有个check，会要求磁盘的iops大于1W（randread iops of tikv_data_dir disk is too low: 8207 < 10000），达不到要求就不能安装，我们的破烂开发机，有1K就不错了，然后测试TiDB这事就无疾而终。论坛里面有相似的问答：https://asktug.com/t/topic/2120 1 。虽然Citeus、YugaByteDB，甚至Cassandra都有过充分的测试、争论，但也因为种种原因没有上线。
召必回，战必胜
21年，我又对TiDB做了一些研究，原来的期望是找一套云原生，兼容Spark计算的数仓View层的数据库，当时期望的架构如下：
但是那一年，我们干了个奇葩事，遇到了一个很难解决的问题。 我们用大数据Hadoop这一套开始给客户算账，地球上绝对有很多人干这事，但是像我们人又少，技术又烂的团队干这事很少。然后我们就遇到了月初月末算账不准的问题。整个同步的链路很长，如下图：
我们研究了两个周，备受折磨，我就想搭建另外一个同步链路，同步数据后作对比，期望发现问题。或者说如果新搭建的同步链路稳定，直接采信新的同步链路的数据。 由于TiDB完全兼容Mysql生态，而且我们集群里面有Otter，于是我有个大胆的想法，用TiDB搭建另外一个数据同步链路，用Spark同步TiDB的数据到大数据产品中进行计算，于是同步链路变成了这样： 
新的同步链路，从搭建生产环境，到能够正式处理数据，仅用三天时间。新链路上线后，采用两条链路互补的方式，计算账单，数据再没出过问题。经过两周的跟踪，也逐步发现了以前环境的问题，修正问题后，TiDB的同步链路完成使命。 详情：https://tidb.net/blog/55a8baf9
最接近生产的一次
22年我逐步走进了社区。在公司内部也做了一些培训，搭建了一个测试环境。由于我的布局，我们另外一个团队在需要解决saiku产品的底层查询问题时，想到了TiDB，于是做了一些测试。从结果来看，TiDB比环境里面的其他数据库，更适应saiku的查询方式。于是我们打算在生产上线TiDB，用于解决很多我们生产环境需要解决的问题，不单单是saiku，还有需要分布式关系型数据库的很多地方。但，又双叒叕因为外部环境因素，我们最终部署了Doris，毕竟测试saiku在Doris上有更好的表现。在这个过程中，我们发现了一些问题，因此提了在tidb的第一个issue，并在新版本中得到修复: https://github.com/pingcap/tidb/issues/32626 1
详情：https://tidb.net/blog/de9bf174
生命不息，折腾不止
随着年龄增大，越来越认识到知识储备的重要性。汲取知识的重要方式是深度参与社区。 于是，我就：
于是，我就：
于是，我就：
还有以下，懂得都懂，hhhhhhhhh：
故事2 ：来自 @h5n1 | 遇上你是我的缘
【 初闻 】
作为一名一直混迹于传统行业的oracle 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盘，跑起来估计还不如SSD盘的笔记本性能好呢，没办法资源就这样了，先上了看看吧，为了尽量的能分散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 1),，再次感谢傲总。
可能是那段时间在tug上比较活跃，突然某一天，收到了表妹的微信消息(终于有美女主动发消息了)问我愿不愿意尝试下做版主，当时的我又喜又恐，喜的是被一定程度认可了，恐的是万一误人子弟不就丢人了，一番心理斗争后就答应了下来，从此开始跟着TiDB的大船远航。
经过一段时间在tug的摸爬滚打，不仅提升了知识技能，认识了一些大佬，还享受到了帮小伙伴解决问题的快乐，更感受到了分布式和开源魅力，这一切都源自当初表妹的那个邀请，对于我来说这就是一次转折，很幸运遇到了表妹，感谢表妹。
【 布道 】
其实之所以会推荐TiDB的一个原因是被官方文档的内容所影响，至少到目前为止相比某里等大厂的文档真的是太丰富了，而且还有很多讲解原理的博客文章，asktug上也有很多丰富的案例，这在国产数据库中真的可以用罕见来形容，也被这种开放的态度所折服，随着后来对tidb的了解越来越多，也开始尝试在tug和公司内公众号上写些关于TiDB的文章，在给给自己做个笔记的同时也能做些知识传播。（专栏地址：https://tidb.net/u/h5n1/post/all 1 公司公众号: https://mp.weixin.qq.com/s/56rHLPIAyWAWcEYXeaynTQ 1 ） 。
为了能让公司内的更多的人了解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分钟的粒度整体也没有什么问题，导致不能快速和清晰的定位问题所在，如果能降执行过程进一步按阶段细化，比如类似oracle的等待事件，则能快速分析问题，降低很多人的门槛。
故事3 ：来自 @shawnYan | 横看成岭侧成峰
Hello, TiDB!
这是我加入 TiDB 社区的第 293 天。
入行 IT 多年，救火数次，原本打算抱着 MySQL 从一而终，却忘了最大的确定就是不确定性。
国产数据库的春天已来，DBA 也应与时俱进，从石器时代走向更先进、更开放的时代，去了解、熟悉、掌握国产数据库，比如领军者 TiDB。
TiDB 是创业即开源的真国产开源数据库，刚接触 TiDB 时，我就被其全开放的源码、文档所吸引，后逐渐发现有各种优秀的活动或课程，比如，适合在校大学生的 Talent Plan，适合极客的 Hacking Camp，适合 DBA 或开发者的 PingCAP Education 系列课程。
而我和 TiDB 的主线故事，是从“TiDBer Talk：TiDB 认证分享会”开始的。
精进的过程
TiDB 能力认证
作为一名合格的 TiJuaner，自然是 PE 课程和认证全卷一遍。我一直推崇“以考促学”，对于刚接触一个新数据库，快速搭建最小验证环境，先用起来，对其有现实感受。与此同时，翻阅官方文档和学习原厂课程，可以帮助我快速补齐理论知识，以此做到理论与运用“双工”推进。
不得不说，TiDB PE 课程都是良心课程，把商业课程做到了“限时免费”，对于数据库小白，或者有一定其他数据库基础的同学都可以快速、有效地学习 TiDB，对课程有疑问可以在论坛反馈，问题基本会得到有效解决，形成了良好的课程学习闭环。
TiDB 6.x in Action
TiDB 6.x in Action 1 已正式发布。TiDB 6.0 Book Rush 活动从4月中旬开始，到7月下旬正式收官，我除了中间生病的一段时间，都有全程参与。在研究 TiDB 的同时，保持输出文章；在 Review 文章的同时，精读其他同学的文章，以拓宽、加深自己的知识面；在编辑电子书的同时，模仿操练案例，以查漏补缺。
好活动就是这样，令我乐在其中，但“副作用”也是有的，会占满业余时间，甚至在凌晨一点多还在看 PR，翻相关帖子或者 Issue。
有趣的灵魂
520 特辑 之 猜谜
谜题的乐趣是在于烧脑还是解谜时的畅快？
二者皆有吧，一群有趣的人在 520 这天玩“烧脑”游戏，有兴趣的同学都可以来试试，感受一下什么叫 Ti 式幽默。
Q: A Prophet who controls the past controls the future.
A: 不止黑客帝国里有先知，TiDB 里也有，这就是 TSO（Timestamp Oracle）。
更多谜题在帖子：这么烧脑有趣的活动，你确定你不来试一下？
520 特辑 之 图云
特别的“爱”，给特别的“你”，最活跃的小伙伴都出现这个帖子里了。
AskTUG 论坛就是 TiJuaner 的精神家园，找@表妹 获取了我最新的热力图，除了过年和病假的那段时间，看来我今年还是常来“HOME”的，有时周末也会来“打卡”。
在 AskTUG，不仅可以收获第一手社区新鲜事，TiDB 异常案例、解决方案，还有丰富的资源案例，也还有我有幸参与编辑的技术月刊。
另外，TiDB 社区有些快乐是想象不到的。不到一年的时间，我收获了 16 枚徽章，其中最惊喜的莫过于“版主候选人”。
当然，还有其他的一堆“惊喜”，比如，绝版帆布包，绝版“吃豆豆”T恤，最炫 Ti 键盘，新款表妹同款挎包，等灯噔噔~
待续
盛夏的夜，蝉鸣不止，沉迷于 TiDB 而无法自拔，闷热仿佛都消散了些。
回归 DBA 的初心，我们是“登山者”，也是“开拓者”，目标明确，不自设上限。
同时，还需心存敬畏，厚积薄发，方能耕获菑畲。
故事4 ：来自 @xfworld | 我们终会在平行世界相遇
我和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
故事5 ：来自 @Kongdom | 迟到的独白
前言
这是一篇迟到的独白，久远到我都忘记了是什么时候收到的邀请，就如同我不记得我和TiDB是如何开始的一样。
正文
作为一个坚定的SQL SERVER使用者，至少在工作后的七八年里，我都和SQL SERVER默默为伴，不论是小到一场订货会的下单系统，还是大到上千家店涵盖多业态的ERP系统。我以为会一直这样下去，就和天亮之后就是爽朗的明天一样。 直到2019年7月份的一个深夜，那是一个孤独难耐的夜晚。第一次，那真的是第一次，进行SQL SERVER向TiDB的切换。在那之前，我对TiDB的了解还停留在，一款数据库，仅此而已。当时公司领导在众多数据库中选型了TiDB，因为框架是微服务的，所以TiDB是8个库，而之前的SQL SERVER中只有一个库，一个典型的单体服务库。由于TiDB兼容MySQL，但是没有兼容SQL SERVER，所以官方的切换工具用不了，只能自谋出路。最后，选择了kettle作为异构数据库切换数据的工具(PS：说到kettle，我好像还欠一位TUG同学的kettle文章，笑哭)，一切从零开始，所以准备切换的那一段日子是痛苦且难熬的，尤其是需要将大量的存储过程和自定义函数翻译到程序中，往事不堪回首，昔情莫再留恋……回到那个奇妙的夜晚，当大家按部就班切换完成时，系统不负众望的运转起来了，是的，正常的运转起来了。这一刻，一切都是值得的，这一刻，对TiDB也产生了莫名的好感。那是一种漫卷诗书喜欲狂，回首无人诉的独欢，是一种随风潜入夜，润物细无声的情怀。 时间来到2020年的4月06日，我光荣的成为了TUG的一员。
后记
我和TiDB的故事还远远没有结束，恰恰才刚刚展开~ 有些人步伐与众不同， 那是因为他们听到了远方的鼓声—— 梭罗《瓦尔登湖》
故事6 ：来自 @db_user | 我和tidb的的故事没有结局
这是一个看起来很短，但却也很长的故事 缘起：其实和TiDB结缘是从我入职这家公司开始，当时还不是很了解tidb,只是知道goInception的解析规则是依据TiDB来写的，这家公司已经有一个AP业务用上了tidb,不过是我当时的运维leader来管理的，作为一个还算年轻的小DBA来说，对于接手这种我还不了解的数据库当然是义不容辞的了，这里要感谢我之前的leader,对我学习tidb起了非常大的指导作用，能让我快速学习了解tidb 升华：与tidb感情的升华源自表妹在社区的一次招募版主活动，本着初生牛犊不怕虎的心态，毅然决然的参加了此次招募，进到了版主群里，本来以为自己的小技术还能用了，但是进来之后发现情况不是这样的，我发现这个群里有三种人 1.大佬 2.嘴上说着自己不是大佬的大佬 3.我自己
从大佬们的聊天中也学到了许多的知识，然后就是参加了tidb的各种线上线下的会议，也和表妹还有大佬们面基，学到了很多。热爱就仿佛璀璨星河中独自闪耀的你，希望我也能在tidb的浩瀚代码中留下淡淡的一笔，生命不息，我和tidb的的故事没有结局
故事7：来自 @ealam_小羽 | 2020-2022
初识
2020 年 2 月 29 日，虽然由于疫情在家办公，但小周还是小周。不过我们的小周一般都是活动日、分享日。这天，同事分享了个新名词——TiDB，说可以去 B 站关注一下 TiDB_Robot，他们今天在直播。为什么 TiDB 的社区凝聚力这么强？TiDB 真的能解决这些问题吗？一个个问题埋在了心底，终有一天，它们会破土而出。
其实我也记不清什么时候开始知道 TiDB ，当时关注了 TiDB_Robot，搜了下关注时间。 2020-02-29 10:57:12，这就是故事的开始！
相遇
2020 年 3 月 ~ 2021 年 9 月，一直在 MySQL 和 Mongo 之路狂奔，也就偶尔会从 B 站动态中：一堆美食区 UP 里冒出 TiDB 的身影。2021 年 10 月，一个新的转折点，转战新的业务线，开始讨论数据中台的搭建方案。虽然以前接触的数据量压根达不到 TiDB 的使用场景，甚至连分库分表都在犹犹豫豫（加点资源，就不用搞那么多了，也就百万级别数据），但一直对 TiDB 的各种特性心心念念。于是，很快提出了为什么要使用 Mongo？数据明显更适合关系型数据库，要不要考虑可以支持海量数据的 TiDB？没想到，新部门的小伙伴，从开发到运维都对 TiDB 有一定了解，一拍即合，选型确定！选型评估、资源申请、线上部署，一路顺畅！ 2020 年 12 月，使用 TiDB 的第一个业务上线，表现良好，开发过程中也没感觉的与 MySQL 有任何差异，几乎完美兼容！
相知
加入社区
2022 年 1 月 1 日，加入 TiDB 社区。 不过说点实话，很长的一段时间，我基本忽视了社区的价值，毕竟作为一个 CURD Boy，文档本身这么齐全，又兼容 MySQL 协议，用就得了，其他的不可以找运维！
人类，终究会为自己的无知付出代价！
遇到问题
2022 年 4 月末，CURD Boy 的开发工作完成，测试验证时发现：咦，这个查询怎么这么慢，表 A、表 B 我加了索引，但为什么没关联？表 A，你怎么和表 C 勾搭上了，你俩不是最佳搭档啊，你的最爱应该是表 B 啊！MySQL 验证了一把，A 终于关联了 B，于是问题锁定：TiDB，肯定是因为你！翻了半天文档，终于找到了答案，Join Record 算法！Join Record 算法，会将关联表中数据量最小的表 C 拎出来，分别和表 A 和 表 B 配对，看和谁的效果好，压根不会有表 A 和 表 B 配对的情况！当然，贴心的 TiDB 也早提供了答案，STRAIGHT_JOIN！
感兴趣的小伙伴，可以看下官方文档：https://docs.pingcap.com/zh/tidb/stable/join-reorder 也就是这一天，我终于理解了这句话：命运馈赠的礼物，早在暗中标注了价格。不学好 TiDB 的架构、设计，各模块特性，怎么能用好 TiDB 呢？重头迈上征程，《TiDB in Action》、301、302、TiDB 社区，我来了！
找到组织
匆匆忙登上 TiDB 社区，不知道在哪翻到了一个交流群贴，加上了 表妹，表妹把我拉近了一个 TiDB 社区互助群，看到了群公告：
进群请改昵称： 社区昵称-城市-公司（公司不方便列出来的可以不列）
本群是 TiDB 技术交流群，有问题先去：asktug.com 发帖，发帖如果没有人回复可以把链接放到群里面来求助。 发问之前可先搜索：https://search.asktug.com/ （大部分问题都可以在此找到答案） 问题搜索指南&提问准则：https://asktug.com/t/topic/93912
技术交流正常需要 case by case 讨论，所以尽可能的先上链接，再沟通，把问题的背景和复现路径都写清楚是对“他人”的一种尊重，也是可以让问题更好地被定位到，提高问题解决得时效。
TiDB 社区交流群是一群使用 TiDB 的社区小伙伴互相交流，我们秉承自由、平等、开放，拒绝白嫖和你就应该为我服务的思想。
不知怎么，看到这篇公告，不由得热泪盈眶，有一种终于找到组织的感觉。之前遇到问题，默默一个人周六翻了一天文档，身边问了一堆不知道，这下，突然有了继续使用 TiDB，踏平各种阻碍的底气！从此之后，惊喜连篇！
内测 201
作为一个 CURD Boy，看着社区里某某公司 运维/DBA 大佬的发言，课程认证中数据库专员、数据库专家的名头，初来贵地，还是有那么一点点格格不入的想法。然而，很快这么一点点格格不入就被驱散了。首先是看了 TiDB 的一些入门课程，会发现完全可以把 TiDB 当作一个分布式应用来理解，而且介绍了很多技术选型方法、分布式应用架构理念，应用开发也会受益匪浅！其次就是，包老师开启了新课程《201系列-面向应用开发》，应用开发也有了一席之地，应用开发专家认证也即将开启！申请了 201 的内测，小伙伴们太卷了，在周末才勉强赶上了进度。而包老师比我们更卷，周日搞到周一凌晨四点，5 月 16 日发布了内测的最后一个课程。当时正在听公开课的我，收到班长小木发的 201.4 的更新推送，瞟了一眼，201.4 才 127 分钟。激动的心，颤抖的手，终于能卷一卷内测的小伙伴，争一争原来早已放弃的前十，看看能不能混进小群，窥屏一下很少能接触到的 DBA 大佬（小部门，上班以来没见过真 DBA）。 2022 年 5 月 16 日 21 点 17 分，201 系列课程拿下！前十锁定！
展望
现在还觉得恍恍惚惚，在 TiDB 社区突然体验到类似心想事成的感觉。没人交流，发现了社区交流群。通过社区交流群，发现了 201 系列内测，有了见产研大佬的机会。内测的小伙伴真肝，但最后一节课刚好有空，偷偷后发制人！一番顺风顺水过后，包老师让我看到了现实，PCSD 考试内测把我打回原形！你还嫩着呢，就算是从应用开发来讲，你还有很多没了解呢！老老实实收下心，定下来之后的目标：5 月份，301 系列刷完后，6 月份，继续 PCTA 试试水，是骡子是马，总得拉出来溜溜！下半年，抽空把 302 系列完成，没事多上上社区，刷刷贴！有机会来把 PCTP，过不过的无所谓，总得考验考验自己，查漏补缺。当然，CURD Boy 的基本功也不能落下，从这次 TiDB 的学习之路，慢慢找回了当年学习的感觉，保持下去吧！
以此记录一下与 TiDB 的这些故事，也偷偷给自己立下了一些 Flag！ 希望明年或第 N 届征文大赛，能在更新一把这些故事，看一看当年的 Flag ，它还好吗？
故事8 ：来自 @Ming
接触
从自己入职公司之后, 自己也算是正式开始接触上了TiDB,在这之前,对于TiDB的了解并不多.也是自从入职公司以后, 大部分的时间都聚集在了了解TiDB,在之前,自己只是单纯的进行学习与日常工作,并没有过太多的交流,直到遇见TiDB之后,在社区里让我感受到了学习带来的乐趣。
相识
刚开始自己只是在社区查看一下自己遇到的的问题有没有相似案例,来进行参考,这样方便了很多,随着越来越多的了解,自己也喜欢上了社区的氛围.（发布问题,会有人耐心解答,还可以了解大佬们的处理思路.帮助别人解决问题,可以扩展自己的思路,还有一种开心的感觉）
相知
这种感觉很奇妙,在经历一两次之后,让我了解到技术并不是一个无聊事情,他可以让我在这感受到很浓参与感与获得感,现在的自己,不止于在社区查找问题,而是通过交流认识大佬,通过交流拓展思维,并且有了也把自己了解到的一些东西分享出来,感受到了浓厚的乐趣. 当然,现在不管是知识的累积还是文笔方面,都有很大很大的差距,自己也是希望在这里锻炼自己,通过交流来成长。（毕竟我还不大,差点00后了🙈） 希望自己接下来可以学更多的相关知识并且可以把自己的文笔方面锻炼出来
故事9 ：来自 @Myth
相识
2021年三月份，校招从算法岗转战开发岗，开始了 KV 存储相关的工作。在一次技术调研的时候，接触到了 TiKV 引擎，也在这时认识了 TiDB 以及 TiDB 社区。从 TiDB 社区非常友好的文档、源码讲解博客中，不仅学习到了技术知识，还学到了如何更好的写文档、如何写文章。
相知
在了解了TiDB 的技术架构和各种组件后，我开始关注 TiDB 社区、GitHub、微信公众号、B站、知乎、甚至东旭的豆瓣 
。了解的越多，越发被 PingCAP这家技术氛围浓厚的公司所吸引，幻想着未来能加入这家很酷的公司。
相爱
也就那时，开始研究 TiKV，TiDB，学习 Rust, 从 TiDB 的文档、材料中汲取知识，并将其迁移到当前工作中，也为 TiKV 下的 KV 分离插件 —— Titan 贡献了一个比较大的 Feature。 后来自己参加了 Talent Plan, 实现了 TinyKV，不仅深爱上了 TiDB 社区，也深爱上了数据库技术。
相守
希望能通过自身的努力，提高自己的技术水平，争取未来能加入 PingCAP，与其相守终生！
故事10：来自 @Hacker_hnSEntrA
相识
第一次接触tidb是2020年3月份，突然领导说有个tidb要48小时分布式写本书，正好我们最近打算上线tidb。就顺便看看能写点什么。 那时候对tidb一点不懂啊，只能硬着头皮搞环境部署一通，然后写了个基于我司环境的部署一篇文章，也算蹭了个参与。后面就是tidb上线。接用户。最一开始对tidb的印象就是银弹，什么问题都能解决，NB的很。结果紧接着一个用户的故障啪啪打脸，P社工程师帮忙分析，是因为SQL写的不好，有全表扫描，然后tikv oom，导致tidb读取schema超时，停止服务。头一次感觉TiDB真脆，竟然那么轻松就OOM了。就不能管好内存，超出自己的内存限额之前就拒绝掉这个SQL而不是让整个集群都挂掉吗？
相知
后来，随着版本升级，出了SQL的内存quota，用户也在我们的引导下逐步学会了优化SQL。 我也跟着TiDB非常丰富的学习资源不断学习，了解了不少TiDB的知识。
新征程
现在，没事儿看看TiKV的源码，对TiDB这一个复杂的数据库了解也越来越多，线上故障基本上游刃有余。用户遇到故障也可以理直气壮的说是他们SQL写的不好，用法不对【手动叉腰】。
故事11 ：来自 @forever
到tug社区快整一年了，虽然时间不长，但是感受到了社区的活跃
初闻
初闻tidb是在一些数据库技术的讨论群里，很早很早了，听到一些大佬在说tidb，但是说的bug比较多点，想自己了解下奈何懒，没付诸行动
初识
初识tidb是在项目要poc各个云，腾讯云，阿里云，华为云，京东云还有一些小弟云，当时测试TP，AP都涉及，当时TP对标都是mysql，腾讯-阿里-华为都是中间件，京东云是tidb，当时听到的介绍，兼容mysql，曾经有客户微代码修改就可以迁移到 tidb，再往前一点做过一个项目用的是华为云，那是直接可以平测，只需要改回原始的sql，还有没有头疼的分库分表，没有分片键这特别考验设计的难题，也在此时开始看源码讲解等文章，没有系统的去学，只是网上搜到的然后就把账号发的都看看
初入tidb社区
对于我来说就是注册了账号，哈哈，虽然最后没有用上tidb，但poc的测试给了学习tidb的动力，然后就进入了社区，在社区感受到了满满的能量，也在官网上看到了好多视频，然后就止不住的把喜欢的都看了，不得不说讲师董菲老师讲的很有磁性 虽然在当前的项目上还没用上tidb，但是还是一直在跟同事科普tidb，不时的来一句选tidb就好了
书山有路，学海无涯，真想对你说一句“天下谁人不识君”
故事12 ：来自 @啦啦啦啦啦
初识
应该是18年吧, 从一个在互联网金融做开发的大学同学那里第一次听见tidb这个词。他说你不是dba吗，为啥不知道tidb，于是去官网了解了下，开始对tidb有了初步的了解。说来也巧，年底的时候就有业务说不想分库分表，想改用tidb。于是趁这个机会用docker部署了一套，测试了性能，发现符合业务的需要。
相知
2019年的时候就有2套tidb集群就在公司上线了，没记错的话应该是2.1版本的。后来有了tug社区，最早只是在asktug注册了账号问了几个问题。当时由于手头的工作实在太多，除了tidb之前还有mysql、sqlserver、pg、redis、mongodb等等，后来领导还想让我接手db2，搞得身心疲惫，所以没能深入学习tidb。
相熟
直到最近2年终于扔掉了那些繁杂的工作，新公司也有业务在用tidb，所以重新开始了学习之旅。后来表妹拉我进了版主群，从社区各种丰富的学习资源和大佬们的聊天中学到了很多的知识。
故事13：来自 @wuxiangdong
初识
2017年的秋天,找了一份dba的工作，分库分表是我主要负责的,很痛苦。当时觉得这不是我要的数据库，于是和朋友不停的抱怨，有一天她突然对我说:“Tidb你了解下,或许能帮到你”,了解了tidb,符合我的期望。我兴奋的对她说，感谢你，我不再痛苦了。
第一次的接触
总会有这样或者那样的问题，但是大家都可以接受，尤其是开发，因为分库分表程序上也要有调整，测试测下来的结果不能令他们满意，毕竟tidb使用的机器数据比之前的多，但是他家最担心的问题还是tidb是否稳定，能否上主业务？经过多次沟通，先上边缘业务，最终一顿整，部分业务用上了Tidb。2020年，公司要求全部应用上k8s,也包括数据库，调研了很多，压力很大，应用程序，刷刷的全上了，数据库依然各方面问题，operator开发，开源社区，很痛苦。最后还是 tidb,可以上K8s。
第二次的接触
2020年，公司要求全部应用上k8s,也包括数据库，调研了很多，压力很大，应用程序
刷刷的全上了，数据库依然各方面问题，operator开发，开源社区，很痛苦。最后还是
tidb,可以上K8s。第二次的接触，依然很多问题，遇到问题解决问题吧。
故事14 ：来自 @Harbin70KG | 学tidb半年，社区治好了我的精神内耗
楔子
今晚下着雨，电闪雷鸣，我漫无目的的在篮球上闲逛，任由时间一点点浪费，22点准时，回家打开电脑写文章，此时距离七夕只能剩下了2小时，原谅我，一个精神内耗严重的人，冲突而矛盾，追求完美，对写出来的文章力求完美，但有时会因想法过于理想化而无法写出来文章，苦恼、郁闷。接触TiDB，半年多1篇文章，都没写
想写TiDB数据库安装，一看专栏里面有了，写的还不错，不能写重复的，想写TiDB 6.0 Book Rush，想写GO语言连接TiDB的文章，写完了，一查资料，还可以各种优化，不停的不满意然后再修改，突然看社区，TiDB 6.0 Book Rush完成了，到给孩子取名了环节，我文章还没写完 … …
内耗
说起和TiDB结缘，还得从上一次陷入一场内耗说起，有一天我在网络上看见这一段话，我只是客观引用
“中国IT行业起步较晚，加上国情和民族性格的原因，大部分人更乐于使用外国人现成的软件（大部分还是盗版），开发点小应用，系统级别的软件几乎没有胆量去挑战。在大多数国人的心目中，象大型操作系统，大型数据库系统这样的软件，就是个禁区。对于性格容易自卑，技术学习没有恒心和耐力，遇难则退的国人，根本从来没有想象过有一天，自己也有能力去挑战。君不见，PUB上的数据库爱好者们，对于各种数据库内幕，比如块构造，隐藏参数等津津乐道，对于调整好一条SQL使之优化器下能高性能运转具有巨大的满足感成功感，仿佛自己掌握了天下最有价值的真理，驾驭了天下最有难度的技术。但对于设计，编写出这个数据库的人来说，他们看到此情此景，只好躲在一边偷偷哂笑。用数据库的称为大师，那么自己写出一个数据库的又该称为什么呢？”
那么自己写出一个数据库的又该称为什么呢？，这句话反复冲撞我的大脑，突然感觉自己的渺小，这几天刚和同事学了点某数据库优化，学了点隐藏参数，刚刚建立一点“数据库大师”的骄傲崩塌了，我陷入了一场巨大的内耗，开始重拾C++，买了许多书，读了Rust编程之道，看到唐刘老师，给做的序，第一次对TiDB有了印象，读完Rust编程之道，我知道我得先精进C++，时间用某个APP读电子书，参加每天3小时的组队挑战，队名就叫180分钟，工作不忙时候，轻松3小时完成，工作忙的时候，半夜困了，闭上眼睛也刷满3个小时，今年1月初读《数据库系统内幕》，黄东旭老师做的序，又接触了TiDB
初始
在之前的MySQL考证群里，听大家聊着TiDB认证，限时免费，大家快考的话，我看一下1月8日，1月14日，考初级，以前我就放弃，自从精神内耗之后，我精神多了，大半夜觉也少了，我当时想法是考满分（估计那时时候内耗最严重吧~），1月26日考中级，必须先取得初级，再考中级，时间太紧了，我破天荒的注册了社区，进去看看了考试认证的经验分享的文章，大致内容就是比另一个开源分布式数据库初级难考，我就看完这句话，放下了我的手机，停了我的180分钟阅读挑战，1月8日到1月26日，我刷视频，做实验，想着考满分了，发一篇考试认证的经验分享之后，“事了拂衣去，深藏功与名”，初级考完，没满分，我挺意外的（1月14日考初级时候，我中级视频已经刷了一遍了）当时考试有个群，说马上解散（我又开始内耗了），迅速写一篇经验分享文章，发群里，继续刷中级视频，1月26日，考完中级，知识点太多了，每道题都要考虑好久，我差点没过，我思考了好几天，TiDB有点不一样，从那以后我开始了180分钟阅读tidb社区文章的挑战任务，天天刷社区，直到参加直播之后，才好一点，因为开始每天练直播啦，这是后话（~）
好事发生
直到YY给我发邮件，然后参加10min TiDBer Talk，2月16日直播，我慌了，赶紧准备2月14日情人节，我竟然录好几遍视频，练习直播，事实上证明，情人节，七夕，这种节日，我对离不开TiDB了，这个后文再说，哈哈（内耗好多了~）
2月16日，我的互联网首次直播，太真实了，我准备那些东西都忘了，胡言乱语，却很开心，仿佛被治愈了一些，也认识好多小伙伴，从此我混进各个国产数据库的直播间，参加各种训练营，每次都会遇到同一个TiDB小伙伴，这个人我就不提（哈哈），至少有5个以上群里，我们都在，比我卷的人还有，社区果然都是些大佬，好事发生，就像小金牌一样，人生好事不期而遇
未完待续
以前内耗，搞代码，搞得身心疲惫，怀疑人生，慢慢沉默寡言，随着参加TiDB社区，课程体验官，群里猜谜活动等（这么烧脑有趣的活动，你确定你不来试一下？），生活也因TiDB丰富起来了，今天为什么发文章，因为今天是七夕，在这样有爱的日子，要和TiDB和社区在一起（~），结尾~
彩蛋
彩蛋就是我在23点59写完章，我又开始精神内耗了，仍需社区治疗
故事15 ：来自 @meathill | 关于我作为前端报名 TiDB Hackthon 2021 然后被毫无悬念地淘汰这档事
初识
我与 TiDB 的故事，应该从上次 Hackathon 说起： 2021 年年底，我偶然在推上看到 TiDB 举办 Hackthon 的消息。当时好像已经得知被金山办公优化的消息，所以准备给自己找点事情做，就报名参赛了。作为一名全栈偏前端工程师，我对数据库的了解停留在基础安装、配置、优化上面。不太了解数据库生态，也不清楚各大厂牌之间的区别。我只在 teahour.fm 上听过 PingCap CTO 黄东旭的访谈，对他们只有一些粗浅的了解：
- TiDB 由豌豆荚内部项目孵化而来
- 他们试图给 KV 数据库增加类似 MySQL 的 API，让熟悉 MySQL 的用户能够无痛迁移到 TiDB 上
- KV 数据库天生便于拆分和分布式，更能适应未来的应用场景
- TiDB 是开源的，PingCap 提供基于 TiDB 的 SaaS 服务
Hackathon
2018年年底，我去北京参加了思否组织的 WeGeek 小程序 Hackthon。去之前，我以为 Hackthon 就是现场组队、现场立项，大家比拼脑洞、比拼协作能力。去了之后才知道，很多队伍都是长期合作的小团队，项目可能也做了很久，现场更多是准备答辩。结果我们当然是陪跑。这次的情况也类似。赛道提前一个月就公布了，大部分选题多半也是同期开始准备的。前面也说过，我本来就对数据库所知了了，也不熟悉 TiDB，自己没法想出好的选题，只能将希望寄托在被其他队伍招募上。没成想这是个数据库 Hackthon，对前端的需求约等于零，于是我无队可投……求组队求到最后，我准备不行我就随便整个 Ghost+TiDB 或者 IndexedDB+TiDB 之类的项目随便搞一下，不要交白卷就行。还好最后 TiDB 送温暖，派了个后端来扶贫，勉强帮我凑齐了队伍，确定了选题。
参赛
TiDB 有个周边产品，叫 Chaos Mesh，可以进行混沌测试，测试服务器集群或者容器在各种干扰下会有怎么样的表现。功能不错但体验稍逊，我们就想改进它。第一个想法是做游戏，我们设计了多个游戏方案，最终又都推翻了，因为 Chaos Mesh 其实有很多限制，都不适合用游戏来描述：
- 操作有失败的可能，不是每次都能成功
- 操作有很多，需要不同的表现方式
- 操作过程很长，多则几十分钟到数小时 眼瞅着比赛日一天天逼近，最终我们决定，先改进表单和拓扑图，毕竟纯前端用户界面类的开发，应该不会太难，有机会出成绩。这是我第一次真正写 React 应用，还是花了不少时间学习和摸索。但是最难的点不在这里，而是，项目里这块实现的不算太好，还有些 Bug……这对我来说就有点超纲了，如果是 Vue+某个我熟悉的组件库，多半也能搞定；但是技术选型我也不熟悉、产品逻辑我也不清楚，确实做不完。最终只勉强修了一个 GitHub 上的 issue，算没有交白卷吧。
比赛日
比赛日当天，我作为本组代表，到广州分赛区参与答辩。TiDB Hackthon 的现场组织非常好：工作人员友善热情积极，现场环境舒适宜人，座位宽敞舒服，网速快，还供应三餐、下午茶和宵夜。签到之后就有纪念品，还能抽奖。纪念品里有我最看重的键帽，感觉组织者真的懂。答辩进行得很顺利，因为项目做的不咋地，所以要说的东西也不多，5分钟时间比较宽松地把做过的工作都介绍了一下，然后坐到一边等待结果。事实证明我想多了。这次 Hackthon 预留了一个多月的准备时间，更有很多参赛选手从上一届就开始筹划这次的项目。所以从理念、从设计、从实施，都远胜我们。于是我们毫无悬念在预赛阶段就被淘汰了。
总结
虽然从前期报名到后面开始写代码的过程都很不顺利；立的项也被各路高手从各种方面碾压。但我必须得说，TiDB Hackthon 的组织能力真得很强，参赛选手水平真高，奖品也真给力，非常值得一来。而且仔细看 决赛项目，全都不明觉厉，如果能准备得更充分一些，相信能学到很多东西。 于是，今年我有两个打算：
- 以 chaos-mesh 作为学习 react+typescript 的入门项目，争取在春节前把这次立项的功能完成，代码合并入主干（或具备合并的条件）。今年每个季度都能贡献一些代码。
- 慢慢积累对 TiDB 的使用经验，争取在年底前能形成一个可行又有价值的提案，然后参加 TiDB Hackthon 2022。
故事16：来自 @程序员陆通
相识
了解到TIDB: 去年开始公司要做数据中台，就把市场上所有的数据中台产品调研了一遍，也把各自大数据的技术框架研究了一遍。因为自己是做Java后端开发的，对数据中台及大数据只是了解层面。万分焦躁时，刚好看到Tidb的黑客马拉松，通过官网了解了一下，看到TIDB部署非常简单就准备深入了解一下。当时的背景也要说说。当时也看了Greenplum，看了Greenplum的N多个部署文档，尝试了1周时间，竟然没有部署成功Greenplum，就投入了TIDB怀抱。
深入了解
后来 Tidb 的黑客马拉松也报名了。想着通过这个活动能深入了解一下 TiDB，看是否解决我的问题。在黑客马拉松组队阶段，设定了基于 TiDB 的大数据处理平台的主题，吸引了几个小伙伴加入了我的战队。通过与团队小伙伴交流如何参赛，如何用 TiDB 去解决我的问题。中间也有多次线上语音沟通交流。因为公司加班原因，很遗憾当时没有去现场参赛。但是通过这次活动认识了不少志同道合的小伙伴，同时对TiDB 有了非常深入的学习了解。
故事17：来自 @木木三DB | 偶遇的缘分
初识
2021年9月份，刚从上海回到武汉，由于之前在上海喜欢参加沙龙，回到武汉后竟然搜不到相关技术的活动，一线城市和二线城市的技术氛围果然是不一样，但是偶然一次机会12月11号看到TUG 华中企业行-武汉站，刚好公司也在金融港，于是参加第一届武汉的技术分享，第一次接触到TiDB,听完各位大佬演讲后，回去详细看了看TiDB，功能很强大。
相知
想把这个TiDB引入到公司层面，因为公司业务有些不符合，场景部分也不需要，希望找到下家公司的时候引入到下家公司回武汉就是因为娃的出生，现在娃慢慢长大了，能够抽出时间督促自己后续投入更多的时间到社区，多多面基参与交流，提升自己，希望TiDB发展越来越好。
故事18：来自 @张雨齐0720
第一次听说TiDB
在2018年的时候，我们技术总监像我们科普分布式数据库产品时，提到了国产开源分布式数据库TiDB，他认为以后会大有可为，建议我们多多了解学习,当时我只是一个刚毕业的小白，压根不懂数据库技术，就没有太关注。在2020年的时候，由于项目需要，在开发一款分库分表中间件。要学习支持多版本并发控制，就需要学习各种数据库的具体实现，整好TiDB开源，是很好的学习资料，我开始找最新文档进行学习，用了一个月时间完完整整的将整个文档看完了，兼容性方面了解了，完全按照MySQL方式使用就行，学习了一下MVCC知识。
后来
工作变动，进入银行，从事了数据库相关工作。时间也到了2021年中，从公众号看到在招募PCTA招生内测，我立即报名了，学习了5.0版本的课程培训，自己安装部署测试了，复习了一个月吧，参加了考试，一次考过。后续又参加了讲师招募，录讲课视频，面试，很荣幸成为了讲师（至今还没有发挥上作用），其他讲师太厉害了，我这小透明没有机会了。2021年10月看到PCTP内测招募，也是各种刷视频，上手练习，一次完成PCTP考试。2022年又参与了PCSD内测，内测考试都挺难的，低分飘过了。3次参与认证考试的内测，感谢讲师联系人王琳琳，很热心帮我推荐内测和讲师资源。后来各种逛问答区，不断学习，回复自己了解的问题，感觉一切都挺好玩的，各种有趣的人在一起。
故事19：来自 @Tank001
接触
认识tidb大概半年多了, 刚接触到tidb时主要是公司有大数据部分部署好了tidb, 说实话他也是刚接触的, 刚学习的, 部署完还是很多不完善, 很多坑没接触到, 比如我有条sql改成tidb的查询, 设计到时间的查询问题, 直接报错, 需要将时间转为字符串, 又比如再同步表后, 我把主键int类型改为Long类型时, tidb的同步居然挂了 , 这些问题导致电销系统那边的客服天天找, 麻烦得一批
后来
就到社区来提问, 学习, 后续又升级了tidb的版本号, 我之前写的sql又失效了 , 原来又是某一处还是不兼容, 行转列函数需要改下. 折腾了一段时间, 后面开始在社区学习, 看看视频 , 看看文档, 也感谢社区给我成长, 现在换家公司虽然没用上 , 但个人也在学习 , 也倡导公司能够早上用上啊哈 。已经多次向同事和领导科普(偷笑)
故事20：来自 @tjss
相识
今年公司过得很艰难，恰逢公司的大佬毕业的毕业，另谋高就的也有几个。唯我小小菜鸡仍在岗位奋斗。突然有一天，领导企微私信我，说看我学习认真工作认真，把底层重构的设计和维护交于我负责（我能怎么回，天掉下来的学习机会！我太难了o(╥﹏╥)o）。某一天领导说最近看到一些TiDB数据库的文章，说这东西很好啊，很适合我们的业务，小堂你有空调研一下哦。于是我便走上了学习TiDB的道路。
相知
我以前也没很详细地了解数据库产品这块，所以也是第一次听TiDB，于是便上官网看看，看着跟其他产品差别不大，便跟着文档学习，一开始学习比较生涩，加班加点，最后熬到脱发失眠，终于有一天我发现了原来TIDB有一个开发者社区！活跃度还很高！（为什么我之前没留意到呢！！！）在TiDB社区中，让我感觉到很有学习的氛围，各位大佬都在疯狂输出[文章、答疑]，也有社区运营每周都安排交流贴给我们诉苦，实在感觉到太温馨了。本身IT这种技术圈子就比较小，有时候很难和其他人交流沟通，在TiDB社区不一样，活跃度很高，自己有什么问题都可以随便在社区中提问，也有很多大佬灰常积极回答，即使是问题很简单的那种（我真的哭死）。工作方面压力也没这么大了，每天都可以准时下班还能锻炼一会儿。脱发失眠也不再发生，这种日子真好。虽然领导安排我的调研进度还是有点慢，但我相信慢工出细活！2022年最后一个季度，大伙加油！！
故事21：来自 @LI-ldc
相识
因为之前一直是使用mysql，在上一年的6月份，主库磁盘空间使用率到了80%以上，需要做磁盘缩容，同时数据分析需求越来愈密集，时间跨度越来越长。再加上本来上的clikchouse进展不顺，干脆就上了一套新的数据库，作为mysql的从库，缩短mysql数据保存的时长。在经过与开发的一系列选型，最后因为tidb的分布式架构、扩容简单、支持上游为mysql，社区活跃，而且融合了OLTP 和 OLAP，最终就用了它了。
相知
在第一个边缘业务上tidb的时候，由于一些图表统计的，数据模型比较复杂，在上线几分钟后，就把tidb跑崩了😂，后面紧急停了这个模块，修改了sql的写法，后面才恢复正常。后面运营反馈，业务上tidb后，数据分析变快了，同时之前在mysql分成100个库，在tidb重新合成了一个库，坚定了我们主营业务上tidb的决心。然后在21年年底上了tidb，一开始由于一些tidb的特性，比如dml的限制之类的，会造成主从同步断掉，经常需要手动修复。但是这些小问题在 查数变快的面前，可以忽略不计。现在tidb已经成为了业务系统重要的一部分。由原来的2tidb+3tikv+2tiflash。到现在拥有两套单独的tidb，每套集群超过500核。再也不需要考虑分表分库的问题了。 tidb真棒！！！
故事22：来自 @irislips
相识
2019年第二季度 的 某天，和一个老朋友聊起当时的近况。从他口中第一次了解到国产数据库TiDB，并积极的带我进入TiDB世界。从NewSQL的起源、发展、现状，到TiDB的诞生、未来前景，对我是一顿输出呀。
相知
自此开始关注、学习TiDB的。工作原因，TiDB组织的线下分享会议，只参加过一两次。倒是线上的分享会参加不少。通过雪薇的努力，2020年底，侥幸通过PCTA3.0的认证考试。本想自此深入研究学习，为国产数据库TiDB的宣传、推广尽一份力，发一份光。奈何天不遂人愿。这一年多彻底离开技术圈，也对TiDB缺少了关注。再次回首，TiDB已推出6.X的版本。期待TiDB在数据库领域继续攻城略地，在二三线技术圈创造更多岗位需求。：）
故事23：来自 @TinyData
初识
14年毕业整车厂质量管理，18年提桶跑路开始转行数据分析。现在职业规划的目标是数据产品经理，就需要熟悉数据全链路。认识 TiDB 其实蛮巧合的，在 B 站看到黄东旭讲数据库的未来（误认为黄旭东，这个星际老男孩也懂数据库？）天马行空，非常有意思。
相知
从那时开始关注 TiDB，学习课程，通过认证。而且赶巧单位新上 TiDB 集群，我成了除了运维大佬第二熟悉 TiDB 的人， 还是值得小小骄傲的。TiDB 的开源文化和社区文化数一数二，让我真正的体会到了互联网自由、开放、进取的精神。
故事24：来自 @TiCQ
相识
2021年第二季度我参与公司数据中台产品的研发，在数据源管理模块的开发过程中有人提出需要纳入TiDB数据库，当时只是把TiDB当做MySQL的类似产品接入中台数据源管理模块，这时候算是我知道了TiDB，但是没有产生深厚的感情与交集，算不上真正的了解到TiDB。时间来到2021年的9月份，我的宝贝女儿出生，在我陪产假期间发生了两件事，这才使得我与TiDB缘起；两件事一是公司组织架构变动正好涉及我当时的部门，等待我的是对新部门的抉择；二是2021年国庆节过后不久，兰州第一次爆发疫情，健康码的访问量直接导致公司相关防疫平台的数据库服务濒临奔溃，基本上都是大批量的人在”抬着”防疫平台的运行,这使得领导想在数据库方面寻找突破和分布式数据库纳入发展规划，这是契机；待我修完陪产假，居家到疫情好转，回公司我加入一个新的部门，记得新部门领导问我愿不愿意先放下大数据的相关工作，进行国产优秀分布式数据库的研究和技术掌握，这才是我与TiDB真正的开始结缘，从此便与TiDB有了深厚的缘分。
相知
2021年12月1号，我便真正的踏入TiDB的世界，开始学习《301 TiDB 系统管理基础》，在12月17号获取到PCTA认证证书，之后便落地了一套TiDB集群（TiDB v5.1.0）,在实际开发中使用TiDB替换MySQL进行TiDB的深层次掌握和学习，也为PCTP认证做准备，那段时间说真的是着迷TiDB的学习，因为我感觉学习TiDB官方推出的课程对我在数据库领域成长很有助益，之后便抽时间学完了《302 TiDB 高级系统管理》课程，在2022年1月26获取到PCTP认证证书。至此之后我开始向公司其他人员推荐TiDB，但是我也出现一段迷茫期，不知道怎么更加深入的与TiDB对话，终于某天加入了TiDB社区，开始参加TiDB组织的活动、茶话会、技术贴，以及签到，因为TiDB社区周边开始深深吸引我了，这使得我从春节节后不间断的在TiDB社区阅览帖子和签到，我也得到了许多社区周边，影响身边的同事纷纷加入TiDB社区，开始关注TiDB的发展和技术。这期间我一点不落的参与学习社区推出的新课程和新认证，2022年6月份相继获取PSCD和PCTA v6的认证证书。
相熟
2022年7月始，我寻找机会又开始公司大数据体系的建设，将TiDB和TiSpark引入公司大数据底座架构，也是数据库国产化适配选择。TiDB给我在大数据领域的发展添光加色，我个人在公司的机会也变的多了起来，也使得我在工作中更加努力和有自信；还有我获得的社区周边也影响一众小伙伴的加入壮大TiDB社区。至此，我感谢TiDB，也有幸与TiDB结缘，更希望TiDB会越来越好。我与TiDB初期的故事在这里就结束了，相信未来还有更多的故事与精彩。
故事25：来自 @Albertchamberlain
相识
嗯，第一次知道TiDB这个名词是在大三的时候，那个时候学习分布式的知识，在知乎上搜索分布式项目的时候了解到了P社的Talent Plan计划，然后又搜索了一下，知道了PingCap这家公司。在我不知道P社之前，我以为数据库要么是几十年前开源的，要么像Oracle那样付费部署使用，但是P社让我开了眼界，原来开源数据库也可以做的这么成功。另外，通过朋友圈知道了原来还有一年一度TiDB Hackathon活动，真是非常极客，非常酷的一家公司啊！！！
刚刚看了一下TiDB的Star数量已经有32.6k了,祝愿TiDB越来越好，祝愿PingCap越来越好😀
故事26：来自 @okenJiang
相识
第一次看到 PingCAP 是来源于牛客 聊一聊我眼中，中国最酷的互联网公司 ，当时是研二上的 12 月，看到后惊觉中国还有如此的公司？！以前认识到的公司都是所谓的「大厂」，什么 BATMD。技术、开源、数据库、分布式开始第一次正式进入我的世界。读完这篇文章之后，我搜寻了网上所有的有关 PingCAP 的经历介绍，比如知乎上一些前辈的入职贴、dongxu 参加的播客，甚至还有微信上有些同事家属的所见所闻。这就是我要去的公司！
相知
确认了之后我开始准备做 tinykv，中间经过了春节，断断续续花了三个月做到了 3b，一个 bug 真的能看好几天都想不出来哪出错了！tinykv 差不多之后，本来春招投了一下贵司，但被挂了，打算秋招再投贵司试试，多亏了 zq 多次提醒我让我再试试！没想到通过了😁。后面在贵司实习和工作真的学到了超多，身边的每个人都超级牛！下次再说～
故事27：来自 @OnTheRoad
初次接触
初次接触TiDB 还是2022年5月末，我在前东家机房值班的时候，其实严格来说还谈不上接触，用“听说”更恰当。电话铃声响起，那边是一位美女猎头（后期加了微信，从朋友圈确定是美女，不是抠脚大汉），说某国企公司去IOE，招聘国产数据库DBA（TiDB方向）。TiDB？腾讯的基于MySQL套娃？原谅我的无知，可能是在自己的舒适圈呆久了。脑海里对国产数据库的印象都是套娃->套娃->再套娃。从心理上，有些抵触。但是，想到前东家的种种（你懂的），这机会试试也没什么坏处。
于是
开始关注 TiDB。在我不了解一款数据库之前，我首先会看它的文档质量。如果连官方文档质量都不过关，那这款数据库可能也好不到哪里去。然后，发现TiDB的官方文档，虽然没有Oracle的全面、细致、系统，但是在国产数据库里，也称得上是天花板级别了。部署一套TiDB总共分几步，官方文档给的答案是一步，执行 tiup 即可（都不需要三步）。到这里，意识到自己先入为主的错误，这哪是TDSQL能比的啊？
后续
就开始着手学习TiDB，跳槽，做实验，写文档，备考 PCTA、PCTP。然后，许下“TiDB 社区第二届 1024 程序员心愿节”的愿望。分享我与TiDB从陌生到熟悉，再到喜欢的态度转变过程。 此-------致了😄
故事28：来自 @TiDBer_小小
心动
心动 TiDB 是因为看到同事所拥有的 TiDB 社区周边(机械键盘、充电宝等)，开始时虽然社区周边深深的吸引我，但出于工作上没有契机切入数据库，所以一直迟迟没有行动；
结缘
直到2022年6月份，参与的通用能力研发工作需要落地国产分布式数据库，在进行了TiDB、OceanBase、openGauss等一众国产分布式数据库的对比分析之后，出于TiDB的易部署、易使用、社区活跃度高、云原生等特质，最终选择TiDB进行国产数据库的落地与技术储备，这才与TiDB真正的结缘。
加入社区
2022年6月13日是我加入TiDB社区的日子，开始了日常打卡赚积分，关注茶话会，在大家的分享中寻找共鸣，同时也算是丰富个人的阅历和工作日常；在TiDB社区日常潜水和冒泡的同时，根据工作中的业务所需，进行TiDB数据库的技术掌握和实践，在数据集成平台和计算引擎中积极使用TiDB，到目前为止已经在项目实践中落地3套TiDB环境。我很期望能够通过TiDB社区学到更多的技术能力，也期望后续和TiDB日常与故事。
故事29：来自 @sanzhanggui
偶然的机会，今天突然发现了这个社区，感觉这个社区很低调，但是很有料，所以我直接注册加入成为第24725 位成员，很荣幸，也很高兴能加入这个社区。在1024到来之际，我的愿望很多，但是不离主题，那就是我希望：
1、能够找到一份合适的工作，最近离职了，有点迷茫；
2、希望社区越办越好，让更多的人知道和加入；
3、能够在上海举办一个线下面基活动；
4、 # 我想要新款挎包 #其实只要是社区周边都行，我不挑的，哈哈；
5、最后，遇到就是缘分，我希望我今天的加入就是我明天成功的开始，加油，奥利给！
故事30：来自 @DBA_尹裕皓 | 缘份在，那就终是能相遇的
初次听说
还记得那是2019年上半年的某一天，坐在旁边的师父转过来给我说：“裕皓，你有没有听过 NewSQL”，于是就有了如下一段对话： 师父：裕皓，你有没有听过 NewSQL？ 我：NewSQL 是什么？ 师父：NewSQL 就是集合了关系型数据库和NoSQL数据库的优势，既能满足弹性扩展、高可用、分布式，还能像关系型数据库一样支持事务，用SQL查询数据。 我：哦，这么厉害。 师父：是的，现在有数据库叫 TiDB，就是这样一个 NewSQL 的数据库，你可以去了解一下。 我：嗯嗯，好的，我去看下。 于是我第一次听说了 TiDB 这么一个产品。随后我找到了 TiDB 的官网（https://pingcap.com/zh/），并初步了解了 TiDB 的原理和架构。 不过当我看到测试机需要的配置后便结束了继续深入，因为即便测试机的配置要求都很高，咱当时穷呀，公司不提供测试机，自己也买不起服务器，只好作罢，不过这也成了我现在深入 TiDB 的契机。
文中提到的我的师父叫 张炜，可能成都的小伙伴们知道这个名号，因为我已经在不下3个技术交流群被问到：你们神马有个数据库大神，叫张炜，他现在还在神马没？ 其实他是我在神马工作期间的领导，当时我还是一个从 Oracle 转到 MySQL 不到一年的小小 DBA，工作期间他教了我很多 MySQL 运维管理的知识和方法，所以是我的师父没错啦，当然我平常都是随大家叫炜哥
再次接触
再次接触 TiDB 已经是2年后的2021年10月，这时距离我跳槽到G7也已经快1年的时间了。因为需要技术互备的原因，这次终于是正式进入了 TiDB 的世界。
怎么快速入门呢
官方文档是个很好的选择，不过我不太喜欢看纯文档，于是开始在各个网站找系统的视频教程，最终锁定了2个看起来比较靠谱的教程，记得费用大概在800多，不过想想还是太贵了，想着再找找看，实在不行那再买吧。最后抱着试试的心态进入了 TiDB 官网看课程有没有更新。
之前的官网也有课程，但是不成体系，每节都是负责对应业务的技术大佬来讲的，怎么说呢，大佬技术很牛逼，但多数大佬讲课真的不太行😂 然后我惊奇的发现，官网已经更新了系统的课程（https://learn.pingcap.com/learner/course），还是免费的，那免费的肯定是香呀，所以先看呗，不行再说。于是，我开启了在官网白嫖知识的日子，因为官网的新课程不仅免费，而且质量不是一般的高。
白嫖真的香
我感觉自己开始学习 TiDB 的时间真的很巧，刚想找课程，发现官网有了。免费课程学着，突然宣布 PTCA\PCTP 认证限时免费报名了，甚至一时间我都觉得自己是天选之子。
101
说学就开始，从10月底，准确的说是2021.10.21，这是我注册的日期，随后开始了101的学习，内容还是简单，很快就掌握了，课程对应的考试也做了五六次，最终达到能够满分才满意的结束了101的学习。
301
随后开始了301的学习，内容也不算太难，学习完第一篇以后发现可以报名这门课对应的 PTCA 认证，不过最近几次都报满了，那想着正好吧，我再刷一遍课程。就这样，我开始301的二刷，又刚好赶上双十一，所以“斥巨资”买了3台服务器来做测试机，期间也时不时看下新的考试场次出来了没。
最终在11月底的样子，有天晚上想看下有没有新开考试场次，结果刷出了最近的一场考试有名额放出（应该是有人退了本次考试），所以立马报名，随即开始了301课程的二刷、三刷、四刷。最终在多次刷课程以及练习后，成功获取到了 PCTA 的认证
302
拿到 PTCA 认证后，就暂时没有新的课程可以看了。悠闲的日子没有持续多久，就在元旦假期的前两天（2021.12.30），官方突然宣布免费开放302课程，并且2周内看完课程的可以获得认证机会1次
又一次的白嫖机会，这哪能错过呢，不仅可以学到新知识，还能获得官方的认证，果断加入学习计划。甚至于在第二天的时候，我觉得这次机会难得，不能被外物影响，于是果断卸载了所有游戏，卸载了抖音，专心学习课程。最终在这样的学习进度下，我在第六天完成了课程目标。
拿到考试资格后终于不用这么着急的学习了，于是稍微放慢了进度。最后在四刷课程的时候，迎来了 PTCP 的考试，当然，最终的结果也没有辜负将近一个月的学习时间。
融入社区
PCTP 认证完以后那就是真的有点闲下来了，工作之余就逛逛社区，看看有没有什么新活动；看看有没有什么问题是我可以回答的，不过咱社区的版主们真是太卷了，大部分问题根本插不上嘴。期间参加了304、305课程的内测活动，又一次知识的学习，因为这次活动也成了版主获选人。到4月份又参加了6.0的试用活动，刚好工作上开始忙了，就只体验了一个自己比较感兴趣的功能。也是这期间，有幸成为了6.0试用活动的 Reviewer，自己没时间写文章，看看别人的文章还是好的。
我需要进阶
最近又到了比较闲的时候，想到之前生产环境出现性能问题，我能够大概定位到问题出在哪，但又没法精准的评估具体的，当时就感觉自己的技术还是差了一点，一定要找个机会再精进一下。
所以想着趁这段时间空闲了，咱继续学习吧，正好攒够了兑换课程的积分，说干就干，我要开始我的进阶之旅了。
故事31：来自 @xuexiaogang | TiDB 对我不离不弃，我亦如此
偶遇 TiDB
在一次DTCC的大会上知道了有家公司要PingCAP，他们的产品叫TiDB。他们的CEO在分享的时候说我们TiDB就像我的发型一样–强一致（他是光头），很风趣是不是？又有一次看他朋友圈说，今天客户交流。有两点需求： 1、客户不能提产品优点只能批评 2、研发不允许辩解。 很霸气是不是？
初识 TiDB
有一次在我们公司会议上有人提出要用一下tidb。当时我在出差，回来有人问我（我是我们这里唯一一个从事数据库相关工作的人），这怎么样？我说可以用用。
不过企业中还是稳定为主，不会轻易尝试的。所以就给了一个非常边缘的系统这个系统是MySQL的，让我搭建一套TiDB，保持和MySQL的同步。然后适当时候把这个边缘系统切换到TiDB上。不过这一等就没谱了，因为这个边缘系统后来不用了。公司又开始降低不必要的设备支出，所以这套TiDB下线了。所以现在我并没有使用TiDB，但是我依然保持这学习的心态。积极加入生态。
我们主力系统还是Oracle和MySQL，数量不多（与大厂比起来还是少的）。但是也有不少。微服务是一方面，更多是因为担心SQL质量把这些数据库不断的分裂。所以如果这个方面得不到根本上改进，使用TiDB是很难的。因为TiDB是消灭分库分表的利器，宣称是一个不需要分库分表的大的MySQL。那么就希望用户把各个MySQL集中在一套中（或者几个吧）。但是如果一个表有100亿数据，遇到SQL质量普遍不高的环境，那么简直是灾难。不管TiDB还是什么DB基本都抗不住。而如果原来的MySQL，比如20个MySQL基础上演变成为20套TiDB，这成本客观上来说有点大。当然这不是TiDB的问题，我觉得这就不是database应该去承担的。
又有一次看到他们CTO的PPT中讲解HATP就下面这样的。估计即使不懂数据库的人看了都觉得以后需求不能乱提了，这也忒多东西在工作了。
参与TiDB 社区
今年利用一段短暂的空闲时间学习了PCTA的课程，在学习的过程中接触到了P社（PingCAP自己这也称呼）的运营人员，在运营上P社如果说第二，可能国内没有第一了。这些群里活跃度简直不亚于任何一个公司内部群。
这个过程中我通过考试也成为了MVA，这期间自我有了很大的提升。接下来上海的疫情导致我在公司关了几个月以及后续主营工作的原因，我没有继续深造，但是看着其他版主们活跃的回答问题，真的让我觉得有些事情是多么的有意义。
纯讨论技术的氛围是非常好，每天不仅能学习到知识，心情也很愉快。比起各种业务上的内卷来说，心情真的不一样。我也写了一些文章：（红框就是我）
如果遇到有条件上TiDB的企业和公司，我会推荐使用这个产品，如果能做到这样，才对得上被称为布道师。
还有的时候，参与生态是一种美好的回忆。无论是作为参与者还是评委。这些就连我的家人都觉得制作精美有意义。
写在结尾
TiDB的安装相对简单，但是技术门槛可不低，想要学习好还是不容易的。他的组件众多复杂程度也高，毕竟分布式的比单机多了很多协调。如果你的数据量很小，那么用单机。如果足够大（当然我意思是单机处理不了）考虑分布式的话，首选TiDB、其次是其他分布式。
当然我还要提醒注意一点，那就是分布式不是肆意妄为，任何数据库都要有规范。比如SQL审核与管控、不要大事务等等。这些配套基因需要具备一下，这样才能用的更好。最后一点，那就是买原厂服务。开源不是免费，开源是专家付费模式。这样才能形成更好的生态。
故事32：来自 @阿福Chris | 这一年，我和 TiDB 的故事
今天是 TiDB 社区专栏征文大赛的最后一天，现在离5月30日结束，还有半个多小时。躺在床上看手机，发现表妹在 TiDB6.0 的试用群里发了一条消息，我决定要写一写我和 TiDB 的故事，说不定能搏一把一等奖（痴心妄想脸）。从 2021年7月24日，到 2022年5月31日，也有10个月了（数字太巧合，可以尽情联想）
（没有表妹的提醒，我可能要错过征文大赛了）
2021 Dev Conf - 故事开始的地方
套用现在文雅的说法，2021 Dev Conf 是故事开始的地方，去年我阴差阳错的跟着朋友参加了 TiDB Dev Conf，那时候新冠还不叫奥密克戎，很多人天真的以为，过了2021年夏天，新冠就结束了。扯远了，回到正题，2021年7月24日，坐着高铁，我来到了 Dev Conf 会场，拿着 “争做Contributor” 的牌子，假装自己也是一枚 SQL BOY。只可惜已经过去一年了，我还没有成为 Contributor，真是难为了运营妹子的一片苦心。这次大会的主题是：开放 x 连接 x 遇见，也正应了这个主题，Dev Conf真是让人大开眼界。
人也太多了吧？
当天现场签到参会的人很多很多，据官方说远超预期，中午会务组不得不临时加盒饭🤦♂️。来看看当时的签到和会场吧，黄教主演讲时，只能看到一片黑压压的脑袋，还好，大家都有头发。
一场数据库技术会议，能来这么多人，也真是活久见。TiDB 作为国产数据库的骄傲，对开发者、DBA、伙伴的吸引力可见一斑。
TiDB 社区是什么神仙社区？
吃完早饭，吃完午饭，吃完晚饭，你们都在干嘛呢？
我在看神州数码的 Mini TiDB 集群：
（客户现场演示的利器）
这一套 Mini TiDB 集群是神州数码在现场展示的真机环境，总共由3台 Mini 电脑和一台小型交换机组成，让人眼前一亮，没想到数据库还能这么玩。据现场的老师介绍，他们去客户现场做 TiDB 产品演示时，带着这一套小集群，可以模拟 TiDB的绝大部分功能了。
我在看 Ping CAP 工程师组装的乐高 TiDB 集群：
（它是真的在处理数据哦）
这一套乐高，无疑是展厅里最吸引眼球的地方了，周围围了好多人在拍照，这套 TiDB 集群，用小球代表流动的数据，集成了 Kafka 的 TiDB集群一刻不停的在运转，就像拥有高性能和高可用特性的 TiDB 生产集群。
我在看 “SQL BOY” 做 TiDB Demo Hack：
（桌子上的免洗洗手液，我现在还没扔，今天收到了官方寄来的勋章，冥冥中都是缘分）
报名参加了黄教主亲自主持的 Demo 演示小组，这位扎着辫子，自称 SQL Boy的创始人，真是一点架子都没有，他带着我们一键生成 TiDB 集群，并完成了一个简单的增删改查项目“提醒事项”。
好玩有趣的事不止这些，为期两天的会议上，介绍了各种 TiDB 的功能、下一步规划。晚上还举行了吐槽大会，不怕暴露自己的问题，用于接受社区伙伴的 DISS，诚意满满。
谁来告诉我，TIDB 社区到底是什么神仙社区？也太会玩了吧？
我的学习之路
走过了顺利的 2021年下半年，年底奥密克戎一哆嗦，2022年整个上半年都在居家办公，好吧，居家就居家，趁有空折腾一下 TiDB 吧。顺便给自己的 Contributor 之路铺垫铺垫。
（TiDB 认证登记介绍）
我的 TiDB 学习之路，是从 PCTA 考试开始的，3月初的一天，TiDB 的小伙伴给我发了考试推荐信息，于是我开始了视频课程的学习和 PCTA 考试的准备。PCTA 的考试内容，可以说是入门级别，只要好好看完官方推荐的视频，并把知识要点统一过一遍，肯定能过。像所有其他数据库认证一样 PCTA 是 PCTP 考试的必选项，只有先通过 PCTA 才有资格参加 PCTP 考试。
2022年3月18日，经过几天视频课的学习，顺利考完了 PCTA，我的学习经验及考试要点，大家可以参考这篇文章：https://asktug.com/t/topic/603068 。请大家充满信心，因为 PCTA 考试一点都不难。
（ PCTA 的考试通过证书）
考试并不是学习的所有内容，考试是为了督促大家学习，完成了 PCTA 的考试，接下来就要开始好好学习，准备 PCTP 了，据说，这个考试有点难。所以我最近这段时间一直在学习官方文档中涉及的知识点，并在实验环境中进行练习，强化记忆。要成为一名合格的 TiDBer，至少要对各个功能模块了解的七七八八，不然真正在生产上遇到问题，都不知道如何定位和解决，这也是考试的真正意义。 最后，在此也给自己立个 flag，希望在下半年能顺利通过 PCTP 考试。
有机会参与社区
TiDB 社区有丰富多彩的活动，比如论坛里的卷王猜词活动，调动大家积极参与猜词并熟记 TiDB 技术要点；又比如社区组织的定期直播分享，用户技术实践让大家对 TiDB 的应用场景更加熟悉，内核技术分享让大家更了解 TiDB 的原理和如何贡献；又比如各地的线下活动。
提到线下活动，不得不好好说说。
随着时间来到了5月中旬，天气转好，疫情向下趋势明显，论坛里，各个地区的组织者纯纯欲动，都准备在各自的城市组织 TiDB 本地活动。看到大家在帖子上踊跃发言，我也顺手打了一句 “啥时候来济南走一波，我来当个志愿者”，没想到把 @YY 老师给蹲来了。
还顺便给自己安排了一个参与社区活动的机会，经过与 @数据小黑 @YY @Kongdom 三位社区伙伴的沟通，我们初步拟定了济南活动的框架。就因为 @YY 老师在社区论坛多看了我一眼，我就从一个社区参与者瞬间转变为一个活动组织者。在这里要给社区的运营小伙伴点个赞，热情的社区，离不开你们的不辞辛苦。接下来，可能有机会与其他伙伴一起，参与到社区活动中，成为一个 “Contributor”，成为这个有趣社区的一员。也期待随着社区的发展壮大，有更多有意义的活动让大家玩起来～
2022 TiDB 6.0 - 有更多的可能
2022年4月22日，TiDB 社区发布了 TiDB 6.0 版本，相信这又是一个里程碑似的版本，经过强化、突破和进阶的 TiDB 又会令人眼前一亮。经过了将近一年的学习和实践，我对 TiDB 也有了较深的认识，正好借着 6.0 Book Rush 的机会，了解更多新版本的特性。
也希望随着对 6.0 版本的认识不断加深，我能在社区发挥更大的作用，尽自己微薄之力，为社区的发展起到正向推动作用。
最后祝 TiDB 越来越好，希望这个有趣的社区能够聚更多的人，为中国基础软件的振兴而努力💪。
故事33：来自 @hey-hoho | 毫无准备地不期而遇，却想说与你相遇好幸运
人群中多看了你一眼
应该是好多年以前，偶然在某个技术公众号上第一次看到TiDB这个词，那时候还是一个刚工作没多久的小开发，并不能理解TiDB背后强大的设计思想，只留下一个模糊的印象：和MySQL类似的一个新的开源数据库，仅此而已。
当时也并不觉得会和它产生太多的交集，没有需求也没有场景，作为后端开发的我没有花更多时间去了解这个产品（那时候资料也比较少）。
直到2020年10月的某一天，我正在一个新项目中写着CRUD，老板突然走过来说想在项目中试试能不能用TiDB，脑子里突然蹦出来几年前的那个文章，接着在搜索引擎中试探性敲下了“TDB”三个字，打开官网文档那一刻，故事正式开始了。然后在那一年底，公司和PingCAP成为了合作伙伴，过完年我们这个团队开始All in TiDB，打开了新世界的大门。
从事了多年的后端开发工作突然转到数据库运维上其实有过一段时间的挣扎期，但是接触下来发现，优秀的产品、充满活力的社区、可爱的小团队都是我坚持下来的动力。而且越是深入了解TiDB底层原理，越能深刻体会分布式技术的魅力，不管是开发还是运维都会受益匪浅。
能够投入到这么前沿的技术领域中，我认为是一件幸运的事。
我使用TiDB的这一年
距离去年3月份拿到PCTA证书持证上岗开始刚好一整年，这一年我们团队围绕TiDB做了很多事情，包括项目交付、文章输出、参与社区建设、TiDB4PG开发、Talent Plan、Hackathon等等，每个人都伴随着团队一步步成长打怪升级。
可是到现在我依然觉得自己是一个TiDB新手，一方面是自己接触时间不长，无法与那些TiDB资深用户的社区大佬相比，也无法与那些做了很多年的专职DBA相比，另一方面是TiDB更新迭代太快了，需要不停的去持续学习。
我们的TiDB使用场景还不太一样，不像很多TiDB用户是运维自己公司内部的数据库平台，我们团队的工作偏客户交付，会和官方一起把TiDB落地到不同的客户生产环境中。因此，过去的一年我经常天南地北的出差，在做年终汇报的时候发现已经参与了大大小小20个TiDB项目，一部分已经投产，还有一部分正在投产路上。
从一个小白到能够熟练使用，真实的项目环境以及面对各种各样的问题无疑是最快的提升方式，在和官方的合作中也得到了很多PingCAP大佬的指点，受益匪浅。在这些项目中，我走过凌晨3点空荡荡的街道也熬过通宵睡过椅子，去过好多个城市也喜提过红码隔离。
我相信每一位热爱写代码的人都有这么一个愿望，就是希望自己写的代码能够运行在成千上万的设备上影响着用户，之于微信QQ一样。但是我着实比较菜运气也不够好，通过写代码的方式实现这个愿望遥遥无期。直到我亲手把打磨了半个多月的TiDB投产到服务了1千多万用户的生产环境当中，看到每天早上业务开始慢慢进来，热力图像黑夜一样开始变亮，有种感觉我的愿望被TiDB实现了。
20万QPS的场景至少是我后端开发生涯中从未遇到过的，我心想今后要努努力，争取让TiDB的某个功能中也能有我写的代码，这样它们就能运行在千千万万的机器中了。
那段时间高强度的加班让身体压力特别大，我甚至都不敢和家里说。好几次凌晨2点多回到酒店，拎着攒了几天的衣服跑到洗衣房，就呆呆地坐在沙发上看洗衣机转啊转啊转，脑子一片空白，明明应该倒头就睡那会却异常清醒。
时隔几个月，虽然过程很艰苦，我总是会怀念和小伙伴们一起战斗的感觉。
吐槽时间
做TiDB这一年让我的工作方式发生了巨大的变化，我需要在数不清的群聊里面对客户提出的问题及时响应答疑，下一秒不知道哪个客户电话就call了进来，随时待命说走就走的出差，晚上睡觉开始不敢关手机，电脑电源随身携带，还要投入大量时间用在招聘和培训中。这种完全转变的工作方式和各种琐碎事情，让我时不时怀疑自己的选择是否正确，我无比怀念以前那种沉浸式写代码的感觉。
害，感觉有点在卖惨，收了收了~ 关于TiDB产品本身在这里并不想提太多，只能说你把它用在了合适的地方它就能超出你的期望，要不然可能会有很长的磨合期。这一年来踩过不少坑、吐过不少槽、碰到不少bug，作为一款诞生不久的数据库肯定会有各种各样的问题，但是这并不影响它成为行业内非常流行的顶级产品。
在国内圈子长期占据墨天轮数据库流行榜第一名的位置，在国外它是唯一上榜DB-Engines TOP100排行榜的国产数据库。今天又偶然看到一组数据，在google搜索结果统计中另一款热门国产数据库搜索量不到TiDB的二十分之一。
就像TUG中某位老师说的，如果你是一位数据库从业者，不管你现在用不用得上TiDB，先学习准没错。
不得不说的TiDB社区
很多人接触TiDB的第一印象就被它的社区所吸引，不管是从它的文档、github互动、问答、各种学习资源、各种meetup、各种年度盛会、各种硬核技术分享、用户活跃度等等方面，没有其他厂商敢说做的比TiDB更好。这一点，我相信是大家的共识，并不是说我现在从事TiDB相关的工作才自卖自夸。
作为开源文化的一部分，社区力量对一个开源产品至关重要。在TiDB社区中，有一批头部互联网用户是它的中流砥柱，他们持续输出高质量的实践经验，给我们这些新手后来者提供了方向。一年前我是个TiDB小白连部署安装可能都要折腾很久，现在我非常乐意用我的经验去帮助那些对TiDB感兴趣的新朋友。后来在表妹的邀请下有幸成为社区版主，在asktug回答问题成为了我重要的学习方式。
2021年7月的DevCon大会是一场大型网友见面会，我在大会上见到了版主团队的其他成员，还有号称技术小白的表妹。这种感觉就像，每一位用户或者说TiDB爱好者都离社区和产品很近，说不定擦肩而过的人就是曾经帮你解决问题的某个大佬，CTO会亲自下场带大家写代码，和大家一起当选手参加Hackathon比赛，CEO会经常关注社区用户的声音回复你的问题。从老板到一线运营人员，大家都不遗余力地在做社区这件事情，从诞生之初这就是TiDB特有的基因。
表妹对我们版主团队简直不能再好，各种TIDB周边礼物管够，有新周边准备上架先给我们尝鲜，每逢过节也费尽心思给我们准备礼物手写感谢信。以至于被某位版主家属“抱怨”，是不是加入了什么非法组织，三天两头就收到奇怪的快递。保守估计，我收到的TiDB周边起码50件以上，我就这么凡尔赛的说了，大家有的周边版主都有，大家没有的我们也有。
但是真要说秀儿，我还得服Kongdom大佬，秀归秀但也是我们的真实写照。
某天晚上我把放在家里的礼物整理了一下，满满地堆了一桌子，这还不包括我转送给别人还有放在公司的那部分，估计P社的同学看了也要投来羡慕的目光。
你以为表妹只会整这些物质奖励收买人心？那必然不是，除了丰富的周边，表妹还给我们争取了太多太多学习特权，比如版主资料库、P社员工才能访问的Knowledge Base、PE课程永久观看、免费考试资格、每月一次的直面产研大佬的交流会等等等等。
有时候大家会开玩笑说，版主团队是TiBD社区最卷的一拨人，举个例子，版主交流会每次都要开到晚上10点多，你能想象到我是唯一缺席过的人？太可怕了。
去年12月份，经过我们公司和TiDB社区运营团队联合策划，TUG企业行活动第一次走进华中地区落地武汉，到场参会人数远远超出我们的预期。如今第二场武汉交流活动也在筹备当中，欢迎大家加入我们~
做这个事情，我们不仅仅是给TiDB布道，更希望以TiDB为契机带动武汉的技术影响力，当人们谈起互联网谈起IT的时候，除了北上广深杭成，还能立马想到武汉。
我们的小团队
过去的一年，感谢老板们对TIDB的大力支持，我们成为相对稳定的小团队，大家可以专注在研发、交付、社区三件事情中。这一年有小伙伴离开，也有新人加入，我因此需要投入更多的时间在新人招聘和培训中。
但每次得知有小伙伴将要离开，我总会心情沉重，一是因为能在熙熙攘攘的人群中相遇是缘分，二是团队又少了一个中坚力量，祝福大家的同时只能为团队感到惋惜。
不管怎样，我希望立足当下的选择，和小伙伴们一起在TIDB上做出一些成绩，这样也算不辜负自己的热爱、付出的时间。
最后，希望TiDB能继续乘风破浪，一路高歌，代表国产软件在各行各业中占据不可撼动的地位。
这样，我就能抱着大腿起飞了，hhhhhhhh~
故事34：来自 @angryart | 从2018到2022: 一个大数据工程师眼中的TiDB
前言
岁月是一把杀猪刀，我把近几年对TiDB的回忆、思考、理解、定义写成一段真实的故事，做为国产数据库人气一哥成长的见证者，我看着他一路成长，希望TiDB后面的路可以越走越顺。
2018年
初识TIDB,那是2018年8月份，当时基于国产数据分析产品调研的背景，我在网上东寻西找，搜查奇珍异宝，然后TiDB跃入眼前。2017 易观 OLAP 算法大赛，TiDB居然获得冠军，这个比赛我有关注过，没有想到是TiDB拿了冠军，TiDB是谁？它做了一些什么？ 第二名是我们耳熟能详的Clickhouse，居然比Clickhouse还快，相信工程师都好奇了。回顾2017 易观 OLAP 算法大赛题目，这是一道用户分析业务场景，漏斗分析题目，我们在购买商品的过程中，需要触发的事件包括 “启动”，“登陆”，“搜索商品”，“查看商品”，“生成订单”并在系统后台生成相关数据。业务需求如下
（1）计算2017年1月份中，依次有序触发“搜索商品”、“查看商品”、“生成订单”的用户转化情况，且时间窗口为1天。
（2）计算2017年1月和2月份中，依次有序触发“登陆”、“搜索商品”、“查看商品”、“生成订单”、“订单付款”的用户转化情况，且时间窗口为7天，“搜索商品”事件的content属性为Apple，“浏览商品”事件的price属性大于5000。
根据官方的介绍，市面上现有的解决方案在数据量较大的情况下，计算效率较低，为了更好的提升用户体验，如何更好的解决问题。官方给出60分合格的解决方案，1底层存储用HDFS，2建立Hive表，并以应用标识、日期、事件名称为分区，3查询用presto，并自定义UDAF，或者利用Spark core自定义相同逻辑。
即使基于内存的presto的解决方案，也是刚及格而已，我的对TiDB的描写，记录在2018年我的《XXX报告》里面，如下
之前我们介绍的另外一个数据服务公司易尚国际，它举办了数据大赛，由PINGCAP获得了冠军， PingCap的产品叫做TIDB。准确来说TIDB不是一个数据查询引擎，它是一个数据库，性质属于 NEWSQL,它是立于谷歌spaner/F1的论文思想。TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景 ,一脚踏两船，在OLTP和OLAP两个领域提供一站式的解决方案。
我对TIDB的第一印象是此物一心两用，主业是OLTP，副业是OLAP，一脚踏两船，但是我始终没有搞明白它是怎么做到一脚踏两船。当时我印象中它已经GITHUB开源，但是文档社区没有那么成熟，所以笔者没有展开安装测试摸底。下图是当初调研的数据库，当时没有gauss，没有OceanBase。
2019年
2019年，TiDB的市场推广非常成功，周边的小伙伴都知道TiDB，但是我始终不了解TiDB的技术细节，只知道它是大一号的MySQL,MySQL能做的它都能做，MySQL不能做的它也能做。终于一天，我下定决心，在自己的虚拟机上，通过ansible安装了3个节点阵容，每个节点是4C和4G，基于tpc-h做了基准测试，并把理论认识付诸实践，做了相关的实验验证，对TiDB有了宏观的了解。
我始终好奇2017年的TiDB是怎么拿下比赛的冠军？那是一场OLAP比赛， 当时TiDB还没有Tiflash引擎，主要分为三大块，分别是TiDB、TiKV、PD, TiDB本身是无状态的计算引擎，估计当时做了特别设置使热数据都活跃在TiDB里面，如果是冷数据再往TiKV查找。在数据写入硬盘的底层方面，TiDB选用了RocksDB，RocksDB兼容LevelDB原有的API，并且对LevelDB进行了一系列的优化，包括对SSD硬盘的优化，针对多CPU、多核环境进行优化，增加了LevelDB不具务的功能，例如数据合并、多种压缩算法、按范围查询等数据存储管理的能力，RocksDB就是TiDB的性能天花板。2017年的易观大赛，当时没有Tiiflash的状况，TiDB基于此等条件获得了冠军。
TiDB后面的创新，将OLTP存储与OLAP存储解耦，OLTP的性能天花板是RocksDB,而OLTP写数据的时候，会有一份数据写入TiFlash，OLTP存储与OLAP存储物理分离，对外却是统一的逻辑管理系统，TiDB提供SQL访问访问入口，让传统的DBA可以像使用MySQL那样使用TiDB。
2020年
TiDB十分注重用户的感受和产品的质量，2020年TiDB做了两个事让我记忆犹新，一个是TiUP，TiUP是对一个TiDB集群的生命周期管理维护的项目。发起这个项目的原因，当时TiDB做了调研，即使大厂的研发工程师安装一个低配的TiDB集群至少也要花费三个小时，所以有了TiUP项目，通过TiUP很快就部署了一个TiDB环境。第二个是产品抓虫的大赛，每一个产品都有BUG，TiDB开诚布公，悬赏找虫，不分地界，引起国外工程师的关注，其中苏黎世理工大学的Dr. Manuel Rigger通过引用最新技术NoREC找出最多的BUG。开源无国界，TiDB致力于开源技术布道，同时也在寻找市场上商业机会，推出的TiDB Cloud也得到人们一定的认可，TiDB Cloud立足于TiDB技术内核实现云计算的弹性敏捷可用性，让广大开发者更方便使用TiDB。
2021年
2021年TiDB推出5.0版本，在原有 HTAP 引擎 TiFlash 的基础上引入 MPP 架构，提供与存储匹配的分布式计算引擎，进一步提升海量数据下的并行计算与分析能力。通过与 TiDB-Server 共享 SQL 前端，实现解析器（Parser）和优化器的共享，TiDB 向业务提供一体化的入口，能够自动选择单机执行或 MPP 模式，并且将事务型和分析型的负载隔离，使得双方在高并发量压力下互不干扰。这个时候我非常好奇TiDB模块的优化器的工作细节，现在的5.0版本，它要识别单读还是批量操作，还要考虑Tiflash的数据分布和持续的数据管理，数据是从OLTP还是从OLAP找，TiDB承载的智能调度工作量比以前大了，它需要比以前更多与TIKV和PD协作才能高质量完成工作。
TiDB Hackathon 2021大赛，He3 团队就选择了冷热数据分层存储，设计中将热数据存放在 TiKV 上，将查询和分析几率比较少的冷数据存放到便宜通用的云存储 S3，同时使 S3 存储引擎支持 TiDB 部分算子下推，实现 TiDB 基于 S3 冷数据的分析查询。其实这就是业界追求的智能数据集成系统应用场景，集成系统能够识别广大的数据源，包括RDBMS、NOSQL、分布式系统、文件系统等等，能够对进行识别并进行连接，采集数据到最近的存储系统里面，这样第二次第三次直接去最近的存储系统。关键核心技术挑战是智能调度识别最近的存储系统与数据源的一致性， 同理TiDB在这里要识别TiKV和S3的一致性，对TiDB提出更高的要求。
我定义了TiDB模块的概念范围，TiDB模块是一个实现分布式【包括单机计算能和批量计算】、无状态、实现SQL、客户端输入连接会话管理的计算引擎。开源界有一个Presto,但是Presto是完全局限于内存的处理能力，但是Presto没有存储引擎成为不了数据库，TiDB与PD和TIKV联合在一起成为数据库， 独立TiDB的模块可以嵌入集成到其它系统上，例如冷热数据分层存储，整个数据集成数据链路中，TiDB作为智能调度处理组件，承担上下游数据的管理传输。
从TPC-H和TPC-DS认识TiDB
小白出身农民，立志改变命运，终于开了五金的电子商务零售网站，天下还有很多像小白一样的人们，他们都想趁着互联网浪潮，趁势而下，大赚一笔，但是他们未必是五金生意，有可能是外卖，有可能是玩具，有可能是生活用品。不管销售什么，至少有供应商、用户、商品等独立基础实体， 依赖基础实体之上有商品采购入货和商品外售的记录，如果我们往细节追究，还有商品评价、商品收藏、商品营销方面的考量，这里我们忽略它。8个表包括suplier表供应商信息、nation表国家信息、region表地区信息、customer表用户表、part表商品表、partsupp表商品供应表、orders表零售订单表、lineitem订单明细表构成最基本元素的电子商务框架，可以视为最通用的数据库设计，基于范式设计的结构如下，一个电子商务应用网站上线了。
一个可靠稳定的电商平台不但可以承担成千上万的流量，而且安全无误的执行每个行为。举个例子，商品上线一万个商品，有十万个客户上来争相哄抢。底层背后，相同一个数据对象被多个人浏览阅读，放入购物蓝、生成订单、交易结帐后客户的钱包扣钱，而商家帐户正确流入客户资金 ，同时商品数目正确扣减。保障客户、商家、商品数目的一致性，即使服务器宕掉、网络延迟、自然灾害导致的地震海啸或者人为主观的恶意性的原因，三者依然保持一致性，不会发生客户扣钱了但是商家没有收到了，或者商家入帐了而客户那边还没有扣钱，商品数目与交易数量对不上出现超买超卖的情况。
更加不可能发生停止对外提供服务的可能性，交易窗口24小时对外开放，不休不眠，对于互联网来说，每一秒都是金钱。基础设施稳定可靠、服务平台稳定可靠、系统服务稳定可靠，业务工作的过程中一直被审计，不管出现什么问题都要可追溯、可跟踪。
对于业务不断递增的电商平台，传统的单机解决方案要存在IO瓶颈，无法应付高流量，而NOSQL解决方案完全否决关系范式建模，只能用文档建模或者键值健模对原生业务应用侵入大，给传统应用开发工程师加大了工作量。中间件解决方案固然解放了应用开发工程师的生产力，却给后台的DBA带来更多的运维工作。1.减压问题，其中一个节点压力过大，如何保障业务正常的前提下把压力转移到其它节点上面。2.扩容 加入新的节点，如何让新节点正好划分合适的数据。
当这个电子商务网站沉淀了大量的数据，需要做数据分析去理解用户的偏好和市场的需求。基于8个表的结构，我们构建了22个模型，这个就是tpc-h基准测试了。每个模型都少了多表关联，最长的有4个表关联或者5个表关联，关联后做聚合、过滤、分组、归并、排序等等。
为了深入理解用户的偏好和市场的需求，数据维度越来越多，需要加入评价、收藏、浏览、点藏维度，而且数据的不断增长，与数据计算能力呈正比，添加更多的服务器固然可以提高计算能力。但是消除冗余的范式建模不适合复杂业务分析景，例如拉链表，每天增加那么一丁点数据，业务上希望那一点变化发生在单表上，分析模型底层太大变化。
阿里的业务也是维度建模，维度建模不像关系建模那样消除数据冗余，相反它集成更多的数据冗余，提高计算能力，tpc-ds就是采取了维度建模，tpc-ds与tpc-h的的本质区别就是不同角度的应用建模，tpc-h还能够为OLTP在线应用服务，而tpc-ds完全没有考虑范式，更加关心分析主题。tpc-ds模型模拟一个全国连锁的大型零售商的销售系统，其中含有三种销售渠道：store（实体店）、web（网店）、catalog（电话订购），每种渠道使用两张表分别模拟销售记录和退货记录，同时包含商品信息和促销信息的相关表结构。TPCDS采用雪花型数据模型，三种渠道的销售、退货表、及总体的存货清单作为事实表，其他商品相关信息、用户相关信息、时间信息等其他信息等都作为维度表，同时各表命名达到见名识义，详细如下表所示：
很明显，tpc-ds的业务主题是销售渠道分析模型，根据模型业务人员很快可以进行渠道比较、渠道强弱，渠道环节对比、购买订单分析，但是不擅长财务分析模型、人力资源分析模型、装运分析模型、库存管理分析模型。7张事实表和17张维度表如下，简单两表关联通过星型模型完成大部分的业务分析场景，再复杂的业务通过雪花模型也可以完成。
tpc-h的特征如下
- 测试大规模数据，解决大数据问题
- 对实际商业问题进行解答
- 执行需求多样或复杂的查询（如临时查询，报告，迭代OLAP，数据挖掘）
- 以高CPU和IO负载为特征，
- 通过数据库维护对OLTP数据库资源进行周期同步
前面说过了TPC-DS采用维度建模，与TPC-H的范式建模，所以必须要发生ETL过程。现实版的TPC-DS应用要打通多个数据源，对接多个数据库，对数据进行清洗、整理、规范，统一置放到数据仓库里面。根据业务调整数据分层分类分级，设计面向主题的数据集市，特别需要全局和发展的视角，建模应该在理解整体业务流程的基础上。
结尾
最后概括TiDB解决的问题 ，TiDB是一个开源的、分布式、计算存储分离、弹性可扩展、支持行式列式、实现HTAP功能的数据库。首先它可以做业务应用的数据库，勿论它的OLTP可以去到多少并发，肯定会比MySQL高，事务、ACID、并发、封锁、串行化它都支持，所以解决100%的业务问题，当数据存储沉淀到Tikv，同时会相同的数据沉淀到TiFlash，TiFlash是列存存储，TiDB对TiFlash的访问操作是通过MPP的方式进行，但是由于关系范式建模的原因，TiDB可能以类似TPC-H复杂的SQL做数据查询，充其量只能解决30%的分析问题。更复杂的数据应用系统建设，需要通过自身的生态工具把数据从TIKV转移到HADOOP，另立数据仓库重新维度建模组织管理，可以解决70%的问题 。
写在最后
一条一条的看完了大家全部的故事，有的小伙伴说遇见 TiDB，遇见社区是一种幸运，对于 TiDB 来说也是如此。很感谢所有 TiDBer 们为 TiDB 做过的所有，大家的每一句回复，每一篇文章都对我们无比重要。TiDBer 们就像是宇航员一样，守护着我们共同的Ti星球，在宇宙深空里一起去探索更多技术的可能性。最后的最后想在故事集里面跟所有 TiDBer 们说一句：遇见你们，真好～