TiDB Serverless 和技術生態全景

資料庫不是單一軟體，而是一個生態體系。成為一款好用的資料庫，除了產品自身的能力外，繁榮的技術生態體系也至關重要，既可以提升使用體驗，又可以降低使用門檻。

PingCAP 在 2022 年 11 月 1 日正式釋出了 TiDB Cloud Serverless Tier，本次分享在介紹 Serverless Tier 的技術細節之餘，全面解析 TiDB 的技術生態全景和在生態構建中所做的努力。閱讀本文，瞭解有關 Serverless 的更多資訊，以及 PingCAP 在技術領域的最新進展。

雲時代開發者面臨的機遇和挑戰

現在雲已經不再是一個新鮮的事物，我們已經處在雲的時代，與之前相比，雲時代的開發者面臨著與之前不同的機遇和挑戰。在雲時代，我們有著新的技術設施，我這裡舉幾個例子，每個雲廠商都會提供塊儲存服務、物件儲存服務和彈性計算服務。塊儲存服務有高吞吐、低時延和高持久的特性。物件儲存服務，比如 AWS 的 S3、國內阿里雲的 OSS，提供了低成本的海量儲存空間，並且這些儲存還有著超高的可用性，甚至可以跨地域複製來進行容災。而彈性計算服務，可以給我們提供多種規格的計算實力，而且還提供了不同的計費模式，當然，根據使用者的訴求進行彈性伸縮，也是一個基本的能力。

有了新的基礎設施，當然也有新的挑戰。雲廠商給我們提供了許多的雲服務，並且雲的初衷之一，就是讓使用者可以減少很多的運維工作。但是如果你現在深度地使用雲，仍然需要運維大量的雲上基礎設施。這些運維工作使得我們開發者的精力被分散，沒法完全專注於業務本身。除了運維工作之外，如何使用好雲也是一門學問，前不久我剛剛參加了 AWS 的架構師培訓，其實如何多快好省地用好雲，不是一件簡單的事兒。雲服務的使用者，很容易就會造成雲上資源的浪費，產生不必要的高額費用，特別是在現在許多的雲服務，仍然是按時間來收費的情況下。對於有多套環境需求的場景，比如說公司內部有多個團隊，不同的業務有各自的環境訴求，或者在 CICD 的場景下，我們可能會有 preview、stage、product 的多套環境需求，購買多套的雲服務會產生高額的費用，但是共享一套雲服務則可能會產生資源的競爭，甚至出現測試環境影響生產業務的情況。雲上的服務，比如說雲上的資料庫服務，現在的使用方式仍然是提前規劃容量，然後始終按照購買的時候的容量進行工作和計費，如果後期需要調整，仍然需要人工介入，手動去進行擴縮容。

這個是我們目前在使用雲的時候，遇到的一些挑戰。那麼為了解決這些挑戰，PingCAP 推出了 TiDB Cloud Serverless Tier。Serverless Tier 是世界上首款的 Serverless HTAP 資料庫，PingCAP 推出它，希望能夠幫助開發者解決剛才所說的那些挑戰，成為雲時代的新的 HTAP 資料庫解決方案。TiDB Cloud Serverless Tier 目前是一個 Beta 的狀態。下面，我就給大家介紹一下 TiDB Cloud Serverless Tier。

TiDB Cloud Serverless Tier(Beta)

世界上首款 Serverless HTAP 資料庫

當然在之前，我們還是先來看一下傳統的TiDB叢集。這是一個經典的 TiDB 叢集架構，可以看到這是一個非常典型的分層架構，計算層是 TiDB Server，每個 TiDB Server 都是一個無狀態的計算節點，可以非常容易的進行橫向擴容，儲存層是 TiKV 和 TiFlash。TiKV 是我們的分散式行儲存引擎，TiFlash 是列儲存引擎，整個儲存層透過分散式協議實現了一致分散式儲存。在計算層和儲存層之外，我們還有一個排程單元 PD，這裡儲存了整個 TiDB 叢集的元資訊。在這樣的一個架構下面， TiDB 已經有了很好的表現。比如 TiDB 有著非常好的擴充套件性，無論是計算還是儲存，能力都可以隨節點數線性擴充套件。

