近日，企業級開源分布式數據庫廠商 PingCAP 正式發布TiDB 7.0 。TiDB 7.0 聚焦于幫助用戶通過可靠性能和簡化數據庫操作來快速響應業務需求，從而滿足客戶的高期望值，并提升開發人員和 IT 運維人員的生產力。新版本中，TiDB 在可擴展性與性能、穩定性與高可用、SQL 以及 可觀測性幾個領域獲得持續提升，累計引入新特性 20 余項，優化功能 50 余項。TiDB 7.0 是 TiDB 7 系列首個 DMR 版本，適用于開發、測試和 PoC 等場景。

在 7 系列版本以及之后 2-3 年的時間里， TiDB 在不斷迭代中將擁有：

(資料圖片僅供參考)

更強的基礎能力（核心性能，擴展性，性價比，云原生等）；更加多元化的場景支持（多租戶，更多數據模型支持，更好的生態適配）；更順滑的運維體驗（更強的 DDL 能力，以 SQL 為統一界面的運維體驗等，智能運維）；更可靠更安全（更高的可用性，更好的安全體系整合，更多合規認證）。這些主題都將逐步在 7 系列以及后續版本中落實，給予用戶更優的使用體驗，讓 TiDB 變成一個好用且泛用，可靠且經濟的選擇。具體到 7.0 版本，TiDB 初步提供了更好的資源管控能力，讓 TiDB 針對 SaaS 和多平臺統一共存等場景有了根本性的解決方案；其次，TiFlash 發布了面向云的存算分離新架構，這使其可以真正做到存算資源解耦，計算資源可以按需啟停，且基于 S3 的存儲設計也將大幅降低存儲成本；而諸如分析引擎支持落盤，自動執行計劃緩存等，則是針對企業級場景做出的必要強化；最后，TiDB 7.0 提供了對 MySQL 8.0 的兼容，這將使得相關用戶能更方便地遷移到 TiDB。

1、資源管控增強多租戶形態下工作負載穩定性

資源管控特性（Resource Control）在 TiDB 6.6 中引入（實驗特性），在 TiDB 7.0 中得到增強和優化，極大地提升 TiDB 集群的資源利用效率和性能表現，為穩定的多租戶奠定了基礎。資源管控特性對 TiDB 具有里程碑的意義，用戶可以將一個分布式數據庫集群劃分成多個邏輯單元，將不同的數據庫用戶映射到對應的資源組中，并根據需要設置每個資源組的配額。該功能允許為一個或多個會話組設置資源上限，如果來自某個工作負載或應用程序的消耗異常重，則其資源消耗將被限制在配額內，以防止對其他更關鍵的工作負載造成干擾。

資源管控適用于以下場景：

用戶可以將多個應用程序合并到單個 TiDB 集群中，降低 TCO 并保證重要工作負載所需的資源。用戶可以在業務運營時間內安全運行批處理任務。模擬環境（Staging Environments）可共享具有受資源管控限制的單個 TiDB 集群。

會話可通過三種方式綁定到資源組： 通過 CREATE USER 或 ALTER USER 語句將用戶綁定到特定的資源組，使得用戶會話始終受到設定邊界約束； 通過 SET RESOURCE GROUP 設置當前會話的資源組； 也可通過優化器 Hint RESOURCE_GROUP() 設置當前語句的資源組。

2、TiFlash 支持數據落盤來穩定分析工作負載

TiFlash 是 TiDB 的列存儲和計算引擎，是數據庫分析工作負載能力的支柱。在 TiDB 7.0 之前，TiFlash 在內存中處理所有數據。從這個版本開始，TiFlash 支持數據落盤功能（Spill to disk），通過調整算子內存使用閾值，控制對應算子的最大內存使用量。對于大查詢而言，當算子使用內存超過一定閾值時會自動將數據落盤，犧牲一定的性能換取整體分析查詢的穩定性。數據落盤操作根據用戶配置參數進行，并適用于單個推送下去的操作。由于該優化發生在單個運算符級別上，因此必須在多個位置執行數據落盤操作。在 TiDB 7.0 中，它首先被應用于以下情況：

相等條件下的哈希連接；GROUP BYs 上的哈希聚合；窗口函數中 TopN 和排序運算符。

在執行這些操作期間，如果運算符使用的內存量超過了配置限制，會自動將數據落盤并繼續進行后續處理。為了說明目標工作負載受影響程度，我們模擬了決策支持系統，使用 TPC-H 基準測試工具進行測試，結果如下表所示：

3、自動計劃緩存減少查詢延遲

