劉奇:當今一切都要更實時、更彈性、更簡單,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 萬,錯過的小夥伴們可以繼續“蹲守”本公衆號近期推送,我們將陸續挑選整理部分精彩內容輸出,敬請期待!

0-live

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

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

1-list

Serverless

很長一段時間 TiDB 用戶使用的集羣規模都很大,然後就會再提出一個訴求說“怎麼降低我的使用成本”。TiDB 4.0 擁有了 Serverless 能力之後,會根據用戶的實際業務負載,基於 K8s 自動做彈性伸縮。

2-cost-effective

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

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

3-workload

另外,能夠彈性伸縮的 TiDB 可以應對無法預測的 Workload,沒有人知道哪一個商品在什麼時候會大賣,沒有人知道我賣的哪一個基金在什麼時候會火,這時如果我們給系統一個權限,讓它能夠自動根據業務當前的實際情況,擴充服務器,這對某個企業或者某個業務來說,可能是“救命之道”,比如像上圖的情況,人爲介入往往是太慢了,來不及了。

Real-Time HTAP

在當今這個世界,大家希望所有的東西都要更快、更簡單。但如果大家還是按照傳統的方式去運用一個數據庫,就不能滿足這個“更快、更簡單”的需求了,因爲傳統的方式需要經過一系列非常複雜的過程從數據庫裏面去提取這些變化的信息、事件、日誌,再去做分析,那這個過程往往會帶來比較長的延遲,這些「延遲」讓我們失去了很多直接的經濟價值。

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

有了 TiFlash,TiDB 4.0 在大量的複雜計算場景下,至少能夠比上一個版本快 10 倍,並且我們永遠不需要去操心“一致性”的問題。不管,面臨的是簡單的 OLTP 類型的 Workload,還是複雜的 OLAP 類型的 Workload,它總是一致的、實時的,並且能夠自動彈性擴張或伸縮。

4-架構圖

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

5-real-time-htap-architecture

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

6-節省成本

說回來,站在基礎架構這一層,用戶其實並不想知道這個 Workload 到底是長查詢還是短查詢,站在用戶的角度,只是希望儘快得到結果,儘可能減少過程的複雜度以節省成本、提高開發速度,創造更多價值。

Cloud-Native

我知道大家都非常期待 PingCAP 能夠提供 TiDB 的雲服務,現在我很高興發佈 TiDB Cloud,由 PingCAP 來管理,維護,優化的 TiDB 雲。

我們從四年前就開始做了這個準備,今天 TiDB 可以無縫地在“雲端跳舞”。

7-cloud-native

如果有人說:“我不想安裝 TiDB,我不想去維護 TiDB”。那這個事,你也可以選擇交給 PingCAP 來做。目前我們已經支持了 AWS、GCP 兩個雲平臺(其它雲平臺的支持也在穩步推進),如果你正在使用這兩個平臺,那麼你什麼都不需要做,點幾下鼠標就可以輕鬆使用 TiDB,真正的「開箱即用」。

8-out-of-the-box

在 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 滿足了我的所有“幻想”。

9-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.com/install.sh | sh && tiup playground nightly --monitor

Deploy a production cluster in 45 seconds

TiUP 對用戶來說是一個巨大的易用性體驗的提升,歡迎大家去體驗。

Security matters!

10-security-matters

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

實戰效果如何?

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

11-zhihu

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

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

12-deeper

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

Why is TiDB so Popular ?

過去的一年,我也會經常被問到一個問題,爲什麼 TiDB 如此的流行?爲什麼 TiDB 能夠走遍全世界?爲什麼能夠得到這麼多用戶的使用和讚賞(當然也有吐槽,用戶的吐槽也讓我們很積極、很有動力去改進,去快速迭代)?

13-star-history

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

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

14-contributor-cloud

同時,經常會讓我感到驚喜的是社區的創造性。比如 TiDB Contributor 劉東坡把貢獻排名前 100 的 Contributor 做了可視化的展示:

15-contributor-gif

https://rustin-liu.github.io/Ti2020/

這位小夥伴也在本屆 TiDB DevCon 的開發者社區專題論壇中分享了參與社區的心路歷程,我們也希望更多人能夠像這位小夥伴一樣,在 TiDB 社區中有所收穫,更在貢獻中感受到樂趣&歸屬感。

另外,不管你是誰,只要你想參與 TiDB 的打造或者想使用 TiDB,我們都爲你準備好了:

  • 如果你在用 TiDB 過程中,遇到任何問題,你都可以去 AskTUG(https://asktug.com)提問,有超過 2700 個會員,他們都在 AskTUG 中分享實戰經驗或者踩過的坑,或許你遇到的問題,在這裏搜索一下就能得到解答。

  • 如果你還想進一步再深入的學習 TiDB,我們也推出了 PingCAP University(https://university.pingcap.com)線上及線下的培訓課程。最後大家也可以驗證一下自己的學習效果,也可以去參加認證考試(如下圖所示)。

16-pu

在過去的幾個月裏,TiDB 社區夥伴們也做了一些比較瘋狂的事情。比如,我們花了 48 小時寫了一本書《TiDB 4.0 in Action》(閱讀地址:book.tidb.io)。或許乍一聽覺得很神奇,48 小時怎麼可能能寫一本書呢?但大家去看一下作者的數量就能理解了,這本書有 100 多位作者,每個人寫一小節,就是 100 小節,48 小時輕鬆搞定。當然這個事情也不是輕鬆促成的,它的實現其實是整個社區長時間的知識&精神力量的積累。

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

Bonus: Chaos Mesh™!

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

17-complexcity

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

因此,我們在開發 TiDB 的整個過程中,構建了一套系統 Chaos Mesh。它會做什麼?

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

18-chaos-engineering

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 搜索或發帖交流~

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章