TiDB 已經在生產場景經歷了數百 TB 規模的資料和百萬級 QPS 的流量的考驗。TiDB 還有著非常好的彈性，系統規模可以隨著業務的需求進行伸縮。而且伸縮是完全線上進行的，不會影響已有的資料和請求。同時，對於系統中的熱點，TiDB 也有能力自動發現，自動排程。TiDB 也有著非常好的容災和高可用的能力，如果節點出現故障，上面的資料可以自動的進行轉移，並且配合 PingCAP 推出的 TiCDC 工具，還能夠做到實時的 CDC 同步，實現異地容災。

但是這樣的一個經典架構在雲的時代，面對著完全不同的基礎設施，存在一些問題。第一，share-nothing，剛才我們提到雲廠商提供的基礎設施，無論是塊儲存，還是物件儲存，天然就有著高可用，高持久的特性，雲廠商已經幫我們做了資料複製，但是 TiKV，TiDB 的儲存層，仍然做的自己的資料複製。這在雲上其實是多餘的，資料的複製不僅僅是儲存資源的浪費，同時還需要消耗大量的頻寬，在雲上，網路也是會造成非常高額的費用。第二，儲存層狀態重。這是因為每個儲存節點，其實都儲存著一些資料的副本，擴容轉移一個故障節點都需要對這些副本進行同步，導致橫向擴充套件的速度仍然不夠快，也進一步導致難以利用雲廠商提供的競價例項，從而能夠進一步的去降低成本。第三，TiDB 之前是一個非常經典的計算、儲存、排程分離的架構。但是在雲時代，這樣劃分的顆粒度仍然過大，每一個節點承擔的責任過多，導致 TiDB 整體的彈性仍然不夠，其實我們可以在雲上，將更多的功能拆分出來形成單獨的微服務，這些微服務可以獨立的去進行擴容和部署，甚至這些微服務可以被多個叢集去共享。如果拆分出更多的微服務，TiDB 叢集整體的彈性會進一步上升。

基於這些問題，其實 PingCAP 做了很多的努力，也都做了相應的改進，大家可以看到這是現在 TiDB Cloud Serverless Tier 的一個新架構。首先在儲存層開發了 Cloud Storage Engine 一個新的儲存引擎，圖中 Shared Storage Layer 和 Shared Storage Pool 這兩層組合起來就是新的 Cloud Storage Engine。現在新的儲存引擎融合使用了雲上的塊儲存和物件儲存，並且消除了原來儲存層冗餘的資料複製，徹底的解決了之前所說的 share-nothing 和狀態重的問題。這樣的改造使得儲存層的節點擴充套件非常容易，而且非常迅速，而且大幅度地降低了成本。

在計算層我們進一步地拆分了 TiFlash，TiFlash 現在它的計算儲存已經可以去分離，TiFlash 的計算部分可以像 TiDB Server 一樣，作為一個獨立的元件去進行管理，去擴容。第二，我們引入了新的一層，叫做 Gateway。Gateway 代替了 TiDB Server 與使用者去進行互動，它負責諸如連線管理、喚醒節點，這樣的功能。它的出現使得我們所說的多租戶成為一個可能。第三，我們池化了計算節點，在圖上右邊的部分，有多個 TiDB 和 TiFlash。我們將計算節點進行了池化，這樣的設計進一步降低了計算層的成本，以及提升了計算節點喚醒的速度。計算層和儲存層的改動，使得 TiDB Cloud Serverless Tier 支援了多租戶。現在一套 TiDB Cloud Serverless Tier 叢集，可以支援多個租戶，每個租戶都是完全隔離的。在使用者看來，他們擁有的就是一套獨立的 TiDB 叢集。

最後，我們還拆分了一些相對獨立的功能，做成微服務，比如資料壓縮服務，降低了計算節點以及儲存節點的複雜性，提升了 TiDB Cloud Serverless Tier 的整體的彈性，後續我們還會繼續對更多的微服務進行拆分。

