劉奇：當今一切都要更實時、更彈性、更簡單，TiDB 就是這樣的基礎設施 | TiDB DevCon 2020

6 月 7 日，TiDB 社區年度技術大會 TiDB DevCon 2020 圓滿落幕，本屆大會採起線上直播的形式，匯聚了來自全球各地的 80+ 開發者、TiDB 用戶及合做夥伴分享第一手開發及實踐經驗，議題覆蓋金融、電信、電商、物流、視頻、資訊、教育、醫療等諸多行業，乾貨滿滿，應接不暇。會上咱們正式發佈了具備里程碑意義的 TiDB 4.0 GA 版本，並分享了技術細節及生產環境的實戰效果，併爲過去年在 TiDB 社區做出卓越貢獻的 Contributor、Committer、Maintainer 授予了榮譽獎盃與證書。

本屆大會歷時 2 天，共設置 7 個論壇，29 小時累計分享時長，直播間人氣值高達 2.3 萬，錯過的小夥伴們能夠繼續「蹲守」本公衆號近期推送，咱們將陸續挑選整理部分精彩內容輸出，敬請期待！

如下是我司聯合創始人兼 CEO 劉奇的現場分享實錄。

每一年我都有一個時間會特別激動，就是產品大版本發佈的時候，一般也是社區年度技術大會 TiDB DevCon 舉辦的時間。去年 TiDB DevCon 2019，咱們發佈了 TiDB 3.0 Beta，固然今年 TiDB 4.0 GA 也如約而至。

Serverless

很長一段時間 TiDB 用戶使用的集羣規模都很大，而後就會再提出一個訴求說「怎麼下降個人使用成本」。TiDB 4.0 擁有了 Serverless 能力以後，會根據用戶的實際業務負載，基於 K8s 自動作彈性伸縮。

從前，當咱們在上線一個系統的時候，第一件事就是 Capacity Planning，去評估一下咱們大概須要多少臺服務器，好比提早準備了 50 臺，可是實際上線以後跑了一個月，發現 5 臺機器就夠了。這就致使了大量的資源浪費。若是整個系統可以在雲上全自動彈性伸縮，就能避免這種資源浪費。

更重要的是，TiDB 的彈性伸縮，意味着你永遠不須要按照業務的峯值配備系統資源。好比你們的業務會有早、晚兩個明顯的高峯，但實際上每一個高峯持續時間一般只有 2 個小時左右，也就是說，爲了這 4 個小時的高峯，而咱們配置了 24 小時的最高資源配置，併爲此付費，但非高峯時間的資源和成本徹底是能夠節省的，可能算下來，咱們可以節省的成本大概在 70% 左右，甚至更高。

另外，可以彈性伸縮的 TiDB 能夠應對沒法預測的 Workload，沒有人知道哪個商品在何時會大賣，沒有人知道我賣的哪個基金在何時會火，這時若是咱們給系統一個權限，讓它可以自動根據業務當前的實際狀況，擴充服務器，這對某個企業或者某個業務來講，多是「救命之道」，好比像上圖的狀況，人爲介入每每是太慢了，來不及了。

Real-Time HTAP

在當今這個世界，你們但願全部的東西都要更快、更簡單。但若是你們仍是按照傳統的方式去運用一個數據庫，就不能知足這個「更快、更簡單」的需求了，由於傳統的方式須要通過一系列很是複雜的過程從數據庫裏面去提取這些變化的信息、事件、日誌，再去作分析，那這個過程每每會帶來比較長的延遲，這些「延遲」讓咱們失去了不少直接的經濟價值。

在 TiDB 4.0，咱們正式推出了 TiFlash，TiFlash 是配合 TiDB 體系的列存引擎，它和 TiDB 無縫結合，在線 DDL、無縫擴容、自動容錯等等方便運維的特色也在 TiFlash 中獲得繼承，同時 TiFlash 能夠實時與行存保持同步。

有了 TiFlash，TiDB 4.0 在大量的複雜計算場景下，至少可以比上一個版本快 10 倍，而且咱們永遠不須要去操心「一致性」的問題。無論，面臨的是簡單的 OLTP 類型的 Workload，仍是複雜的 OLAP 類型的 Workload，它老是一致的、實時的，而且可以自動彈性擴張或伸縮。

