TiDB in 2023， 一次簡單的回顧丨PingCAP 唐劉

PingCAP發表於2024-02-15
TiDBPingCAP

2023 年已經過去，TiDB 經過了一年的迭代，又往前進步了一點點，我們非常自豪的看到，TiDB 正在不斷地幫助我們的客戶成功，包括但不限於：

○  首 個雲原生、分散式、全棧國產化銀行核心業務系統投產上線丨TiDB × 杭州銀行

○  國產資料庫的珠穆朗瑪峰，到底在哪裡？

○ Scaling TiDB To 1 Million QPS (  blog.flipkart.tech/scal  )

○ ……

要取得上面的成績並不容易，在 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 (  github.com/pingcap/tidb  )。這個工作非常的重要，在沒開始之前，如果我們在本地單純的跑 TiDB 的 UT 測試，不出意外，大機率會跑掛，即使透過，耗時也接近 50 分鐘，而這個工作開始一段時間之後，我們當前跑完 UT 只需要 15 分鐘（後面還會繼續最佳化），這個對於我們自身的測試效率是一個極大的提升，當效率提升之後，我們就能有更多的時間寫程式碼，加測試了。

這裡僅僅只是簡單的列了一些我們在質量上面做的事情，如果後面有機會，我可以專門寫一篇文章講講 2023 年 TiDB 在質量上面做的工作。坦白的說，直到現在，我也沒找到一系列很好的指標來評估我們發出去的一個版本質量到底好不好，無論我們做了多少的測試，我總認為是不夠的。

小結

上面就是 TiDB 2023 的一個簡單的回顧了，我們在 2023 年真的取得了許多非常不錯的成績。總結來說，就是我們釋出了一個不錯的產品，以及明確了以穩定性為基礎的研發策略。回顧 2023，我們也有不少做錯的地方，也走了一些彎路，這個有機會，後面再重新開一個新坑，講講『那些年我們開發 TiDB 所踩過的坑 :-) 』。

對於 2024 年，在 TiDB 上面，我們也會非常聚焦，首先仍然會以穩定性為基礎，在這個基礎上面，我們會投入頻寬來改進 TiDB 的可觀測性以及提升一些場景下面的效能，具體的大家可以關注我們 TiDB 的 roadmap，我們會定期的重新整理。

在 2023 年，我們在 cloud 上面也取得了不錯的進展，在後面一篇文章中，我就會來講講 “TiDB Cloud in 2023”。


來自 “ ITPUB部落格 ” ，連結：https://blog.itpub.net/69994146/viewspace-3006642/，如需轉載，請註明出處，否則將追究法律責任。

相關文章