做完相應的改進，新的架構解決了之前所說的傳統架構在雲上的問題，更好地適應了雲上的基礎設施。這邊總結一下，一是推出了 Cloud Storage Engine，可以融合地使用塊儲存和物件儲存，並且消除了多餘的複製，解決了兩類問題，一是冗餘的複製，二是高額的網路費用。第二，拆分出了更多的微服務，更好地使用了雲上的彈性算力。整體的改動使得 TiDB Cloud 可以支援多租戶。

技術上的努力使得 TiDB Cloud Serverless Tier 擁有了非常新穎的能力。TiDB Cloud Serverless Tier 擁有全部的 TiDB 的 HTAP 能力，是世界上第一款 Serverless HTAP 資料庫。我們最佳化了 TiFlash 的架構，使其更好地適應了雲上多租戶的場景。從剛才介紹的 TiDB Cloud Serverless Tier 的架構上可以看到，我們對計算節點進行了池化，多租戶也共享了儲存。所以，TiDB Cloud Serverless Tier 目前可以做到秒級建立一個 TiDB 叢集，並且如果你長時間不使用，再次連線的時候也僅需數百毫秒的時間就可以恢復完整的叢集。這個操作對於使用者來說，是完全透明的，使用者甚至感知不到。未來，我們會進一步最佳化這個時間，叢集建立時間會持續縮短，喚醒時間也會從數百毫秒縮短到數十毫秒。

作為一款真正的 Serverless 雲資料庫，當然，TiDB Cloud Serverless Tier 是完全無需使用者去運維的。在使用方式上，不需要像傳統的雲資料庫那樣，提前去規劃容量，在需要的時候進行擴縮容，TiDB Cloud Serverless Tier 會根據流量自動地進行伸縮，無需任何手動的操作。具備了這麼強大的能力，TiDB Cloud Serverless Tier 的計費方式也是真正的按使用量付費，使用者只需要為自己真正使用的資源進行付費，不使用，即使這些叢集仍然在執行當中，你也無需支付任何的費用，這也是 TiDB Cloud Serverless Tier 區別於傳統雲資料庫甚至於其他 Serverless 資料庫的不同之處，這些資料庫即使你不使用，但只要叢集被建立出來，仍然會按照建立時的規格進行收費，這其實會造成極大的資源浪費。

同時 TiDB Cloud 是支援多雲廠商的，Serverless Tier 也將會繼承這一點。目前 TiDB Cloud Serverless Tier 僅支援在 AWS 上建立，但未來一定會支援更多的雲廠商，同時 Serverless Tier 還支援多個區域，滿足使用者時延和資料儲存區域選擇的訴求。

講了這麼多，接下來我們來展示一個 Demo，這個 Demo 就是我們從無到有來建立一個 TiDB Cloud Serverless Tier 叢集，這個其實也是基本上是所有使用者唯一需要與 TiDB Cloud Serverless Tier 打交道的一個動作，因為剛才我們說了，一旦建立之後其實你不需要去運維，你也不需要去進行手動擴縮容，TiDB Cloud Serverless Tier 會根據你的流量自動進行擴縮容，我們開始看一下叢集建立的過程。

我們只需要點選建立，如果你需要可以選擇名字以及供應商以及 region，這裡我們都是使用預設的。然後就進入了建立的一個過程，可以看到大概在 20 秒的時候整個叢集其實就已經從 creating 的狀態變成了 avaliable 的狀態，TiDB Cloud Serverless Tier 現在整個建立時間大概就是在 20 秒左右，可能會上下有一定波動，基本是在這樣一個量級。只需要 20 秒你就可以擁有一個完全工作的 HTAP 雲資料庫，並且後續不需要你進行任何操作以及與它有任何運維上的互動。

