數據庫領域正在發生鉅變，從 TiDB 5.0 發佈會看將來的數據庫發展趨勢

前不久，PingCAP 剛剛度過六歲生日。對於數據庫這樣一個古老的行業，六年只是剛剛起步。TiDB 5.0 的發佈就像一個慶祝成長的生日禮物，爲 TiDB 帶來了一個具備里程碑意義的版本。經過引入 MPP （Massively Parallel Processing，大規模並行處理）架構，年輕的 TiDB 已經成爲一款具有完整 HTAP 能力的分佈式數據庫。

PingCAP 聯合創始人兼 CTO 黃東旭在 TiDB 5.0 發佈會上進行了《What’s Next? 新一代數據庫的構想》的精彩演講，講述了 TiDB 做爲一款企業級數據庫的成長史，並分享 PingCAP 對於企業級數據庫的思考與內外功修煉。

一個企業級數據庫的辛酸成長史

TiDB 從誕生的第一天起，就被設定了一個很高的目標——成爲一款面向核心系統的企業級數據庫。也由於這個很高的目標，其發展歷程充滿着辛酸的故事。

5 年前，當帶着 TiDB 第一個版本見客戶時，尚未人用過 TiDB ，而客戶的問題就是「有誰在用你的產品？」 很顯然這段對話的結果就是被拒絕。畢竟做爲一款企業級數據庫，替換數據庫的動做就像動心臟手術同樣，客戶一般都很是謹慎。

TiDB 的第一次用戶嘗試就成爲「救命」的產品

TiDB 的第一個用戶是一家遊戲公司，當時的數據庫不能知足其廣告投放系統的實時查詢，因而就抱着死馬當活馬醫的心態開始試用，結果 TiDB 成爲救活這個公司的產品。說來也巧，這個廣告系統剛好是一個 HTAP 場景，彷佛也預示了 TiDB 的救命能力與實時性數據處理密不可分。

一個小目標：開拓金融行業客戶

以後的幾年中，隨着在 Mobike 、今日頭條等互聯網創業企業中應用，TiDB 逐步成爲互聯網行業在分佈式數據庫領域的事實標準，也有了一些知名度。但熟悉的對話再次發生，客戶在與 PingCAP 交流中問 「大家如今有沒有金融行業的案例？」，當時 TiDB 還正處於 1.0 - 2.0 階段，並無金融行業案例，客戶認爲這還不算真正的企業級數據庫。

到了 3.0 、4.0 版本時， TiDB 逐漸有了一些核心的金融行業客戶，具有了金融客戶使用案例。但客戶又問 「大家有大行核心系統的應用案例嗎？」 「沒有」 「那很差意思，告辭！」

這段歷史很辛酸，每一個人都有第一次，一個新產品也總得有第一個客戶。但數據庫這種東西全部人都說必須得別人用過，本身才敢用。這就是作企業級數據庫的現狀，由於這個東西實在太過於重要，沒有人願意當小白鼠。

從「救命」 到「省心放心」 企業級數據庫的成熟之路

TiDB 跨過最危險的開源鴻溝

TiDB 與不少數據庫相比，很特別的一點在於它是一個開源軟件。在業界，開源軟件有一個跨越鴻溝的理論，它描繪了一個新技術的發展階段：一開始你們的預期都很高，逐漸有一些早期的用戶，市場也在不斷髮出聲音。持續一段時間後會經歷一個高峯期，高峯事後就會進入一個很長時間沒有增加的階段。不少開源項目死於這個死亡之谷，那是一段很是焦慮很是煎熬的時期。

上圖中，藍線表明 Kubernetes —— 目前全世界最流行的開源軟件，從圖中能明顯看到它也經歷過這樣一個曲線。另一條綠線表明了 TiDB ，做爲一個歷經六年的開源項目，也沒有逃出這個客觀規律。在中間長達兩年的時間裏幾乎沒有增加，這段時間對於一個開源數據庫是最難熬的日子。從 4.0 版本發佈至今，TiDB 終於跨過了這個最危險的開源鴻溝。根據開源的歷史規律，TiDB 與 PingCAP 將會迎來一段高速的增加，如今已是一個「死不了」的產品。在基礎軟件行業，一個死不了的開源軟件已經很不容易了。

這個規律的背後說明了什麼？一個真正好用的基礎軟件，一款真正好用的企業級數據庫，並非幾個天才工程師寫出來的，而是被人「用」出來的。中間那段長達兩年的，其實並非沒有增加，它只是在不停地進化，不斷地在各類各樣的場景中打磨產品。

回到 「什麼是企業級數據庫」 這個問題。有不少用戶是經過數據庫的用戶案例來判斷是否企業級，有的認爲貴的軟件收費就是企業級，也有不少人甚至以爲開源就不是企業級，每一個人心中都有着不一樣的答案。

作「省心，放心，不擔憂」的企業級數據庫

PingCAP 認爲，一個真正的企業級數據庫廠商應該把本身放在用戶的角度去思考，不管是一個企業去購買數據庫應對數字化挑戰，仍是一個工程師去面對數百臺的數據庫集羣維護，他們須要的就是「省心、放心、不擔憂「。

第一，省心。省心其實主要是易用性問題，不少時候，人們認爲易用性是一個有關用戶體驗的事情。這裏有一個特別簡單的標準，若是它帶來的問題要小於它解決的問題，這就是易用。若是你發現用一個新東西的時間和精力比它解決問題所花費的時間還多，那就是不省心。

