概覽
我們很高興爲大家帶來 TiDB 最新版 6.0 的介紹。雖然是一個開源數據庫，但 TiDB 的定位一直都是面向企業級和雲的數據庫，而 TiDB 6.0 也是圍繞這個主題而研發的。在最新版本中，我們大幅度加強了作爲企業級產品的可管理性，與此同時也加入了諸多雲原生數據庫所需的基礎設施。
對於企業級和雲數據庫，除了性能，可用性和功能等常規維度外，一個重要維度就是可管理性。除了提供必備的「硬」能力以完成用戶的技術及業務目標，是否「好用」，是用戶做選擇時的重要考量，可管理性維度也會很深地影響用戶實際使用數據庫的隱性成本。而這點對於雲數據庫則更爲明顯，將數據庫作爲雲服務提供，將使得可管理性的重要程度被放大：一個可運維性更好的數據庫，在固定的運維和支持資源下，將爲用戶提供更好的服務。
針對這個方向，TiDB 6.0 引入數據放置框架（Placement Rules In SQL），增加了企業級集羣管理組件 TiDB Enterprise Manager ，開放了智能診斷服務 PingCAP Clinic 的預覽，大幅加強了生態工具的可運維性，並針對熱點問題爲用戶提供了更多的手段。這些努力加在一起，將使用戶無論使用的是公有云服務，還是私有部署，都獲得體驗更平滑和近似的使用體驗，讓 TiDB 在成熟的企業級雲數據庫維度更向前邁進。
除此之外，在這一年的時間內 TiDB 6.0 相較於前序版本也有了長足的進步，修復了 137 個 Issues，並融入了 77 個嚴苛的真實環境錘鍊帶來的增強。而社區一直期望的 TiFlash 開源也實現了，歡迎廣大社區開發者一起參與。
<div class="is-flex is-flex-direction-row is-justify-content-center"> <div class="is-flex is-flex-direction-column"> <a target="_blank" rel="noopener noreferrer" class="button is-link mx-5" href="https://pingcap.com/zh/product-community/?utm_source=blog&utm_medium=cta&utm_campaign=tidb-6.0-release" style="background-color: #4fc172;"> 下載 TiDB 社區版 </a> </div> <div class="is-flex is-flex-direction-column"> <a target="_blank" rel="noopener noreferrer" class="button is-link mx-5" href="https://tidbcloud.com/signup?utm_source=blog&utm_medium=cta&utm_campaign=tidb-6.0-release" style="background-color: #3a40e1;"> 註冊 TiDB Cloud </a> <div style="font-size:12px; text-align:center">適用於中國出海企業和開發者</div> </div> </div>
全面加強可管理性
可管理性是數據庫的一個重要能力維度：在滿足業務需求的前提下，是否靈活易用，將決定了用戶技術選擇背後的隱性成本。這種成本可大可小，可以是一句抱怨，也可能會結合人因帶來災難性後果。在最新版本研發過程中，我們結合了客戶和市場反饋，總結了當前的可管理性的問題仍存在的缺失，這包含了「複雜且不直觀的集羣的日常管理」、「無法控制數據的存儲位置」、「數據生態套件難於使用」、「面對熱點缺少解決方案」等多個維度，而 TiDB 6.0 從內核、數據生態套件、增強組件多個方面針對這些問題進行了加強。
自主的數據調度框架
讓我們先從內核部分開始。
TiDB 6.0 以 SQL 形式對用戶暴露數據調度框架（Placement Rule In SQL）。以往，TiDB 的數據調度對於用戶一直都是黑盒，TiDB 自行決定某一個數據塊應該存在哪個節點，無論數據中心的物理邊界和不同規格機器差異。這使得 TiDB 在多中心，冷熱數據分離和大量寫入所需的緩衝隔離等場景下無法提供靈活的應對。
我們先看兩個有趣的場景：
-
你有一個業務橫跨多個城市，北京、上海和廣州都設有數據中心。你希望將 TiDB 以跨中心的方式部署在這三個數據中心，分別覆蓋華北、華東和華南的用戶羣，讓不同區域的用戶可以就近訪問數據。在以往的版本中，用戶的確可以跨中心的方式部署 TiDB 集羣，但卻無法如上述期望地將歸屬不同用戶羣的數據存放在不同的數據中心，只能任由 TiDB 按照熱點和數據量均勻分佈的邏輯將數據分散在不同中心。在高頻訪問的情況下，用戶訪問很可能會頻繁跨越地域進而承受很高的延遲。
-
你希望用一組導入專用節點專門用於隔離導入數據所帶來的性能抖動，而後再將導入完的數據遷回工作節點；或者你希望用一組低配節點存放冷數據，接受低頻歷史數據訪問。暫時，還沒有特別的手段支持這樣的用況。
TiDB 6.0 開放的數據調度框架提供了針對分區 / 表 / 庫級數據在不同標籤節點之間的自由放置接口，用戶可以針對某張表、某個數據分區的存儲位置做出自定義的選擇。在新版本中，用戶可以將一組節點給與標籤，併爲這組標籤定義放置約束。例如你將所有位於紐約機房的 TiDB 存儲節點定義放置策略：
CREATE PLACEMENT POLICY 'newyork' CONSTRAINTS = "[+region=nyc]";
然後將這個策略應用於表：
CREATE TABLE nyc_account (ID INT) PLACEMENT POLICY = 'newyork';
通過這種方式，所有 NYC_ACCOUNT 的數據將存放在紐約機房，而用戶的數據訪問請求也自然會被路由到本地機房。
類似的，用戶可以爲機械磁盤節點打標籤用以冷存和低頻訪問以節省成本，並將舊數據分區放置在低成本節點。
CREATE PLACEMENT POLICY storeonhdd CONSTRAINTS="[+disk=hdd]";
ALTER TABLE orders PARTITION p0 PLACEMENT POLICY = 'storeonhdd'；
另外，該功能也可被用於多租戶隔離場景。例如在同一集羣中，用戶可以將不同租戶的數據經由放置規則分配到不同節點，而不同租戶的負載也將自動由對應節點處理。這使得 TiDB 具備了租戶隔離的能力，且輔以合理的權限設置，租戶之間仍保有數據互訪的可能。
雖然是一個大型功能引入，但實際上這個框架的主體部分，已經通過 TiFlash 的行列分離能力於 4.0 版本間接發佈給用戶使用了，且經過了超過一年的迭代和打磨。因此，雖然是一個重大變更，但該框架卻已經擁有了成熟的案例。本次發佈將 Placement Rules 能力藉以 SQL 的形式向用戶全面開放，除了解決上述問題之外，也希望藉助社區無限的想象力，發掘更多有價值的用法。
熱點場景應對
分佈式數據架構下，有一個惱人的話題：如何應對熱點。在熱點數據訪問或鎖衝突場景下，分佈式數據庫無法發揮多計算節點的性能優勢，造成性能瓶頸，影響業務穩定和應用體驗。TiDB 6.0 針對這類問題增加了多種解決方案。
小表緩存
有時用戶的業務同時涉及大表（例如訂單）和若干小表（例如匯率表），其中大表的負載很容易通過分佈式分擔，但每次交易亦要訪問的小表的數據卻容易造成性能瓶頸。TiDB 6.0 新引入的小表緩存功能，支持顯式將小的熱點表緩存於內存中以大幅提高訪問性能，提升吞吐，降低訪問延遲，適用於高頻訪問低頻更新的小表場景，例如配置表，匯率表等。
內存悲觀鎖
通過將悲觀鎖事務緩存化，大幅降低悲觀場景下的資源開銷，CPU 和 IO 開銷降低 20%左右，同時性能提升 5%-10% 左右。
除了上述新增功能外，TiDB 未來還將提供基於負載的熱點 region 自動分裂能力，提升熱點數據的訪問吞吐，解決非預期突發熱點訪問造成的性能問題。
數據生態套件可管理性提升
作爲 TiDB 產品重要的一環，數據生態套件之於可管理性尤爲重要。具體到數據遷移場景，當用戶在對大規模的MySQL Sharding 系統進行遷移時，需要有很多的遷移任務、遷移規則、源端和目標端表相關的配置和管理工作。 在數據同步環境的日常管理過程中，經常需要對數據同步任務進行監控、診斷、創建、刪除等管理操作。 命令行的操作在進行復雜運維操作，或者大量任務操作時，通常會效率很低，而且容易出錯。由此，在新版本中，DM 推出了基於 Web 的圖形管理工具，幫助用戶更加方便的對整個數據遷移環境進行管理。它包含了如下功能：
- Dashboard： 包含了 DM 中同步任務的主要監控信息和運行狀態信息，幫助用戶快速瞭解任務的整體運行狀況，以及與延遲、性能相關的重要信息。
- 數據遷移任務管理功能，幫助用戶監控、創建、刪除、配置複製任務。
- 數據遷移上游管理功能，幫助用戶管理數據遷移環境中的上游配置，包含了，新增、刪除上游配置、監控上游配置對應的同步任務狀態、修改上游配置等相關的管理功能。
- 遷移任務詳細信息管理功能，根據用戶指定的篩選條件查看同步任務的具體配置和狀態信息，包括，上下游配置信息，上下游數據庫名稱、表名稱等。
- 集羣成員信息管理功能，幫助用戶查看當前 DM 集羣的配置信息和各個 worker 的狀態信息。
全新的管理平臺和智能診斷套件
TiEM 管理平臺
從最初版本至今，TiDB 的日常運維都是以命令行操控爲主。雖然 TiDB 從 4.0 開始推出 TiUP 工具對 TiDB 集羣進行安裝部署和運維操作，降低了管理複雜度，然而它終究是命令行工具，學習成本較高，對相當多的企業用戶而言，並不合意。除此之外，我們也經常遇到用戶同時管理多個業務的多套集羣，且配置和規格各不相同，任何集羣變更和監控都是一個很大的挑戰。一個無心的疏忽登錄了錯誤的管理節點，應用了錯誤的變更，就可能帶來無法挽回的損失。我們曾經遇到過僅僅因爲切錯命令行分頁，而將生產集羣當做測試集羣關閉的慘況。現下諸多企業級數據庫都擁有圖形化管理界面，而 TiDB 6.0 中，也引入了 TiEM（TiDB Enterprise Manager）。
在當前版本中，TiEM 集成了資源管理，多集羣管理，參數組管理，數據的導入導出，系統監控等諸多功能。用戶可以通過 TiEM 在同一界面管理多套集羣，擴縮容，數據備份恢復，統一參數變更，版本升級，主備集羣切換等。TiEM 還內置了監控和日誌管理，讓集羣巡檢變得輕鬆高效，不再需要在多套工具和監控之間不斷切換。通過 TiEM 的管理平臺，除了方便的統一界面進行多集羣管理外，也將很大程度避免人爲疏失帶來的災難，而用戶也可以從繁雜易錯的工作中解脫。
PingCAP Clinic 自動診斷服務（預覽版）
和其他數據庫系統一樣，TiDB 本身存在一定的內在的複雜性，問題診斷和解決並不是非常容易的事情。而對於雲環境下，服務提供商更需要面對大量不同用況的用戶，對於集羣的問題定位，診斷，問題解決都提出了全新的挑戰。爲了更好更高效地應對問題診斷，定位和修復，TiDB 必須用不同以往的方式面對。究極而言，我們希望數據庫是可以智能地自調整自修復，但這卻是一個非常宏大的目標。
傳統上，我們依賴具備專家知識的工程師 / DBA 進行分析診斷，但這些知識是否可以通過程序來提供，以方便我們的日常運維管理，甚至這些知識是否可以通過不斷積累我們由不同真實案例而變得更智能更強大？作爲 TiDB 邁向自服務的全新一步，我們希望對於集羣運行情況的分析，風險預警和問題定位是可以作爲智能服務來提供的：在 TiDB 6.0 發佈的同時，新版本也引入了智能診斷服務 PingCAP Clinic 的預覽版。PingCAP Clinic 從全生命週期確保集羣穩定運行，預測並降低問題出現概率，快速定位並修復問題，加速問題解決效率。它集成了診斷數據採集、智能診斷、智能巡檢、雲診斷平臺等功能，這些功能將逐步向用戶開放。
PingCAP Clinic 通過訪問（經過用戶允許）信息採集組件獲取各類故障信息，在對各種問題進行排查的同時也不斷增強自身的能力。PingCAP Clinic 將受益於我們面對的數千個場景迥異的用戶所提供的各類集羣運行數據。我們會不斷將從問題中抽象出的規則固化到智能診斷中，並通過在線/離線升級的方式分發給 TiDB 用戶，這使得用戶在使用 TiDB 的同時也不斷獲得整個 TiDB 社區的積累。可以預見到的是，當 TiDB 獲得更多雲端客戶時，PingCAP Clinic 也將更容易不斷「學習」來提高自己。作爲一個宏大目標的起點，我們歡迎大家的關注和討論。關於更多 PingCAP Clinic 的信息，請閱讀官方文檔，並關注後續進展發佈。
面向非專家的可觀測性
作爲可管理性的一個重要組成部分，可觀測性是TiDB 一直以來都在不斷加強可觀測性。除了其他分佈式系統都具備的基本監控和指標，從 4.0 起，TiDB 已陸續發佈了諸如 Key Visualizer，SQL 統計和慢查詢展示，監控關係圖，持續 Profiling 等分佈式數據庫專有的功能，這些都是對 TiDB 的可觀測性很好的補強，能幫助 DBA 和工程師更好地理解自己業務在 TiDB 上的運行情況，以更精準地定位問題和進行系統調優。但這些多多少少是專家向的特性，需要用戶對系統有一定的技術理解。
而從 6.0 開始，我們將引入更多的非專家向可觀測性特性，讓對分佈式數據庫和 TiDB 並不那麼瞭解的用戶也能排查系統問題。Top SQL 的推出是踐行理念的第一步。
Top SQL 是一個面向運維人員及應用開發者的一體化、自助的數據庫性能觀測和診斷功能。與現有 TiDB Dashboard 中各個面向數據庫專家的診斷功能不同的是，Top SQL 完全面向非專家：你不需要觀察幾千張監控圖表尋找相關性，也不需要理解諸如 Raft Snapshot、RocksDB、MVCC、TSO 等 TiDB 內部機制，僅需要知道常見數據庫概念，如索引、鎖衝突、執行計劃等，即可開始使用它來快速分析數據庫負載情況，並提升應用程序的性能。Top SQL 以用戶自助使用、判斷分析的方式，與 PingCAP Clinic 自動化規則一起，共同爲用戶提供從常見到複雜罕見的不同性能場景的覆蓋方案。
Top SQL 無需額外配置，在 TiDB 6.0 版本中開箱即用，集成於 TiDB Dashboard 圖形化界面，且不影響數據庫現有應用程序性能。當前版本 Top SQL 率先提供各個節點 30 天的 CPU 負載情況，你可以直觀瞭解各節點的高 CPU 負載是來自於哪些 SQL 語句，從而快速分析諸如數據庫熱點、突發的負載升高等場景。在未來版本中我們還將持續迭代改進 Top SQL，重組整合流量可視化、慢查詢、鎖視圖等現有的專家功能到 Top SQL 中，以一體化的、面向非專家的功能形式，幫助運維人員及應用開發者更簡單、更全面地分析數據庫性能問題。
更成熟的 HTAP 能力
TiDB 5.0 是其分析引擎架構初步成型的版本，這個版本中我們引入了 MPP 執行模式，從而得以服務於更廣的用戶場景。這一年來 TiDB HTAP 也經受了嚴苛的考驗，無論是雙十一場景下數十萬 TPS 寫入合併數十張實時報表中高頻刷新，交易分析混合下優化器自動路由完成的高併發數據服務，這些用例都成爲 TiDB HTAP 不斷成熟的依託。相較 TiDB 5.0，最新版本中分析引擎 TiFlash 擁有了：
- 更多算子和函數支持：相較 5.0，TiDB 分析引擎新增加了 110 多個常用內建函數以及若干表關聯算子。這將使得更多計算能享受 TiDB 分析引擎的加速帶來的數量級性能提升。
- 更優的線程模型：在 MPP 模式下，以往 TiDB 對於線程資源是相對無節制的。這樣實現的後果是，當系統需要處理較高併發的短查詢時，由於過多的線程創建和銷燬帶來的開銷，系統無法將 CPU 資源用滿，從而帶來大量資源浪費。另外，當進行復雜計算的時候，MPP 引擎也會佔用過多線程，帶來性能和穩定性的雙重問題。針對這個問題，最新版中引入了全新的彈性線程池，並對算子持有線程的方式進行了較大重構，這使得 TiDB MPP 模式下的資源佔用更爲合理，在短查詢下達到同等計算資源倍增的計算性能，且在高壓力查詢時穩定性更佳。
- 更高效的列存引擎：通過調整存儲引擎底層文件結構和 IO 模型，優化了訪問不同節點上副本和文件區塊的計劃，優化了寫放大以及普遍的代碼效率。經客戶實景驗證，在極高讀寫混合負載下提升超過 50%～100% 以上併發能力，同等負載下大幅度降低 CPU / 內存資源使用率。
強化的容災能力
除了可管理性之外，作爲數據容災的關鍵組件，TiCDC 也迎來了核心能力增強：通過對整個處理增量數據處理過程的優化、控制拉取事務日誌速度等方式，TiCDC 在大規模集羣數據容災方面的能力有了長足的進步。
TiCDC 對於增量數據的提取、排序、加載、投遞等多個處理流程都進行了優化，降低在處理每一張表的增量數據時所需要使用的 CPU、內存量、減少進程間的通信次數。 這極大地提升了 TiCDC 在大規模集羣下同步數據的穩定性、並降低了資源消耗和數據延遲。 真實用戶場景測試顯示， 6.0 版本的 TiCDC 可以在上游集羣的規模達到 100K 張表、集羣每秒鐘數據改變行數低於 20 K/s、數據改變量低於 20 MB/s 的情況下，確保 99.9% 的數據延遲時間低於 10 秒鐘， RTO < 5 分鐘，RPO < 10 分鐘。就整體而言，在上游集羣 TiDB 集羣節點進行計劃內升級或者停機的場景中，可以將延遲控制在 1 分鐘之內。
另外，爲了降低數據複製過程中對上游集羣的性能影響，保證數據複製過程中業務無感知， TiCDC 增加了對於主集羣事務日誌掃描的限流功能。在絕大多數情況下，確保TiCDC 對於上游集羣的 QPS、 SQL 語句平均響應時間的影響不超過 5%。
面向企業級版本的錨定
隨着對版本發佈的節奏把控不斷成熟，隨着 TiDB 6.0 發佈，針對企業級用戶的穩定性要求，我們也再次進行發版模型調整。從 6.0 版本開始，在 2 個月爲週期內的版本迭代基礎上，TiDB 發版策略將引入半年爲發佈週期的 LTS（Long Term Support）版本，同時爲用戶提供只包含修復的長期穩定版和快速迭代版以兼顧不同傾向的版本需求。其中 LTS 版本面向不需求最新功能，但希望不斷收到問題修復的用戶，生命週期爲 2 年；而非 LTS 版本則擁有更高的迭代速度，只維護 2 個月，面向對最新功能有需求且穩定性需求不高的非生產場合。規劃中的 TiDB 6.1 將作爲第一個 LTS 版本發佈。
展望
由於雲數據庫並不強調版本，因此在前文中我們沒有對 TiDB Cloud 進行過多贅述。但是可以看到，6.0 版本不但是 TiDB 邁向企業級 HTAP 數據庫的又一個全新版本，也是 TiDB 向雲數據庫進發的新起點。諸如可管理性主題，數據放置框架，Clinic 自動診斷兼顧了私有部署的使用，但實際上它們都將在雲端形態下擁有更大的潛力。
雲原生數據庫是一個很有趣的話題。我們對雲數據庫的認識隨着持續的摸索在不斷提升中，從在雲上可運行的數據庫，到藉助雲基礎設施實現的數據庫，再到在雲上可自運維數據庫，6.0 版本是我們踐行這個理念的重要一步。試想，結合良好的可管理性，當雲數據庫服務爲成千上萬用戶提供支持的同時，也可以採集到遠超於現在的非敏感的集羣運行數據，這些數據將作爲數據庫自運維自服務的基礎信息，不斷學習不斷進化，在用戶體驗提升的前提下也解放服務後端團隊更多的資源，集中精力更好地提供用戶所需的產品，這將帶來私有部署形態無法替代的優勢。
而在後續的版本規劃中，我們將嘗試通過藉助雲存儲服務和資源按需啓停等技術，爲用戶提供超越以往形態的使用體驗。藉助開源的力量，讓用戶覺得雲服務相比免費使用私有部署更值得，轉化爲我們新的推力，是我們和整個整個社區雙贏的共同目標。
查看 TiDB 6.0.0 Release Notes，立即下載試用，開啓 TiDB 6.0.0 企業級雲數據庫之旅。