上面的架構圖你們應該很是熟悉，幾乎每一家擁有必定數據規模的公司都經歷過。曾經有一個用戶，他們在一個大概只有幾十 T 數據規模的場景下，搭建了相似上圖那樣複雜的系統，就是爲了可以作 OLTP 和一個報表查詢。這中間不得不接入 Kafka 和 ETL，而後將這個報表查詢的結果又從新序列化到 HBase 之類的存儲系統裏面。有沒有辦法去簡化整個系統呢？

當咱們用 TiDB 4.0 的視角去看的時候，用戶已經給出了他們上線的答案。如上圖所示，當咱們把 TiDB 放在中間這一層，整個系統的複雜度就下降了很是多。接下來也會有用戶分享他們使用 TiFlash 的經驗，以及他們在架構上面作了哪些簡化。

說回來，站在基礎架構這一層，用戶其實並不想知道這個 Workload 究竟是長查詢仍是短查詢，站在用戶的角度，只是但願儘快獲得結果，儘量減小過程的複雜度以節省成本、提升開發速度，創造更多價值。

Cloud-Native

我知道你們都很是期待 PingCAP 可以提供 TiDB 的雲服務，如今我很高興發佈 TiDB Cloud，由 PingCAP 來管理，維護，優化的 TiDB 雲。

咱們從四年前就開始作了這個準備，今天 TiDB 能夠無縫地在「雲端跳舞」。

若是有人說：「我不想安裝 TiDB，我不想去維護 TiDB」。那這個事，你也能夠選擇交給 PingCAP 來作。目前咱們已經支持了 AWS、GCP 兩個雲平臺（其它雲平臺的支持也在穩步推動），若是你正在使用這兩個平臺，那麼你什麼都不須要作，點幾下鼠標就能夠輕鬆使用 TiDB，真正的「開箱即用」。

在 TiDB 4.0 中咱們提供了超過 70 個新特性，能夠閱讀這篇文章《TiDB 4.0：The Leading Real-Time HTAP Database is Ready for Cloud》。

Dashboard

在 TiDB 4.0 裏面內置了 Dashboard，很是適合像我這種好久沒有寫 SQL 的人，經過圖形界面解決大多數問題，觀察整個系統裏的熱點數據、慢查詢，業務在數據庫上具體是什麼樣子，經過多種不一樣的視圖去理解業務負載等等。咱們但願在 10 秒鐘內就幫用戶定位大部分故障和問題，下面的 Dashboard 知足了個人全部「幻想」。

性能：Faster and faster

性能是一個永遠都會「使人興奮」的問題。對比 3.0 版本，TiDB 4.0 總體的性能提高了 50% 左右；若是是跑聚合查詢，在不少場景下能作到提高 10 倍，甚至是更高，TPC-H 的性能也提高了一倍。這個成果也來自於整個 TiDB 開源社區的貢獻，去年年末咱們舉辦了 TiDB 挑戰賽 第一季「性能挑戰賽」，總共有 165 位社區開發者參賽，包括 23 支參賽隊伍和 122 位我的參賽者，他們的參賽成果都落地到了 TiDB 產品當中。

TiUP 一鍵安裝部署

以前有同窗吐槽說，我安裝 TiDB 太麻煩了，花了幾十分鐘甚至一天，才把整個系統部署起來。

在 TiDB 4.0 中，咱們專門寫了一個工具，叫 TiUP，它是一個包管理器。經過 TiUP，你們能夠在一分鐘內本地把 TiDB 跑起來，一分鐘就可以體驗 TiDB。而部署 15 個節點的生產集羣也只須要 45 秒，也就是徹底作到 1 分鐘內快速體驗。TiUP 是一個巨大的易用性體驗的提高，歡迎你們去體驗。

TiUP: A component manager for the TiDB eco-system

Try TiDB (playground) within 1 minute with 1 command

$ curl https://tiup-mirrors.pingcap.... | sh && tiup playground nightly --monitor

Deploy a production cluster in 45 seconds

TiUP 對用戶來講是一個巨大的易用性體驗的提高，歡迎你們去體驗。

Security matters!

