TiDB 的如今和將來

本文根據黃東旭在 PingCAP D 輪融資線上發佈會的演講實錄進行整理。

TiDB 的如今和將來

你們好，我是黃東旭，是 PingCAP 的聯合創始人和 CTO，這是 PingCAP 成立以來的第一次發佈會，我想跟你們簡單聊聊 TiDB 在產品和技術上的更新。考慮到線上的不少觀衆不必定是有很強的技術背景，我將盡我所能將技術的部分說得讓你們都可以理解。

在講正題以前有一個小故事，咱們作基礎軟件的產品經理去跟客戶聊需求的時候，客戶常常都會說：對於數據庫，個人要求特別簡單、特別基礎、很是樸素，我不要求不少功能，安全穩定是必須的，最好能高可用，性能必定要好，若是數據量大了，能實現彈性伸縮就更好了；另外，最好別讓我學太多新東西，用起來跟過去使用的產品差很少，這就是一款完美的數據庫產品。

就像你們在家裏用自來水同樣，咱們對自來水的需求就是擰開水龍頭水就能出來，可是背後自來水廠是怎麼處理的你們不用知道，咱們只須要根據實際狀況使用冷水或者熱水就好。可是從技術的角度來講，剛纔相似冷熱水這個很是樸素的基礎需求，類比一下放到數據庫的世界這就是一個圖靈獎級別的基礎需求，稍微解釋一下圖靈獎是計算機行業學術界最頂級的，至關於計算機界的諾貝爾獎。

這裏有兩位行業泰斗級的人物，左邊 Leslie Lamport 在 2013 年研究相關問題拿了圖靈獎，右邊這位跟咱們挺有緣的，髮型跟（咱們的 CEO）劉奇同窗挺像，他是 UC 伯克利分校的一名教授，也是著名 CAP 定理的提出者，PingCAP 中的 CAP 就是來源於此。雖然看上去這個需求是一個很樸素的需求，可是這是一個值得去花很長時間研究，在技術領域頗有挑戰，也是一個很前沿的研究領域。

在聊數據庫以前，我想帶你們回顧一下十年前的電子產品，回顧一下咱們當年的生活，你們回想一下十年前咱們手上的數碼產品有哪些，好比咱們打電話有諾基亞，拍照有數碼相機，也有用來作導航的獨立設備 GPS，聽歌用的 MP3 等等，種類繁多。

咱們再來回顧一下這十年，這些東西好像在咱們的生活中漸漸消失掉了，一臺智能手機把不少這些碎片化的東西統一了起來，我以爲這背後一個很重要的點就是咱們對於統一用戶體驗的追求驅動了整個科技界產品發生翻天覆地的變革，如今一臺智能手機基本解決了咱們生活中百分之七八十的數字化生活場景的需求。

TiDB 是一個 HTAP 系統

接下來進入正題，PingCAP 是作數據庫的廠商，若是咱們拉一條數軸來看，左邊的業務是更偏實時在線的業務，若是這條數軸的右邊是離線業務的話，按照這個數軸來看，數據庫這個產品你們可能印象中是在左邊的，一些典型場景，好比像 Hadoop 或者一些數據倉庫、報表是在右邊。

再看一個具體的業務場景，假設是一個公司要打造電商平臺的 IT 系統，梳理一下如今電商平臺內部有各類各樣的應用和場景，咱們按照這些場景放到這個數軸上，左邊是在線，右邊是離線，咱們看到好比交易、訂單管理、明細查詢，這多是偏在線的業務，用戶用手機隨時能夠打開看；右邊離線業務更像是內部運營人員，好比老闆查看去年賺了多少錢，這種報表多是一個更偏離線的業務。

你們有沒有發現中間有一些實時的報表，實時的促銷調價，熱銷產品的推薦，你放在左邊不合適，放在右邊好像也不太對，因此中間部分是一個比較模糊的狀態，這是一個業務的語言，好比咱們把這個業務放到這條軸上去看，好比說我是電商平臺的技術人員，業務人員告訴我，咱們上面這些需求，這些需求翻譯成技術的語言會變成什麼樣子呢？