第二，放心。數據不會錯、不會丟、性能無抖動是對於一個數據庫最基礎的要求。其實在使用數據庫的過程裏，並不在於它有多少功能、多高性能，而是萬一出現問題，有沒有人提供背後的企業級服務。一個 DBA 工做中可能有 50-60% 的時間在部署、安裝、備份、維護數據庫，若是這個數據庫他不會運維，不知道怎麼調優，就沒法讓人放心。PingCAP 背後有一支專業的服務團隊，比起其餘沒有生態的數據庫軟件更能讓人放心，維護不愁人。

第三，不擔憂。用戶到底在擔憂什麼？是業務的增加嗎？是數據量變大嗎？是擔憂這家數據庫公司倒閉嗎？其實在數據庫領域裏，從用戶的視角來看，真正的敵人是系統的複雜性，這個系統越複雜，在應對業務高速增加、快速變化時，應對的動做就會越遲緩。這個複雜性是各類各樣的技術架構、各類各樣的軟件組合在一塊兒，產生了不少的數據對接，以及維護各類各樣的技術棧。

關於不擔憂，在 TiDB 裏有一個真實的故事：

https://v.qq.com/x/page/k3242wd985n.html

在傳統的數據處理與大數據方案中，引入了各類各樣的複雜性，用戶的在線系統和離線大數據系統是徹底割裂的兩個系統。使用 TiDB 後，大多數場景用一套系統就能夠支撐。對於用戶來講，一個簡潔優雅的技術架構就是不用擔憂的方案。

里程碑！TiDB 5.0 核心能力向企業級演進

TiDB 5.0 的內功：TiDB，棧穩了！

若是要給 TiDB 5.0 定義一個關鍵字的話，那就是「練內功」。如今整個行業對於 TiDB 的認知和需求已經進入一個深水區，過去你們認爲這是一個創新型產品，會在一些創新型的業務上用。但從 4.0 開始至今，愈來愈多的金融機構或大型企業，開始把 TiDB 用在一些很是關鍵、很是核心的交易、支付場景裏。不少人表面上看 5.0 彷佛並無發佈特別多新功能，其實在 5.0 這個版本能看到的顯性功能只是冰山一角，冰山下面更多看不見的是 TiDB 產研團隊、用戶和貢獻者對穩定性以及性能的持續優化，這些「內功」也是一個真正的企業級數據庫應該追求的能力。

從 4.0 版本到 5.0 版，TiDB 作了大量優化，包括減小性能抖動、提高性能、提高安全性等，上圖中能看到這條黃色曲線最終變成了紅色曲線，減小抖動將近 100 項。對於一個企業級數據庫來講，內功實際上是很是重要的一個壁壘。

真 HTAP 來了！TiDB 5.0 補全 HTAP 能力拼圖

回顧整個 TiDB 歷史，你能夠看到 HTAP 是如何一步步變成今天這個形態的。TiDB 剛誕生的時候，出發點很是樸素，就是想作一個 MySQL 分庫分表的替代品，比 MySQL 分庫分表用起來更方便，解決 OLTP 規模化的問題。

4.0 版本已經實現初步的 HTAP 能力，第一次引入了 HTAP 的重要插件 —— 列式存儲 TiFlash 引擎。列存引擎在底層爲 TiDB 打下一個基礎，與 OLAP 數據庫相比再也不有天生的缺陷。

TiDB 5.0 最新版在 TiFlash 的基礎上引入了 MPP 架構，在功能上補全了 HTAP 最後一塊拼圖。提供與存儲匹配的分佈式計算引擎，進一步提高海量數據下的並行計算與分析能力。這對於 TiDB 來講是一個里程碑，標誌着 TiDB 成爲一個擁有完整能力的 HTAP 分佈式數據庫。但里程碑並不表明終點，對於一個企業級數據庫來講，TiDB 還有很長的路要走。前路漫漫，但願你們多多包容，多多呵護 TiDB 繼續成長壯大。

拋掉過去，從新出發——數據庫將來趨勢

若是從數據庫的發展歷史角度來看，上世紀六七十年代，IBM、Oracle 發明了關係型數據庫。2010 年先後，互聯網普及了 Shared Nothing 架構，分佈式數據庫慢慢走向主流。如今基本一個成規模的互聯網公司或者數據量大一點的公司，大多都在用 Shared Nothing 的數據庫支撐。但從架構來講，咱們也許須要新的思路來解決將來的問題。2021 年咱們又站在了一個新十年時間窗口的開始，直覺告訴咱們，接下來即將進入一個數據庫技術的全新時代。這個時代須要拋棄掉過去全部對於數據庫的假設，去面向這個時代的基礎設施從新設計。

首先，規模效應會從新掌握一切。早年間有一個預言說將來這個世界上只須要五臺計算機，如今來看應該不是五臺計算機，而是五朵雲。雲的基礎設施也許會變成新的基礎設施，將來的年輕一代工程師或許都不知道什麼是 CPU、內存、磁盤，他們看到的基礎設施就是雲廠商提供的 API 或服務接口。從 Snowflake 的實踐來看，新一代的基礎軟件只有基於雲底層能力深度重構才能真正獲取彈性的能力。Snowflake 是第一個，可是確定不會是最後一個。

將來可期，PingCAP 已經準備好從新出發！