導讀
在 TiDB 8.1 發布后，TiDB 展現了強大的支持 SaaS 業務的能力，成為 SaaS 業務數據庫的優先選擇之一。
本文為“當 SaaS 愛上 TiDB”系列文章的第一篇，系列文章將從技術原理和真實用戶體驗兩個角度深入探討 TiDB 在 SaaS 業務中的表現，包括如何應對可擴展性、多租戶管理、運維便利性、高可靠性等挑戰，后續文章將分別從資源隔離、彈性擴展、方便運維、業務架構等角度展開。通過這些內容，您將了解為何 TiDB 是高成長 SaaS 業務的最佳選擇。
本文作者：唐劉，PingCAP 研發副總裁。
當TiDB 8.1 發布之后，我非常相信，TiDB 已經具備了支持客戶 SaaS 業務的能力，甚至可以做為客戶 SaaS 業務數據庫的最優先選擇之一，為什么我會這么篤定，主要信心的來源就是我已經看到了非常多的客戶，來自不同的行業（譬如游戲，電商，AI，互聯網等等），基于 TiDB 構建他們的 SaaS 業務的成功案例。
當然，成功并不是一蹴而就的，TiDB 也并不是從一開始就能支持好客戶的 SaaS 的業務，所以后面，我會寫一系列的文章，來聊聊 TiDB 是如何在 SaaS 業務場景下，如何一步一步贏得客戶的『信任之旅』，以及說明下為什么 『TiDB 會成為你高成長 SaaS 業務的第一選擇』。
一個好的 SaaS 業務給數據庫帶來哪些挑戰？
什么是 SaaS，網上已經有太多的解釋，這里簡單的說明一下，SaaS 全稱為軟件即服務，新一代 SaaS 目前都是基于云計算的軟件服務，通過互聯網提供軟件應用。用戶無需在本地計算機或服務器上安裝和維護軟件，而是通過網絡瀏覽器進行訪問。SaaS 業務由服務提供商托管和管理，用戶可以從任何有互聯網接入的設備訪問，并且通常采用訂閱制，使其對企業和個人來說既方便又具有成本效益。從某一方面來說，TiDB Cloud 也算是一種 SaaS，后面如果有機會，我也可以寫寫我們是如何構建 TiDB Cloud 這個 SaaS 業務的。
SaaS 業務的挑戰非常的大，對于數據庫的要求尤其的高。通常一個數據庫要支持好 SaaS 業務，會面臨如下的一些挑戰：
可擴展性 - SaaS 業務一個非常有意思的點就在于你的業務的租戶數量可能會從一點點突然就漲到了成千上萬，甚至百萬以上的級別，而單個租戶數據也可能從 GB 級別瘋漲到百 TB 級別。在整個業務增長，數據膨脹的過程中，數據庫的可擴展性尤其重要：客戶總不可能容忍因為數據庫沒法承載業務增長導致錯過成長紅利。
多租戶的管理 - 如何在一個數據庫里面管理多個租戶，既要確保這些租戶之間的數據隔離以及安全，又要保證租戶之間不能相互影響，是一件非常困難的事情。
方便運維 - SaaS 業務另一個好玩的點就在于業務的快速變化，我們如何對數據庫進行快速的變更以滿足不斷變化的業務需求，還有如何快速的對不同的租戶進行數據備份，性能監控等等，在運維上面都是挑戰。
高可靠性和高可用性 - SaaS 業務的連續性非常重要，如果 SaaS 業務出現宕機，影響的可是成千上萬的租戶，這個損失客戶是承受不起的。數據庫需要穩定高可靠的長時間運行，即使出現最極端的情況，也要保證能快速的幫助客戶恢復數據。
還有：高性能、數據安全和合規、成本等等。
可以看到，要支持好一個 SaaS 業務，對數據庫的核心能力要求非常的高。下面我就來大概的介紹下 TiDB 是如何應對上面的一些挑戰的。
可擴展性-SaaS業務增長的基石
如果你問我，要支持好 SaaS 業務，對于數據庫來說，最重要的特性是什么？我會毫不猶豫的回答 - 『可擴展性』。一個不支持可擴展性的數據庫是沒法支持好客戶的 SaaS 業務增長的。
說起可擴展性，我猜測，大部分的讀者立刻能想到的就是數據規模的可擴展性，這個也是 SaaS 業務一個通用需求。而這方面，TiDB 具備天生的優勢，因為 TiDB 從一開始就具備水平擴展能力，隨著數據規模的增大，客戶唯一需要做的一件事情就是不斷地增加存儲節點，TiDB 會自動的將數據進行切分打散到不同的存儲節點，并且使用多副本的方式保證數據的高可用性。這塊網上因為有太多的文章，就不詳細的說明了。
**不過，數據規模僅僅只是可擴展性一個方面的挑戰，這里說另外一個例子，就是 schema 的可擴展性挑戰。**我們的一個客戶，他在設計自己的 SaaS 業務的時候，讓所有租戶共用一套 schema 模板，也就是實際創建一個租戶的時候，一個租戶一個數據庫，每個數據庫里面有十幾張表，所以不同租戶除開數據庫名字不一樣，里面的表結構是一模一樣的。最開始這個客戶只有幾千個租戶，不過很短時間，租戶數量直接直接漲到了 10 萬個，這就意味著他需要在 TiDB 里面存至少 100 萬級別以上的 tables，簡化一點，我們就說 1M tables，我不確定有多少數據庫有信心說能很好的支持好 1M tables 這個場景。坦白的說，當前我們只能說能承接 1M tables 這個場景，還有很多挑戰需要攻堅，關于這塊的，我后面也會有文章詳細的說明。
除開上面兩個例子，可擴展性還包括很多方面，這個我們會在后面的文章中具體解析。
下圖是一個客戶實際的例子，他使用 TiDB Cloud 提供的自動擴縮容功能，在一小時之內直接新增了 200 個計算節點，承載住了那一段時間的業務流量，然后在業務穩定之后，又下線了 50 個計算節點，節省了成本。
方便運維-為SaaS業務敏捷性兜底
SaaS 業務以靈活多變著稱，靈活多變就意味著業務邏輯調整的頻繁，甚至會對數據庫進行變更，而變更，恰恰是最容易引入故障的。
第一個最直接挑戰就是 Schema 的變更，研發不可能一開始就規劃好 Schema 設計，所以就很可能出現為了業務對 schema 進行變更的情況。可能有些讀者會說，不就是做 DDL 操作嗎，對數據庫不就是小菜一碟？不過假設現在一個客戶在數據庫里面存了 10 萬個租戶，一次業務變更，可能要進行 10 萬次 DDL 操作，中間的任何失敗，以及執行效率變慢，都會影響到實際的業務變更，拖慢業務的迭代。
所以對于數據庫來說，在 DDL 這塊，需要具備如下關鍵核心能力：
- Online DDL 能力，確保做 DDL 的時候不會影響在線業務。
- 失敗重試管理，譬如能隨時從中途某一個階段恢復繼續執行。
- 高效，快速，性能好，譬如如果要給一個 100TB 的表添加索引，需要小時級別就能搞定，甚至越快越好。
另一個挑戰就是依據對業務的規劃，對數據庫進行擴縮容處理。譬如下一周如果有一個重要的活動，譬如最近的歐洲杯，或者游戲新功能上線，客戶需要提前做好應對。這一塊一直是 TiDB 的優勢，上面也說到了，這里就不提了。
還有一個非常大的變更挑戰，這個算一個低頻的操作，不過真要做的時候，大家的頭一定是非常大的 - 這個就是數據庫版本的升級。SaaS 業務在這方面，挑戰尤其突出：如果只能停機升級，這個對于客戶來說，就會面對成千上萬個租戶的業務停機，對客戶來說這個損失不可想象。另外，如果因為代碼 bug（無論是 SaaS 業務自身，還是數據庫自身），可能會導致一部分租戶能正常工作，一部分租戶出現問題，對于特定租戶的數據修復，也是一個非常大的難題。
TiDB 從一開始就支持了 online upgrade，能讓客戶不停機，直接在線滾動升級，不影響客戶的業務連續性。在 TiDB Cloud 上面，我們也提供了非常充分的升級解決方案，更進一步保證升級的成功。當然 TiDB 也還有一些挑戰需要更好的解決，這個后面有機會再說。
下圖是另一個客戶跑的一個 SaaS 業務（某客戶給我們提供的數據，做了脫敏處理）。他在 30 分鐘時間內進行了 300 多次 DDL 變更，這里我們僅僅列出了 create table，還并沒有列 drop，alter 的統計。實際上這個客戶的 DDL 頻繁一直如此頻繁，而如此頻繁的進行 DDL 處理，我只能猜測，客戶實際已經是基于 TiDB Online DDL 特性，構建他自己的 SaaS 業務邏輯了。
資源管控-助力精細化資源管理
多租戶的支持是 SaaS 業務里面一個很重要的能力，對于客戶來說，在數據庫里面，一個很重要的難題就是我需要給這一個租戶設置多少的資源，才能確保一方面這個租戶的業務能正常運行，而另一方面則是不能影響到其它的租戶。
這里其實就涉及到數據庫里面資源隔離，或者資源管控的支持。在非常多的數據庫里面，通過使用 cgroup 或者其他方式，提供了按照 CPU/Mem 等物理資源拆抽象的隔離方案，譬如我給租戶 1 設置只能使用 8c16g 的資源，給租戶 2 設置只能使用 16c32g 的資源，這種資源設置的方案非常的直觀，客戶也容易理解，為了便于說明，我們后面叫這個方案為 resource group(RG)。
**相比于單純的 RG，TiDB 提供了另一種抽象，我們叫做 request unit(RU)。**為什么我們要提供 RU 的抽象，一個很重要的原因就是我們希望客戶能更加細粒度的控制自己的資源，譬如對一條特定的 SQL 進行細粒度的控制。一個例子，在 RG 這個方案里面，我給一個租戶設置了 16c32g 的資源，不過這個租戶完全跑滿了，那么到底是哪幾條 SQL 占用了最多的資源，是不是需要控制這些 SQL 的資源開銷？另外如果我發現一個租戶一直沒跑滿過資源，我是不是要重新設置下它的 RG，不過萬一這個租戶在某一天突然又需要更多的資源，我如何來調整？這些都是一些比較有意思的挑戰。
而使用 RU 的方式，是容易就能達到精細化控制的效果，幫助客戶能更好的看清楚自己業務每一條 SQL 的資源開銷，針對性的進行成本優化。如果你要對你的租戶進行收費，RU 也可以提供更加細粒度的賬單，方便你更好的設計你的定價模型。當然，RU 這個方案也并不是完美的。關于 RG 和 RU 的優劣，后面有時間，可以再來討論。
因為現在的數據庫幾乎都能支持 HTAP 了，所以如何在一個數據庫里面很好的處理 TP 還有 AP 的業務，也是在資源管控上面的另一個挑戰。不少的數據庫，在自己的存儲層支持了行列混存的方案，而 TiDB 則是完全的將行列兩種數據分別放到了不同的存儲節點上面，從物理上面進行了隔離。
為什么我們要選擇行列分離的存儲方案，一個很樸素的偏見就是我們認為 AP 的查詢都是會占用比較多的資源的，無論是 IO 還是 CPU，在物理層面上面 TP 和 AP 分開，會顯著的減少 AP 對于 TP 的影響，做到更好的，更徹底的隔離。行列混存方案在資源充分的情況下工作的很不錯，不過當資源吃緊的時候，我們并不相信這樣的方案能很好的保證 AP 不會干擾 TP。而 TP，恰恰是客戶跑得最重要的業務。關于這兩個方案的優劣對比，后面有時間，也可以再來討論。
下圖是一個客戶在 TiDB Cloud 使用 RU 的效果（客戶自己提供的監控數據），可以明顯的看到，在設置好 RU 之后，租戶之間的影響降低了，整體的 TP 業務更加的穩定。
寫在最后
上面僅僅只是列舉了一些 TiDB 如何支持好客戶的 SaaS 業務的例子，可以看到，我們實實在在的助力了客戶 SaaS 業務的增長，幫助這些客戶成功，能贏得這些客戶的信任，是我們的榮幸。
當然，離真正的讓任何的 SaaS 業務在 TiDB 上面都能完美順暢的直接運行，我們還有很長的一段路要走。在后面的系列文章中，我會詳細的介紹 TiDB 在 SaaS 業務場景中一系列具體的挑戰（譬如 1M tables，資管隔離等） 以及我們是如何應對的。我也會介紹一些客戶是如何基于 TiDB 構建他們自己 SaaS 業務的最佳實踐。
在產品方向上面，SaaS 業務的支持也會做為今年以及未來幾年 TiDB 重點的發展方向，所以如果你的業務是 SaaS 業務，需要選擇一款數據庫，不要猶豫，請從現在開始使用 TiDB。即使當前可能在一些方面 TiDB 會有一些問題，我們也會跟你一起努力，共同克服難關，在助力你 SaaS 業務增長的同時，也一起將 TiDB 打造成全世界上『高成長 SaaS 業務的首選數據庫』。
)