希望經過我們的努力，TiDB Cloud Serverless Tier 可以成為一個服務於每個人的 HTAP 資料庫，TiDB Cloud Serverless Tier 現在擁有了完整的 HTAP 能力，可以處理複雜的工作負載，並且真正地按使用量付費，對於任何人都只需要為自己使用的計算資源和儲存資源付費，不存在資源浪費的情況，具有非常高的價效比。對於個人開發者，TiDB Cloud Serverless Tier 每個月其實都提供了一定量免費的 Quota，只要不超過這個 Quota，對於個人開發者而言，TiDB Cloud Serverless Tier 就是一個完全免費的觸手可及的 HTAP 資料庫，對於 Startup 來說，TiDB Cloud Serverless Tier 可以跟隨業務增長自動進行擴容，而且這個擴容完全是自動的，不需要手動介入。Startup 可以專注於他的業務本身去發展自己的業務，不需要為資料基礎設施去操心。對於大公司而言，因為 TiDB Cloud Serverless Tier 超高的價效比以及非常迅速的建立恢復時間，使得雲上資源不再成為一個限制，每個部門、每個環境都可以擁有自己獨立的資料庫，未來我們還會推出 data branching 更好地幫助企業客戶，當然如果公司有跨雲部署的訴求，TiDB Cloud Serverless Tier 也是一個非常完美的選擇。

資料庫不是單一軟體，而是一個生態體系，除了產品自身的能力，繁榮的技術生態體系也至關重要

當然，對於任何一個資料庫的使用者不可能僅僅與資料庫軟體本身打交道，同時需要使用大量的資料庫生態軟體，TiDB Cloud Serverless Tier 擁有非常豐富的生態，接下來我們就來看一下 TiDB 的生態。資料庫不是單一軟體，而是一個生態體系，除了產品自身的能力，繁榮的技術生態體系也至關重要。TiDB 從出生起就非常重視生態，所以選擇了與 MySQL 相容，並且在這個上面做了許多努力。

因為 TiDB 是 100% 相容 MySQL 協議的，所以 TiDB 與所有的主流語言都是相容的，比如 Go、Ruby、Java 、Python、JavaScript 等等，還有更多。TiDB 相容的遠遠不只這些語言，這裡列了一些比較流行的語言，只要一個語言擁有 MySQL driver，它就可以使用 TiDB，使用 TiDB Cloud Serverless Tier，不管這個語言多麼小眾。

在語言之上，TiDB 還與基本上所有的流行的 ORM 框架相容，與語言的 driver 不同，除了協議層的相容之外，ORM 往往在功能上對 MySQL 的相容性有著更高的要求，TiDB 的一些擴充套件能力也需要去進行補齊。TiDB 在這個方面做了很多努力，首先針對一些 ORM 開發了自己的外掛，比如對於 django 和HIBERNATE，我們開發了django-tidb 和 hibernate-tidb 外掛。TiDB 也在產品本身的 MySQL 相容性的能力上做了很多增強，比如，可能在應用中我們可以不用，但是對於許多 ORM 框架都非常重要的兩個功能 savepoint 和外來鍵。這兩個功能對於很多的 ORM 框架來說都非常重要，很多 ORM 框架對他的依賴都非常重。在最近兩個 TiDB 的版本中釋出了savepoint 功能和實驗版本的外來鍵功能，這使得 TiDB 進一步提升了與許多 ORM 框架的相容性。

除了語言的 driver 和 ORM 框架之外，TiDB 以及 TiDB Cloud 還可以整合許多流行的平臺，我們這裡羅列了一些主要的，比如在資料處理領域，TiDB 可以與 Spark、Flink、Databricks 這些流行的大資料處理框架以及平臺結合使用，來構建企業的 ETL pipeline，形成統一的資料處理平臺。同時除了傳統的 ELT 平臺，TiDB 還可以與海外非常流行的 modern data stack 體系進行整合，我們給 Airbyte 貢獻了 tidb-source-connector 和 tidb-destination-connector，開發了 dbt-tidb adapter，使得 TiDB、TiDB cloud 可以完美地與 Airbyte、dbt 進行整合。

當然 TiDB 還支援類似於 Metabase 這樣的 BI 平臺，分析 TiDB 中儲存的資料。在 CDC 的領域 TiCDC 支援了 avro 格式以及 kafka sink，使得 TiCDC 可以支援將資料匯出到 confluent 平臺，同時我們還測試了與 arcion 平臺的相容性，可以使用 arcion 平臺來做 TiDB 或者 TiDB Cloud 的 CDC。

