TiDB 7.1 LTS 發(fā)版：為關鍵業(yè)務提供業(yè)務穩(wěn)定性和多租戶場景支持天天熱消息

2023-06-08 16:50:30來源：中關村在線

近日，企業(yè)級開源分布式數(shù)據(jù)庫廠商 PingCAP 正式發(fā)布 TiDB 7.1 版本，這也是 2023 年度發(fā)布的首個 LTS（Long Term Support）版本，匯集了來自 20+ 個真實場景帶來的功能增強，累計優(yōu)化和修復 140+ 功能，旨在提升關鍵業(yè)務的穩(wěn)定性和性能，幫助開發(fā)人員和數(shù)據(jù)庫管理員提高生產(chǎn)力并進一步降低總體擁有成本（TCO）。用戶可在生產(chǎn)環(huán)境中使用 TiDB 7.1。

(資料圖)

TiDB 半年版本回顧

TiDB 7.1 LTS 距離上一個 LTS 版本 6.5 已經(jīng)過去了整半年，在這期間，PingCAP 對產(chǎn)品的關鍵能力做了大量的增強和優(yōu)化，其中最重要的特性有：

● TiDB 7.0 提供了基于資源組的資源管控（Resource Control） ：這使得 TiDB 在針對多租戶場景有了很好的應對。事實上，經(jīng)常有用戶希望借助 TiDB 的可伸縮特性將多套業(yè)務系統(tǒng)歸一到一個集群中，從而使得集群管理、資源利用都能得到有效的改進。資源管控特性提供了對多租戶的支持，并解決了不同租戶間資源爭搶的問題。在新版本中，用戶可以很方便地借助這個功能完善數(shù)據(jù)庫整合的使用場景。

● Multi-RocksDB 特性 ：借助將單一 TiKV 實例中的 RocksDB 拆成多份，TiKV 的寫吞吐提升近三倍；此外，在新架構(gòu)中數(shù)據(jù)分片（Region）大小將變得更大，由此減小維護分片所帶來的開銷，減少單位存儲所需的固定 CPU 消耗，更節(jié)省成本。這使得大寫入吞吐，或者需要大量存放溫數(shù)據(jù)的 Data Serving 場景下，TiDB 的表現(xiàn)得到了本質(zhì)的提升。

對于這些重要的重量級特性，在新版本中也將持續(xù)得到打磨和加強。這半年中，TiDB 在一些關鍵場景的性能也得到長足提升：

● 數(shù)據(jù)導入 Lightning 性能提升近 30% ；

● 真實業(yè)務測試下，Analyze Table 性能提升 42%+ ；

● 標準測試 TPC-H 和真實業(yè)務測試下，TiDB 分析能力分別提升 15% 和 25% ；

● TiCDC 針對大型單表復制性能提升可達 90%+ 。

TiDB 7.1 功能特性

TiDB 7.1 是PingCAP 計劃在 2023 年發(fā)布的兩個長期可支持（LTS）版本中的第一個，它提供了一個面向未來的數(shù)據(jù)庫，可以為各種關鍵業(yè)務應用程序提供動力。TiDB 7.1 將為用戶帶來以下特性：

● 更穩(wěn)定地支持關鍵業(yè)務負載 ，為 DBA 提供多工作負載穩(wěn)定性控制，并顯著改善尾部延遲；

● 以更少的資源提供更佳的性能 ，通過架構(gòu)增強實現(xiàn)更高的吞吐以及更快的在線 DDL。

此外，TiDB 7.1 企業(yè)版增強了數(shù)據(jù)庫審計功能，通過更細粒度的事件過濾控制、更友好的過濾條件設置方式、新增的 JSON 文件輸出格式以及審計日志的生命周期管理，大幅提升系統(tǒng)的審計能力。

2.1 更穩(wěn)定地支持關鍵業(yè)務負載

2.1.1 通過資源組改進資源管控的用戶體驗，提供更好的隔離性

PingCAP 在 TiDB 7.0 中增加了通過資源組進行資源管控的功能，為 TiDB database consolidation （數(shù)據(jù)庫整合）方案奠定了基礎，具有里程碑的意義。多個業(yè)務可共享同一個 TiDB 集群，DBA 可為不同的工作負載設置資源配額和優(yōu)先級，例如為關鍵業(yè)務分配更高的優(yōu)先級，確保其能夠優(yōu)先獲得資源，避免受到其他工作負載的干擾。

