一个小型网站设计,黄山公司做网站,wordpress 浮层,辽宁大学网站怎么做2023 年已经过去#xff0c;TiDB 经过了一年的迭代#xff0c;又往前进步了一点点#xff0c;我们非常自豪的看到#xff0c;TiDB 正在不断地帮助我们的客户成功#xff0c;包括但不限于#xff1a;
○ 首个云原生、分布式、全栈国产化银行核心业务系统投产上线丨TiDB …2023 年已经过去TiDB 经过了一年的迭代又往前进步了一点点我们非常自豪的看到TiDB 正在不断地帮助我们的客户成功包括但不限于
○ 首个云原生、分布式、全栈国产化银行核心业务系统投产上线丨TiDB × 杭州银行
○ 国产数据库的珠穆朗玛峰到底在哪里
○ Scaling TiDB To 1 Million QPS ( https://blog.flipkart.tech/scaling-tidb-to-1-million-qps-d556aa6a16ef )
○ ……
要取得上面的成绩并不容易在 2023 年我们也经历了很多下面我会简单的梳理回顾下我们在 2023 年一些有意思的事情。 TiDB 6.5
在 2022 年的年底我们发布 了 TiDB 6.5 LTS 版本 这个版本我是非常期待的。实际结果来看到 2023 年截止TiDB 6.5 已经逐渐成为客户最重度的使用版本。
在 TiDB 6.5 之前用户高频吐槽我们的一个问题就是 - 有时候来了一个大查询直接把 TiDB Server 给弄 OOM 了这样影响了一批其他的请求。所以我们在 TiDB 6.5 重点解决了 OOM 问题结果也是很令人满意的下图是我们实际在 TiDB Cloud 上面客户集群的报警情况可以看到TiDB OOM 的问题下降的非常明显。 不光在 TiDB Cloud 上面我自己也从客户那边得到了非常多的直接反馈。 除了 OOM 问题的缓解在 TiDB 6.5 里面我们还重点的优化了 DDL 的速度增强了优化器的能力等等。 所以在 2023 年一开始我是信心满满的觉得 TiDB 6.5 版本已经很不错。 现在想想我那时候真的太天真了。
『不错』这个 flag 立了之后立刻被打脸。TiDB 6.5 解决了不少之前客户遗留的问题不过当客户开始更大规模使用 TiDB 把 TiDB 用到更 critical 或者更复杂的场景的时候新的问题又来了。
TiDB 7.1
在 2023 年有一段时间我一般见到做数据库的朋友都会问他们一个看起来比较好玩的问题『你的客户有试过一次性导入一张 50TB 大小的单表吗』如果是做 TP 数据库的朋友通常会来一句『哪有这样的场景』
嗯我本来也以为『哪有这样的场景』直到我们一个北美的客户真的进行了这样的操作。他们在 4 月份的时候开启了一次单表 50TB 的导入操作开始的结果是悲催的 - 无论客户怎么操作导入都遇到各种各样的问题包括但不限于数据倾斜打满了一台 TiKV 的磁盘PD 在 scatter region 的时候太慢导致的导入 timeout 等。本来我们希望帮助客户去操作导入这样我们遇到问题之后能直接修复然后继续不过这个提议被客户直接拒绝因为他们就是要自己亲自验证能一次性的导入成功。
随着客户多次导入失败客户生气的放下狠话如果一周后还搞不定那么就不用 TiDB 了。压力到了我们这边我们开始了几乎连轴转的导入增强工作终于在一周后客户直接一次性的单表 50TB 数据导入成功。
这一次的导入优化经历让我们学习到了很多如果有机会后面可以再开文章详细说明。当然也有很大的收获在北美这个客户导入成功一周以后我们日本的一个客户进行了单表 100TB 的数据导入结果当然是非常振奋人心的。
挑战还不仅仅限于此又是北美的一个重要客户他们将他们自己非常核心的一个元信息管理的业务放到了 TiDB 上面然后这个业务大部分时候都只是涉及到 meta 的简单操作属于 TP workload不过也有不少的时候他们需要直接进行一些轻量级的复杂查询而且明确要求了当这样的复杂查询过来的时候几乎完全不能影响他们的 TP workload。这个在 TiDB 6.5 还是比较有挑战的。而不光是这个客户我们也发现越来越多的客户将多个负载跑在一个 TiDB 集群负载之间的隔离就变得尤其重要。于是我们跟这个客户一起开始了 resource control 的开发也取得了非常不错的效果。 上面只是分 享了 TiDB 7.1 LTS 两个功 能的开发经历我们也非常欣喜的看到这些功能都得到了客户非常积极正向的反馈。也坚定了我们 - 聚焦样板客户的业务场景不断打磨 TiDB支持好这些业务场景复制到其他客户助力客户成功。
TiDB 7.5
随着越来越多的客户将 TiDB 用在非常核心的系统上面在发布 TiDB 7.1 之后我们决定在 TiDB 7.5 LTS 版本我们将专注于产品质量的提升。产品质量是一个很大的话题这里仅仅列一些我们做的一点工作。
我们认为要控制版本质量一个非常朴素的逻辑就是少做 feature当然我们不可能不做 feature所以这一定是基于我们当前团队带宽的一个平衡和折中。下面是我们大概统计的不同 LTS 版本开发的 feature 个数可以明显的看到趋势是明显减少的。因为做的 feature 少多出来的带宽我们就用到更多的质量加固的工作上面所以我非常有理由相信我们的 TiDB 的质量会越来越好。 减少 feature 个数对于研发工程师来说是一个极大的挑战因为在很多研发的脑子里面还是固有的认为我要通过做更多的 feature 来拿到更好的绩效以及晋升。所以在 2023我们花了大量的时间来解释为啥我们要控制 feature 个数加固质量等而且也会在绩效上面对相关工作的同学进行了倾斜。
这里大家可能会有另一个疑惑就是我们 feature 做的少产品的竞争力是不是就不行了之前我也是这样的认为不过后来我发现我自己做为程序员也一样我们太容易低估业务的复杂度而高估自己的技术能力所以总认为自己能开发很多 feature。不过后来我认识到与其开发 10 个半吊子的 feature真的还不如好好的开发 5 个或者更少的开箱即用的 feature这样给客户的感受会更好。这也是我们后面会持续努力的目标。
譬如在 7.5 里面我们花了大量的经历仍然去完善和优化 resource control譬如我们引入了 runaway query 机制给用户提供了对于 heavy query 的控制机制更好的防止了一些突发 heavy query 引起的 TP 业务抖动问题效果如下 除了控制 feature 的个数我们还致力于提升我们自己的测试效率2023 年一个非常大的工作就是将很多写在 unit test 文件里面的 integration tests 挪出去让 UT 真的变成 UT详细见这个 issue - Split integration tests(IT) and unit tests(UT) in TiDB repo ( https://github.com/pingcap/tidb/issues/45961 )。这个工作非常的重要在没开始之前如果我们在本地单纯的跑 TiDB 的 UT 测试不出意外大概率会跑挂即使通过耗时也接近 50 分钟而这个工作开始一段时间之后我们当前跑完 UT 只需要 15 分钟后面还会继续优化这个对于我们自身的测试效率是一个极大的提升当效率提升之后我们就能有更多的时间写代码加测试了。
这里仅仅只是简单的列了一些我们在质量上面做的事情如果后面有机会我可以专门写一篇文章讲讲 2023 年 TiDB 在质量上面做的工作。坦白的说直到现在我也没找到一系列很好的指标来评估我们发出去的一个版本质量到底好不好无论我们做了多少的测试我总认为是不够的。
小结
上面就是 TiDB 2023 的一个简单的回顾了我们在 2023 年真的取得了许多非常不错的成绩。总结来说就是我们发布了一个不错的产品以及明确了以稳定性为基础的研发策略。回顾 2023我们也有不少做错的地方也走了一些弯路这个有机会后面再重新开一个新坑讲讲『那些年我们开发 TiDB 所踩过的坑 :-) 』。
对于 2024 年在 TiDB 上面我们也会非常聚焦首先仍然会以稳定性为基础在这个基础上面我们会投入带宽来改进 TiDB 的可观测性以及提升一些场景下面的性能具体的大家可以关注我们 TiDB 的 roadmap我们会定期的刷新。
在 2023 年我们在 cloud 上面也取得了不错的进展在后面一篇文章中我就会来讲讲 “TiDB Cloud in 2023”。