TiDB 和 TiDB Cloud 很早就支援了使用 prometheus 和 grafana 作為監控平臺，我們還支援將監控的 metrics 匯出到 datadog 平臺，還可以實現與 Serverless 部署平臺 Vercel、Netlify 的整合，以及與 no-code workflow automation 平臺，像 zapier、n8n 的整合，以及與 IaC 工具 Terraform 的整合等等。接下來深入到一些領域來仔細看下。

首先來看 modern data stack 領域也就是我們所說的 ELT pipeline，注意，這裡不是傳統的 ETL pipeline，是 ELT pipeline。首先介紹一下 Airbyte 和 dbt，Airbyte 是一個 data pipeline 平臺，它可以連線數百種資料來源和資料匯，將資料來源中的資料匯出到資料匯中，然後在資料匯中對資料進行整理。基於此，使用者可以透過 Airbyte 實現任意的資料遷移，它的口號就是 data from any source to any destination。dbt 是一個 data transformation 工具，藉助 dbt 使用者可以非常靈活地在資料庫或者資料倉儲中運算元據，進行資料變換。結合使用 Airbyte、dbt 和 TiDB Cloud，使用者可以將任意資料來源中的資料，比如在 salesforce 中的 CRM 資料，google sheets 中的表格資料，甚至是像 Instagram 這樣 2C 應用中的企業運營資料匯入到 TiDB Cloud 中。有了資料，我們可以利用 BI 工具進行資料分析，因為 TiDB 以及 TiDB Cloud Serverless Tier 是一個 HTAP 資料庫，在面對分析型負載的時候，有著更好的表現。甚至，如果說使用者有資料歸檔的訴求，可以繼續將 TiDB 作為 Airbyte 的資料來源，將資料匯入到像 Snowflake、Databricks、Google Big Query 這樣的資料倉儲或者說資料湖中去。

總的來說，使用者如果結合使用 TiDB Cloud、Airbyte 和 dbt 建立一條 ELT data pipeline，一是可以使自己的資料設施 all in Cloud，整條流水線都可以擁有非常好的彈性，可以滿足業務增長的訴求。同時雲上的基礎設施擁有很高的價效比，可以降低資料基礎設施的成本，而且因為 all in Cloud，你無需運維，降低了資料整合的技術、費用門檻。二是可以加速企業內業務資料的流動，Airbyte 擁有上百種的資料聯結器，使用者可以直接去使用，無需自己設計、開發，從而企業內的資料分析師可以更快地進行資料分析，幫助企業發現新的商業機會，而不是把精力浪費在基礎設施的重複建設當中。

接下來看 Vercel，Vercel 是海外領先的前端部署平臺。使用 Vercel 開發者可以非常迅速地將自己的 web 應用進行部署、分發給全球的訪問者，在這個過程當中 Vercel 還可以加入到開發者的 CICD 流程當中，使開發者可以輕鬆地預覽效果。同時藉助 Vercel 遍佈全球的邊端網路，訪問者可以以極低的時延訪問 web 應用，獲得更好的使用者體驗。

Vercel 本身作為一個 Serverless Frontend Infrastructure，它不具備持久化資料儲存的能力，這也就意味著如果僅僅使用 Vercel 的能力，沒辦法去開發一個複雜的 web 應用。所以我們可以結合 Vercel 和TiDB Cloud Serverless Tier，從而獲得一套完整的 web 開發的 Fullstack Serverless Infrastructure，和前面的 all in Cloud 的 data pipeline 一樣，這套 Web App Develop Infrastructure 也是 all in Cloud，使用者無需運維，基礎設施可以自動擴充套件，並且具有很高的價效比。

為了讓使用者更好地使用 Vercel 和 TiDB Cloud Serverless Tier，我們開發了 TiDB Cloud Vercel Integration ，你可以在 Vercel 的 Integration 市場中找到它，透過這個 integration，只需要簡單的幾次點選就可以連線 TiDB Cloud Serverless Tier 叢集和 Vercel 專案。同時我們還開發了 TiDB Cloud Starter 模板，這個模板可以讓使用者透過幾次點選和幾分鐘的等待，就從無到有地構建一個全球可訪問的 web 應用。以下是一個簡單的 demo 讓大家來體驗這套 Fullstack Serverless Infrastructure。