就變成了各類各樣的 OLTP 數據庫和 OLAP 數據庫和數據倉庫，好比像 ClickHouse、Greenplum，像離線的數據倉庫 Hadoop、HIVE，有不少同窗不瞭解這些名詞不要緊，我只是想展示一下，業務需求翻譯成技術語言，一般須要一系列複雜的數據技術棧來支撐。

可能有不少觀衆學過計算機技術，我記得我在上大學的時候，咱們有一門課是叫數據庫系統，老師上課的時候教我數據庫就是增刪改查，就是存數據、取數據的一個系統、一個軟件，幾個關鍵的命令 INSERT\SELECT\UPDATE\DELETE，我回憶了一下好象也沒有教哪些場景是 OLTP 的場景，哪些是 OLAP 的系統，並無這麼複雜。

數據庫應該就是存數據、取數據天經地義，就像水龍頭同樣一擰開就出水，我還特意查了一下 database 的定義，在維基百科上面的定義其實並無說 OLTP 的 database 或者 OLAP 的 database。

我知道這多是一個細分的領域，可是從數據庫這個詞的本源來看，本質上像一個容器同樣，存儲數據和取數據的一個系統，好像也沒什麼複雜。

爲何今天不少工程師，不少用戶就以爲這個數據庫或者這個場景必定是個 OLTP，或者是個 OLAP ，要有一個涇渭分明的分類。就像剛纔電商的例子，其實有大量中間的場景很難說究竟是一個 OLTP 仍是 OLAP 。可是如今的現實是對於不少 IT 系統、業務系統來講，對於實時性的要求愈來愈高，爲了解決這個問題，咱們構建了各類各樣的數據孤島，構建了各類各樣的煙囪式系統。

因此過去這種涇渭分明式的分類方式到底適不適用如今有愈來愈多實時性要求的時代呢？

回過頭來思考這個分類是否是有問題的時候，做爲一個理工男或者做爲一個學理科出身的工程師，咱們特別喜歡尋找一個定義或者尋找一個分類。咱們找遍了各類各樣的定義，從學術界、工業界、到各種諮詢機構，發現 HTAP 是一個更加符合或者說更加適合如今 TiDB 應用場景的一個定義。

TiDB 的定位是一個 Real-Time 的 HTAP 系統，有不少朋友後來問我，TiDB 是一個 HTAP 系統，是否是就意味着你不是一個 OLTP 系統，或者說你究竟是一個 OLTP 仍是 OLAP ？

咱們回到智能手機的那個例子，首先智能手機必定是一個 100% 的手機，確定能打電話，在打電話的基礎上再加上不少其餘的經常使用功能，好比相機、GPS、MP3等在一個系統裏面搞定。我想強調的是 TiDB 的定位就是 Real-Time HTAP 系統，首先是一個 100% 的 OLTP 系統，同時還能支持一些 Real-Time OLAP Query。

講到 TiDB，我其實很感慨，我一直看着這個產品一步步成長起來，最近這一年成長速度尤爲快，如今我很高興地看到 TiDB 4.0 已經成爲社區的一個主流版本。

在 4.0 發佈的時候，我當時很熱情洋溢的發表了一段話，說這是一個很是具備里程碑意義的一個版本，事實上 TiDB 4.0 的表現我以爲是不負衆望的，如今你們都很是喜歡，成爲了主流。

展望 TiDB 5.0

我想跟你們展望一下 TiDB 5.0，在講 5.0 以前我想稍微強調一下 TiDB 作產品的思路。咱們都是工程師出身，也比較接地氣，不說什麼高大上的，用大白話來講就四點：穩、快、好用和用着放心。前面提到過用戶對於一個數據庫產品的樸素需求，咱們也是但願按照這種方式來作產品。

但在 TiDB 5.0 裏面咱們真正把一個具體的目標放到了產品規劃的方向裏面，那就是 TiDB 要走向各行各業的核心場景。以前，TiDB 從 2.0 到 3.0 和 4.0，已經開始慢慢地走向了各行各業，慢慢地滲透到一些對穩定性、對性能要求很是極致的場景，包括金融、銀行的一些核心業務系統。

