概覽
我們很高興為大家帶來 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 開源 也實現了，歡迎廣大社群開發者一起參與。
適用於中國出海企業和開發者
全面加強可管理性
可管理性是資料庫的一個重要能力維度：在滿足業務需求的前提下，是否靈活易用，將決定了使用者技術選擇背後的隱性成本。這種成本可大可小，可以是一句抱怨，也可能會結合人因帶來災難性後果。在最新版本研發過程中，我們結合了客戶和市場反饋，總結了當前的可管理性的問題仍存在的缺失，這包含了「複雜且不直觀的叢集的日常管理」、「無法控制資料的儲存位置」、「資料生態套件難於使用」、「面對熱點缺少解決方案」等多個維度，而 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 企業級雲資料庫之旅。