這是 Vercel 的 template 列表，先找到我們的 TiDB Cloud Starter 模板，進入模板的詳情頁，點選 deploy 進到一個流程頁。首先因為這是一個模板，所以我們要基於這個模板來建立一個我們自己應用的程式碼倉庫，這裡選擇 starter，你只要簡單的一次點選就可以。

在這個過程當中整合了 TiDB Cloud Vercel Integration，這個頁面就是 integration 的頁面。這裡選擇我們想要的 Vercel 專案以及想要的 TiDB Cloud Serverless Tier 的叢集，選擇之後點選 integrate，這個 integrate 的過程就結束了。到這裡我們需要操作的過程已經完全結束了，現在處在等待 Vercel 幫你構建專案以及部署專案的一個階段。大家可以看到，建立我們自己的程式碼倉庫點選了一次，進行 integrate 點選了大概一到兩次，我們就完成了所有的操作。

接下來稍微等待一下，大家可以看到現在大概過了兩分鐘，整個部署和構建過程就完成了。我們到 Vercel 專案的詳情頁去點選 visit，可以看到這時候這裡展示的頁面就是透過模板構建出來的一個專案的主頁，大家可以看到這上面的 URL 是一個所有人都可以訪問的 URL，現在這個專案已經對全球可以訪問了。任何人在地球上的任何角落現在都可以來訪問 bookstore 這個專案，整個的耗時也就大概兩三分鐘。這個專案前端整個的程式碼應用邏輯是部署在 Vercel 的 Serverless 的架構上面，後端資料儲存是儲存在 TiDB Cloud Serverless Tier 叢集中。

我們進入下一個生態 Terraform，Terraform 是業界預設的跨雲 IaC 工具，使用 Terraform 可以使用程式碼來管理雲基礎設施，將它整合到我們的 CICD 流程當中，我們在前不久開發了 TiDB Cloud Terraform Provider，使得使用者可以透過 Terraform 來管理 TiDB Cloud 的資源。像圖上展示的，我們可以透過這樣的一個 Terraform 檔案來建立一個 TiDB Cloud Serverless Tier 叢集。Terraform Core 會解析這個檔案，將 TiDB Cloud 資源的相關定義都發給我們開發的 TiDB Cloud Terraform Provider，TiDB Cloud Provider 會呼叫 TiDB Cloud Go SDK 來操作 TiDB Cloud 的資源。PingCAP 已經和 HashiCorp 成為了技術合作夥伴，TiDB Cloud Terraform Provider 也已經是 HashiCorp 認證的 Partner Provider，歡迎大家使用 Terraform 來操作 TiDB Cloud 的資源。

展望未來

最後，我們一起展望一下未來，TiDB Cloud Serverless Tier 才剛剛釋出，我們仍然有很長的路要走。

目前因為剛剛推出，Serverless Tier 還沒有向使用者開放諸如像備份、恢復、監控、報警這樣的能力，我們很快就會新增這些能力並對使用者進行開放。我們還會開發 PiTR 和 Branching 這些功能，方便使用者進行資料共享，將資料庫納入CICD。我們還會進一步地去降低建立時間和成本，期望 Serverless Tier 叢集的建立時間能從現在的 20 秒降低到 5 秒，喚醒時間從數百毫秒降低到數十毫秒。後續會推出 Data API，Data API 是透過 RESTful API 的形式提供資料庫的 CRUD 能力，未來除了 RESTful 之外還可能推出 GraphQL API。透過 Data API 希望 Serverless Tier 可以更好地與 Serverless 生態結合，服務邊緣請求。現在很多的 Serverless 的部署平臺加速從中心化的託管能力向邊緣進行擴張。當我們使用邊緣的一些託管 runtime 是根本無法發出像傳統的 TCP 請求的，所以 Data API 的推出可以讓 Serverless Tier 更好地與這些平臺進行結合。

在生態方面，我們會進一步提升 MySQL 相容性，對接更多平臺，給使用者提供更多選擇。PingCAP 始終堅持開源開放的路線，TiDB 社群從誕生開始就開放幷包，我們期望大家加入，共建 TiDB 的繁榮生態。