在 TiDB 7.1 中，資源管控特性正式 GA 了，并加入了兩個特性增強：

● 降低了在重寫入密集型工作負載中出現(xiàn)的尾延遲：資源組通過資源配額和優(yōu)先級控制工作負載。優(yōu)先級由存儲級別控制。當工作負載寫入繁重時，基于優(yōu)先級重新調(diào)度機制有時會造成更高的尾延遲（Tail Latency）。在 7.1 版本中，尾延遲被修正到預期水準。

● 增加原生負載校準工具，幫助用戶設置更準確的資源資源分配：資源分配的基礎是用戶對負載的資源使用量有所了解。新增的校準工具將很好的幫助您評估相關信息，以合理配置資源組。最快的方法是從 SQL 接口運行校準命令來估計基準測試（如 TPC-C 和 sysbench）的資源使用情況。

2.1.2 多個熱點場景下性能和穩(wěn)定性提升

對 TiDB 的底層行存儲 TiKV 有三個關鍵增強，以降低延遲提升穩(wěn)定性（通過 p99 延遲衡量）。新版本引入了三項優(yōu)化，分別針對三個級別熱點進行處理：Key 級別、分片（Region）級別和節(jié)點級別：

● Key 級熱點：鎖沖突優(yōu)化

● Region 級熱點：TiKV 子任務的批處理化

● 節(jié)點級熱點：引入了基于負載的副本讀取

鎖沖突優(yōu)化（GA）

TiDB 引入了處理 Key 級熱點的優(yōu)化。在遇到許多單點悲觀鎖沖突的負載中，喚醒等待請求的算法在新版本中將表現(xiàn)得更穩(wěn)定，最大限度地減少了重試的資源浪費，從而節(jié)省了整個集群的資源并降低了尾延遲。測試表明，當啟用鎖沖突優(yōu)化時，如果吞吐量相對較小，即使在沖突最嚴重的工作負載中，新版本的尾延遲也將降低 40-60%。

批處理 TiKV 子任務（GA）

選擇性較差的查詢可能會導致需要讀取許多數(shù)據(jù)。在 TiDB 的分布式存算分離架構(gòu)中，這樣的查詢可能會帶來數(shù)萬或數(shù)十萬個 RPC 請求用于獲取數(shù)據(jù)，如果使用索引讀取則將更進一步加重這一負擔。

TiDB 服務器作為 TiKV 客戶端，現(xiàn)在可以識別針對同一分片的批處理任務，并將這些批量發(fā)送到對應的存儲節(jié)點。這大大減少了網(wǎng)絡的 RPC 開銷，使得這些查詢更穩(wěn)定。這個增強可以將相應場景中的延遲減少多達 50%。

基于負載的副本讀取（GA）

這個特性用于優(yōu)化節(jié)點級讀熱點。當大批量查詢以不均勻的方式發(fā)起讀取，可能會出現(xiàn)節(jié)點熱點。注入 Index Lookup JOIN 這類常見的事情都可能會導致這種情況。一旦發(fā)生，讀取請求會排隊，當隊列塞滿時，一些請求可能會等待相當長時間。PingCAP 希望通過更均勻地分配工作來減少延遲。

新版本中，TiDB 引入了基于負載的副本讀取來實現(xiàn)這一點。它為隊列提供了一個可配置的持續(xù)時間閾值，當超過該閾值時，它會告訴 TiDB 開始優(yōu)先考慮副本讀取。在讀熱點的情況下，與不打散讀熱點相比，該功能可提高讀取吞吐量 70%～200%。

