命里有时终须有--记与TiDB的一次次擦肩而过

作者： 数据小黑原文来源：

https://tidb.net/blog/1ec54d5b

我

我是一个非常有重量的人，买衣服只买迪卡侬，是因为迪卡侬的号大。我曾经崇拜过一个技术大拿，很牛的那种，体重比我还大，所以我很释然，也觉得做技术也许体重大是标配。我是个老头，在社区里面，很自信的说，我的年龄数一数二的大。我也接触过非常多的东西，我曾经搞过 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 。虽然 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

详情：

https://tidb.net/blog/de9bf174

生命不息，折腾不止

随着年龄增大，越来越认识到知识储备的重要性。汲取知识的重要方式是深度参与社区。于是，我就：

于是，我就：

于是，我就：

还有以下，懂得都懂，hhhhhhhhh：

最后，感谢贵司，让我圆了一个分布式数据库的梦。