在 TiDB 5.0 這個版本，咱們第一次明確地提出，至少在產品層面上要達到各行業核心場景對於數據庫性能和穩定性的要求。

接下來具體談談 TiDB 5.0 在這幾個方面的進展。

首先第一點穩定性，我常常說一句話：把一個東西作對實際上是很難的，把一個數據庫作出來不難，作對卻很難，因此咱們構建了各類各樣的正確性的測試系統。如今 TiDB 已經作出來了，下一個階段是更穩，可是要使得 TiDB 更加穩定還有不少的工做要作，這方面沒有捷徑，道理誰都懂，魔鬼在細節，只有作得愈來愈深，愈來愈細，我很高興的看到，在 TiDB 5.0 中咱們和用戶一塊兒把 TiDB 的穩定性又往前推動了一個級別。

下圖是 5.0 在某個券商機構的測試結果，在 48 小時高壓力的測試場景裏面 TiDB 5.0 的系統抖動一直小於 5%，同時在性能上跟 4.0 相比有明顯的提高。我想強調的是在作穩定性這件事情上，已經開始進入改革深水區，低垂的果實已經摘的差很少了，剩下就是一些場景和技術上比較硬的難題等着咱們去攻克，咱們很高興地看到 5.0 對於 4.0 在穩定性上有比較出色的表現。

第二，性能快。天下武功，惟快不破，尤爲是對於數據庫這樣的基礎軟件來講，特別是在一些核心應用場景，好比像銀行的一些核心交易系統，一個毫秒的額外延遲可能就會對總體的系統和用戶體驗形成影響。

在 TiDB 5.0 裏面咱們很高興地看到，對比 4.0 延遲幾乎成倍地降低。這讓我想到跟開發團隊常常開的玩笑，說 TiDB 每一個版本有點像摩爾定律，每個版本比上一個版本性能提高一倍、延遲降低一倍、成本不變，將來成本還會持續降低。我很高興看到 5.0 仍是保持着這個規律，因此，性能快與延遲下降在 5.0 裏面會是一個很重要的標籤。

快的另一個方面，首先熟悉 TiFlash 的同窗看到標題確定會心一笑，咱們以前有提到 TiDB 是一個 Real-Time HTAP 架構，AP 這部分是由 TiFlash 分析加速引擎來提供服務的。在 5.0 裏面 TiFlash 將支持分佈式的聚合和分佈式的計算（MPP），能讓整個 TiDB 的 OLAP 能力真正延伸到更多的應用場景，應對更多更復雜的 JOIN 場景。

好用，這個方面我想強調的有兩點。

首先，你們看到跨數據中心、跨地域一個部署，不少作分佈式系統的同窗會以爲很興奮，TiDB 終於能夠支持作 Geo-Partition（多地多活跨地域數據分佈） 。我稍微解釋一下，TiDB 是一個分佈式數據庫，因此有不少用戶、不少開發者但願 TiDB 能夠實現真正的跨長距離或者跨多個數據中心的部署，能夠在全國或者全球都組成一個大的網絡。

其次，打通多個流行數據處理棧生態和提供全鏈路追蹤系統，也將使得 TiDB 5.0 變得更加好用。

提到 Geo-Partion，實際上，有不少客戶有這樣的場景需求，特別是對於一些海外客戶，好比一家歐洲公司的業務遍及全球，這時候若是有一個數據庫系統，可以支持全球跨長距離的區域部署，可以在不一樣的國家、不一樣的位置隨時提供服務，運維方面也省去了部署多套技術棧和數據庫系統的成本，這對於客戶來講就是一個理想之選。

舉個例子，咱們剛纔提到多地部署，怎麼下降本地的延遲，若是是一個歐洲公司，你們知道歐洲有很嚴格的 GDPR ，企業的數據不能出境，這種場景下 Geo-Partition 就是一個很是實用的特性。

若是是如今的 TiDB 去作這件事情，好比說在歐洲、中國、美國同時提供服務，在一些場景下的數據庫性能和延遲可能會不太理想，由於須要到一箇中央的服務器上去處理，去拿時間戳，而後才能提供服務。