在此之前，TiDB 已經支持使用 PREPARE 準備語句來進行計劃緩存。TiDB 7.0 中，非 Prepare 語句的執行計劃也能夠被緩存，使執行計劃緩存能夠應用于更廣泛的場景。該功能支持在會話級別上對查詢進行緩存，全局級別的支持將在未來發布中推出。會話級別的緩存將減少由于查找正確計劃而導致的延遲，但可能也會增加全局緩存中可能存在重復數據時所需內存。目前可以通過此功能進行單表過濾和范圍查詢類型的查詢進行緩存，但不能夠處理單表復雜查詢和 JOIN 查詢等其他類型。

4、TiFlash 支持存算分離架構，降低數據分析成本

在 TiDB 7.0 版本，TiFlash 支持存算分離和 S3 對象存儲（實驗特性）。之前版本的 TiFlash 是存算一體架構，TiFlash 節點既是存儲節點，也是計算節點，其計算和存儲能力擴展受到一定限制。同時，TiFlash 節點只能使用本地存儲。在 7.0 版本中，TiFlash 支持存算分離架構，分為 Write Node 和 Compute Node 兩種節點，可以分別部署，單獨按需擴展，并支持將數據存儲在 Amazon S3 或兼容 S3 API 的對象存儲中。

圖：TiFlash 存算分離架構

TiFlash 存算分離架構 適用于高性價比的數據分析場景。 在數據量很大，但是只有少量數據被頻繁查詢，大部分冷數據很少被查詢的場景下，將經常被查詢的數據緩存在 Compute Node 的本地 SSD 上，可以提供較快查詢性能，將大量冷數據存儲在成本較低的 S3 或者其他對象存儲上，從而節省存儲成本。 在計算資源需求有明顯的波峰和波谷場景下，例如晚上執行的重型對賬查詢，對計算資源要求較高，可以臨時擴展 Compute Node，其他時間可以用較少的 Compute Node 完成查詢任務。 TiFlash 的存算分離架構大幅降低了使用 TiFlash 支持分析工作負載的成本，并且提供了一定程度的工作負載隔離。 目前，TiUP 和 TiDB Operator 已經支持部署和縮放 TiFlash 獨立組件的能力。

5、TTL 定期刪除過期數據，為系統減負

TiDB 6.5 引入了 Time to live（TTL）實驗特性，提供了行級別的生命周期控制策略，該項特性在 TiDB 7.0 中正式 GA。TTL 是一種通過 SQL 配置設置表中行到期時間的方式，幫助用戶周期性且及時地清理不需要的數據，并盡量減少對用戶負載的影響。TTL 以表為單位，并發地分發不同的任務到不同的 TiDB Server 節點上，進行并行刪除處理。在某些情況下，較大的表格意味著查詢時間更長；較大的表格意味著更多的存儲成本；在 TiDB 中，一個表越大，Region 就越多，限制表格大小可以減輕系統負擔；各種合規性要求可能需要設置數據過期。基于成本、性能或安全等因素考慮，數據庫管理員可以配置自動檢查并刪除過期的表格行數據，例如定期刪除驗證碼、短網址記錄、不需要的歷史訂單、計算的中間結果等。

6、使用 Key 分區提高可擴展性

在 7.0 之前，TiDB 支持 Hash、Range 和 List 分區。新版本引入了 key 分區，與 Hash 分區類似，Key 分區可以保證將數據均勻地分散到一定數量的分區里面。Hash 分區只能根據一個指定的整數表達式或字段進行分區，而 Key 分區可以根據字段列表進行分區，且 Key 分區的分區字段不局限于整數類型。Key 分區提供了一種更靈活的方式來對數據集進行劃分以改善集群的可擴展性。

7、使用 Reorganize Partition 適應不斷變化的需求

TiDB 長期以來一直支持分區，修改分區表的唯一方法是添加或刪除分區和截斷 LIST/RANGE 分區。TiDB 7.0 TiDB 支持 ALTER TABLE... REORGANIZE PARTITION 語法，用戶可以對表的部分或所有分區進行重新組織，包括合并、拆分、或者其他修改，并且不丟失數據，增加了可用性和靈活性以滿足不斷變化的需求。

8、使用 Load Data 從遠程存儲導入數據

TiDB 7.0 中， LOAD DATA 語句集成 TiDB Lightning，用戶可以使用 LOAD DATA 語句完成原先需要使用 TiDB Lightning 才能完成的數據導入任務（實驗特性），不僅可以省去 TiDB Lightning 的部署和管理成本，還可以借助 TiDB Lightning 的功能極大擴展 LOAD DATA 語句的能力，包括：支持從 Amazon S3 和 Google Cloud Storage 導入數據到 TiDB，且支持使用通配符一次性匹配多個源文件導入到 TiDB；支持查詢任務狀態，添加操作便利性等。

關鍵詞：