前不久，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 已經準備好重新出發！