有關此優(yōu)化的更多信息，請參閱文檔 ( https://docs.pingcap.com/tidb/dev/troubleshoot-hot-spot-issues#scatter-read-hotspots )。

2.2 更少的資源，更佳的性能

TiDB 7.1 提升了 TiDB 讀、寫以及管理操作的性能，以提供更好的用戶體驗。新版本中，TiDB 增加了多值索引以提供對 JSON 的查詢效率。此外，在寫入吞吐、分析查詢速度和后臺任務效率方面也進行了大量的改進和優(yōu)化。

2.2.1 多值索引（GA）以增加速度和靈活性

多值索引也稱為“JSON 索引”，這種新型輔助索引在 TiDB 6.6 中引入并在 7.1 中 GA。多值索引支持索引記錄到數(shù)據(jù)記錄的 N:1 映射，使得查詢可以快速檢查存儲在 JSON 數(shù)組中的特定值。

無論該數(shù)據(jù)存儲為 blob，還是郵政編碼直接存儲為 zip 數(shù)組，用戶都可以創(chuàng)建多值索引來定位特定郵政編碼存在于哪一行。

索引是使用表達式創(chuàng)建的，該表達式將 JSON 數(shù)據(jù)邏輯解析為生成列（Generated Column）和該列上的二級索引。如果用戶將 JSON 存儲為 blob，并且需要支持遍歷多層嵌套的查詢，只需創(chuàng)建一個索引以檢索。

有關用法和注意事項的更多詳細信息，請參閱多值索引文檔 ( https://docs.pingcap.com/tidb/dev/sql-statement-create-index/#multi-valued-index )。

2.2.2 更快的 TTL（GA）

TTL (Time to live) 在PingCAP 的 TiDB 6.5 中作為一個實驗特性進行了介紹，而在 7.1 中這個特性 GA 了。此外在新版本中，TiDB 節(jié)點可以共享 TTL 相關任務并并發(fā)執(zhí)行，從而擁有了更好的性能和資源利用率。

2.2.3 延遲物化加速分析查詢（GA）

TiFlash 是 TiDB 的列式存儲引擎，在 7.1 版本中延遲物化特性 GA。當表掃描擁有高過濾性的時候，TiDB 優(yōu)化器可選擇讓 TiFlash 啟用延遲物化。開啟該特性后，TiFlash 支持下推部分過濾條件到 TableScan 算子，即先掃描過濾條件相關的列數(shù)據(jù)，過濾得到符合條件的行后，再掃描這些行的其他列數(shù)據(jù)，繼續(xù)后續(xù)計算，從而減少 IO 掃描和數(shù)據(jù)處理的計算量。

此功能的影響取決于實際負載和數(shù)據(jù)分布。在某些情況下，它可以顯著減少延遲（在PingCAP 的測試中延遲最高可降低 70%）。TiDB 的查詢優(yōu)化器可以決定是否使用它，默認情況下打開是安全的。

2.2.4 Multi-RocksDB 存儲引擎帶來巨大性能提升

在 TiDB 6.6 中，PingCAP 引入了對 TiKV 存儲架構(gòu)的重大更改。雖然這個架構(gòu)仍然是實驗性的（默認關閉，并且只能在新集群中啟用），但在這個 LTS 版本中，該特性獲得重大加強，并在預生產(chǎn)環(huán)境中收到了很好的測試反饋。

在 TiDB 6.6 之前，單一 TiKV 節(jié)點所有 Region 共享一個 RockDB 存儲引擎。新架構(gòu)則將不同 Region 分別存放在不同 RocksDB。新架構(gòu)的好處是顯著的：

● 減少 RocksDB 對應的 LSM 負擔，增加了吞吐量，測試結(jié)果顯示寫入吞吐量 增加了 200% 。

● 使用不同 RocksDB 也會減少 Compaction 帶來的寫放大，降低資源消耗。

● 更好的寫入吞吐使集群的擴展 速度提高 500% 。

● 在測試一些真實的客戶工作負載時，PingCAP 觀察到尾部延遲 減少了近 50% 。

● 更小的單位存儲消耗，使得集群可擴展性進一步增強。

在 TiDB 7.1 中，PingCAP 進一步提高了該特性的性能和穩(wěn)定性，并添加了網(wǎng)絡帶寬優(yōu)化。當前仍然缺失的是 TiCDC、BR 等生態(tài)工具的支持，當這些完成后PingCAP 將宣布這個特性 GA。

有關更多詳細信息，請參閱產(chǎn)品文檔 ( https://docs.pingcap.com/tidb/dev/partitioned-raft-kv )。

2.2.5 Online DDL 的大幅提升（實驗特性）