关于tidb:TiDB-in-2023-一次简单的回顾丨PingCAP-唐刘

<article class=“article fmt article-content”>2023 年曾经过来，TiDB 通过了一年的迭代，又往前提高了一点点，咱们十分骄傲的看到，TiDB 正在一直地帮忙咱们的客户胜利，包含但不限于：○ 首个云原生、分布式、全栈国产化银行外围业务零碎投产上线丨TiDB × 杭州银行○ 国产数据库的珠穆朗玛峰，到底在哪里？ ○ Scaling TiDB To 1 Million QPS ( https://blog.flipkart.tech/scaling-tidb-to-1-million-qps-d556… )○ …… 要获得下面的问题并不容易，在 2023 年咱们也经验了很多，上面，我会简略的梳理回顾下，咱们在 2023 年一些有意思的事件。<h2>TiDB 6.5</h2>在 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 或者更简单的场景的时候，新的问题又来了。<h2>TiDB 7.1</h2>在 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，反对好这些业务场景，复制到其余客户，助力客户胜利。<h2>TiDB 7.5</h2>随着越来越多的客户将 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 在品质下面做的工作。坦率的说，直到现在，我也没找到一系列很好的指标来评估咱们收回去的一个版本品质到底好不好，无论咱们做了多少的测试，我总认为是不够的。<h2>小结</h2>下面就是 TiDB 2023 的一个简略的回顾了，咱们在 2023 年真的获得了许多十分不错的问题。总结来说，就是咱们公布了一个不错的产品，以及明确了以稳定性为根底的研发策略。回顾 2023，咱们也有不少做错的中央，也走了一些弯路，这个有机会，前面再从新开一个新坑，讲讲『那些年咱们开发 TiDB 所踩过的坑 :-) 』。对于 2024 年，在 TiDB 下面，咱们也会十分聚焦，首先依然会以稳定性为根底，在这个根底下面，咱们会投入带宽来改良 TiDB 的可观测性以及晋升一些场景上面的性能，具体的大家能够关注咱们 TiDB 的 roadmap，咱们会定期的刷新。在 2023 年，咱们在 cloud 下面也获得了不错的停顿，在前面一篇文章中，我就会来讲讲 “TiDB Cloud in 2023”。</article>