隨着 TiDB 在全球的應用規模愈來愈大，愈來愈多的用戶在更加嚴肅的場景裏使用 TiDB，所以咱們也提供了你們很是關注的安全特性，來符合各個國家對安全和隱私的合規要求。目前全部 TiDB 通信組件的通信過程都是所有加密的，全部存儲的數據都支持透明加密，包括 PingCAP 或者任何一家雲廠商，都不能侵犯到 TiDB 用戶的數據隱私與安全。當 TiDB 跑在這個雲上時，沒有人可以看到數據庫，沒有人可以從中截獲到通信過程的數據。

實戰效果如何？

相信有人會有疑問，講了這麼多，TiDB 4.0 是否真的準備好了？能不能上生產環境？有沒有實戰數據分享？

上圖知乎的已讀服務，前幾天知乎剛升級到 TiDB 4.0 的最大的一個內部集羣。整個集羣容量有 1 PB，目前的存儲數據量已經達到了 471TB。

我第一次看到這個數據的時候仍是很是震驚的，不只僅是由於數據規模，還震驚和感動於孫曉光老師（知乎，TiKV Maintainer）對 4.0 的信心，他們在 5 月 28 日 4.0 GA 版本正式發佈的第4天，就已升級。固然，看到這個結果，個人信心也更強了，TiDB 不只僅支撐這麼大數據規模，更重要的是讓知乎已讀服務的整個系統計算能力有了很大的提高，極大改善了整個系統的延遲。

從上圖能夠看到，TiDB 4.0 與上一個版本相比，下降了 40% 的延遲，換句話說，若是在維持相同的延遲的狀況下，大約可以下降 40% 的成本。

Why is TiDB so Popular ?

過去的一年，我也會常常被問到一個問題，爲何 TiDB 如此的流行？爲何 TiDB 可以走遍全世界？爲何可以獲得這麼多用戶的使用和讚揚（固然也有吐槽，用戶的吐槽也讓咱們很積極、頗有動力去改進，去快速迭代）？

其實這一切不只僅是 PingCAP 的功勞，而是整個開源社區的功勞，PingCAP 只是 Community 的一部分。正是由於有全球各地的開發者參與貢獻，好比美國的 Square、Azure、Zoom、法國的 Dailymotion、日本的 PayPay 等等，給咱們提意見、提需求，提 PR 貢獻代碼，一塊兒打磨、一塊兒成就了今天的 TiDB ，組成了如今龐大的 TiDB 開源社區。

在 4.0 發佈的時候，咱們也作了一個詞雲，看了看 TiDB 代碼貢獻者所屬的組織，而且按照組織的貢獻程度，畫了一張圖出來，咱們才發現原來有這麼多的組織，在 TiDB Community 中持續貢獻：

同時，常常會讓我感到驚喜的是社區的創造性。好比 TiDB Contributor 劉東坡把貢獻排名前 100 的 Contributor 作了可視化的展現：

<div class="caption-center">https://rustin-liu.github.io/...</div>

這位小夥伴也在本屆 TiDB DevCon 的開發者社區專題論壇中分享了參與社區的心路歷程，咱們也但願更多人可以像這位小夥伴同樣，在 TiDB 社區中有所收穫，更在貢獻中感覺到樂趣&歸屬感。

另外，無論你是誰，只要你想參與 TiDB 的打造或者想使用 TiDB，咱們都爲你準備好了：

• 若是你在用 TiDB 過程當中，遇到任何問題，你均可以去 AskTUG（https://asktug.com）提問，有超過 2700 個會員，他們都在 AskTUG 中分享實戰經驗或者踩過的坑，或許你遇到的問題，在這裏搜索一下就能獲得解答。
• 若是你還想進一步再深刻的學習 TiDB，咱們也推出了 PingCAP University（https://university.pingcap.com）線上及線下的培訓課程。最後你們也能夠驗證一下本身的學習效果，也能夠去參加認證考試（以下圖所示）。

在過去的幾個月裏，TiDB 社區夥伴們也作了一些比較瘋狂的事情。好比，咱們花了 48 小時寫了一本書《TiDB 4.0 in Action》（閱讀地址：book.tidb.io）。或許乍一聽以爲很神奇，48 小時怎麼可能能寫一本書呢？但你們去看一下做者的數量就能理解了，這本書有 100 多位做者，每一個人寫一小節，就是 100 小節，48 小時輕鬆搞定。固然這個事情也不是輕鬆促成的，它的實現實際上是整個社區長時間的知識&精神力量的積累。