在 TiDB 5.0 裏面，咱們將中央的授時服務改爲了一個分佈式授時的服務，可以讓這個系統在本地或者在多數據中心場景裏面的性能表現更佳。

第二個方面是 TiDB 的「朋友」愈來愈多，做爲一個基礎軟件，雖然 TiDB 的目標是儘量的把不少場景統一，但我以爲 TiDB 跟業界其餘生態技術棧的互聯互通也是一個很是重要的方面。

如今對於 TiDB 來講，已經可以與 Flink、Kafka、Spark，包括 Hadoop、AWS S3 以及 MySQL、Oracle 這些傳統的數據庫進行互聯互通。

舉一個具體用戶的例子，這是一個在線的實時數倉業務，線上的業務持續在作交易，在作寫入，同時這些數據經過 TiDB TiCDC 增量訂閱模塊輸出到 Kafka，同步到 Flink 流式計算引擎去作概括、聚合與分析，而後再從新寫回到 TiDB。寫入到 TiDB 的這些數據再去對在線業務進行補充，TiDB 結合 Kafka、Flink 組成了一個簡單易用的實時數倉架構。

說到安全，對於數據庫來講，安全實際上是很是重要的，在咱們的產品規劃裏面，安全是放在很高優先級的特性。

我想強調，在 4.0 裏面 TiKV 存儲層已經支持全鏈路的數據透明加密。在 DBaaS 平臺裏面，咱們正在引入 RBAC，就是基於用戶身份的鑑權系統，同時咱們會跟 AWS 的身份認證系統進行打通，給用戶提供更加安全、更加可靠的產品與服務保障。

在安全合規方面，隨着 TiDB 愈來愈多地應用在國內、國外一些關鍵的業務場景，不一樣的國家，不一樣的應用場景對於合規的要求呈現多樣化特色， TiDB 已經經過了 SOC2Type1 認證，這是在美國金融行業裏面很是承認的合規標準，將來咱們將在合規上面投入更多的精力。

將來的數據庫是什麼樣子？

前面是對於 TiDB 5.0 在如今這個時間點的進展同步。可是將來在哪裏？

咱們每個分享最後的部分會講講到底將來應該是什麼樣子的，我以爲在比較近的將來，TiDB 一個重要的方向是更加雲化。爲何雲如此重要？數據庫雲化的背後我以爲能夠展開幾點：

• 一個是 Severless；
• 二是智能的調度能力；
• 第三是利用雲的基礎設施下降成本。

爲何說雲如此重要？你們能夠看到右邊這張圖，橫軸是數據量和業務需求，縱軸是企業在 IT 上投入的成本，在雲誕生以前咱們在去作面向不肯定性的業務，面向暴漲的數據量，若是採用傳統的 IDC 部署方式，成本和投入的曲線跟實際的需求不能徹底吻合，其實存在不少資源的浪費。

首先，只有雲真正把整個基礎軟件的商業模式變成了pay as you go，儘量地貼合業務的增加曲線，對於數據庫這樣很重要的基礎軟件來講，在雲上利用雲的彈性可以去更合理地知足業務的實際需求。

第二，雲很好地屏蔽了底層基礎架構實現的複雜性，對於作基礎軟件的人來講，這具備劃時代的意義。好比說利用雲的彈性調度能力以及一些 AI 新技術，使得這個系統更好地理解業務的需求，更加智能地規劃該把數據放置在什麼地方，該創建什麼樣的索引。

第三，雲是很好的基礎設施，面向雲時代的基礎設施如何去設計下一代的基礎軟件，我以爲是一個很重要的課題。最近關注技術圈的朋友，Snowflake 的消息令你們很是振奮，Snowflake 在技術上的選擇也帶給我不少啓發，怎麼經過雲的基礎設施來打造新一代的基礎軟件。

以上是我對近期將來的一些展望和見解。最後我想強調的是，迴歸初心咱們想作的事情就是讓數據庫真正迴歸本來的樣子，把複雜性隱藏在背後，爲用戶提供一個使用門檻很低，解放你們生產力的好產品，謝謝你們！