若是看到這裏，你雄心勃勃，還想再精進一步，想寫一個屬於本身的分佈式數據庫。沒問題，咱們還準備了 Talent Plan 課程，能夠根據課程規劃一步步 build 一個分佈式數據庫的計算層、存儲層，這門課程還會有來自全球各地的導師幫你 Review 代碼和做業，目前暫時支持中文和英文。

Bonus: Chaos Mesh™!

最後聊一聊咱們在混沌工程方面的實踐，在軟件領域有一個常識是，「現實中全部能夠預見的故障，最後都必然會發生」，系統的複雜性是沒法逃避的、必需要面對的，也是咱們必需要去解決的。在今天，整個系統的複雜性已經不只僅侷限於數據庫了，而是延展到了整個業務的全鏈路，最終落腳在系統爲用戶提供的服務質量。

如上圖所示，Amazon 和 Netflix 兩家公司的微服務可視化以後的樣子，不能簡單用蜘蛛網來比喻，它實際上比蜘蛛網還要複雜得多。因此咱們須要一套系統，去模擬現實中全部可能發生的故障，而且讓這個故障不斷的發生，未雨綢繆地加強系統的魯棒性。

所以，咱們在開發 TiDB 的整個過程當中，構建了一套系統 Chaos Mesh。它會作什麼？

好比，它能夠模擬磁盤壞掉。在咱們的測試環境中，磁盤每分鐘壞一次，網絡每分鐘都會產生隔離。儘管這種狀況在現實世界中極少出現，可是一旦出現就會造成災難性的故障。而模擬磁盤壞掉只是 Chaos Mesh 能夠提供的衆多功能之一。

Chaos Mesh 將幫助你們在業務的全鏈路上，作完整的、全部可能出現的故障測試。以往你們憑經驗所說的 「有 99.99% 或者有 99.999% 的概率系統可以正常運行」，都包含了一些「運氣」成分在其中。由於，咱們用 Chaos Mesh 去測試了各類故障狀況，會發現某個系統要作到「99.99% 或者 99.999% 正常運行」是很是很是少見的、極其困難的一件事。在 TiDB 的開發過程當中，咱們同步使用了 Chaos Mesh 來測試 TiDB，TiDB 4.0 在測試用戶中的反饋很是好，一部分也要歸功於 Chaos Mesh 「瘋狂摧殘式」的測試。固然咱們也很是歡迎你們使用 Chaos Mesh 測試和打磨本身的系統。

結語

實際上，TiDB 發展到今天，已經不只僅是一個數據庫產品，它已是不少系統的基石，做爲一個基礎設施的存在。你們在使用以前，也能夠參考其餘人的成熟經驗或者解決方案，TiDB DevCon 2020 上有 80+ TiDB 用戶&合做夥伴分享一手實踐經驗，無論你來自哪一個行業，好比金融、電商、物流、新零售、出行、電信、醫療、能源、製造業、高科技、教育、視頻、資訊；仍是應用在不一樣的使用場景，好比實時分析、數據匯聚、Data Mart，元數據存儲、日誌審計、日誌統計分析，還有 IM 等等。全部你想看了解的行業參考，你想了解的場景實踐，咱們已經準備好了。後續 TiDB DevCon 2020 部分視頻&文字回顧將陸續整理輸出，敬請期待。

感謝社區夥伴們的熱情參與和支持，將來咱們繼續攜手同行，走向開源世界的星辰大海！關注 PingCAP 微信公衆號(pingcap2015)，在後臺回覆「 DevCon2020」獲取部分通過講師受權後整理的 PPT 資料。

TiDB DevCon 是 PingCAP 團隊面向 TiDB 社區推出的技術會議，每一年在北京舉辦。本屆 DevCon 在 6 月 6 ～ 7 日舉辦，以線上直播的方式，爲你們展現 TiDB 近一年的產品技術蛻變，分享最新的海內外生態進展，並邀請了來自全球的 80+ 位開發者、用戶及合做夥伴，分享他們的實戰經驗和開源思考，覆蓋金融、製造業、電信、電商、物流、能源、快消、新零售、雲計算等多個領域。

本文內容以 PingCAP 官網博客欄爲準，歡迎點擊【這裏】查看原文。

若對 TiDB 的使用有所疑問，也能夠登陸 Asktug.com 搜索或發帖交流～