批處理 TiKV 子任務(wù)（GA）

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

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

基于負(fù)載的副本讀?。℅A）

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

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

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

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

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

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

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

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

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

有關(guān)用法和注意事項(xiàng)的更多詳細(xì)信息，請(qǐ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 中作為一個(gè)實(shí)驗(yàn)特性進(jìn)行了介紹，而在 7.1 中這個(gè)特性 GA 了。此外在新版本中，TiDB 節(jié)點(diǎn)可以共享 TTL 相關(guān)任務(wù)并并發(fā)執(zhí)行，從而擁有了更好的性能和資源利用率。

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

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

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

2.2.4 Multi-RocksDB 存儲(chǔ)引擎帶來(lái)巨大性能提升

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

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

● 減少 RocksDB 對(duì)應(yīng)的 LSM 負(fù)擔(dān)，增加了吞吐量，測(cè)試結(jié)果顯示寫(xiě)入吞吐量 增加了 200% 。

● 使用不同 RocksDB 也會(huì) 減少 Compaction 帶來(lái)的寫(xiě)放大，降低資源消耗。

● 更好的寫(xiě)入吞吐使集群的擴(kuò)展 速度提高 500% 。

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

● 更小的單位存儲(chǔ)消耗，使得集群可擴(kuò)展性進(jìn)一步增強(qiáng)。

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

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

2.2.5 Online DDL 的大幅提升（實(shí)驗(yàn)特性）

在 TiDB 7.1 中，類似于前述 TTL 改進(jìn)，PingCAP 引入了跨 TiDB 節(jié)點(diǎn)分配 DDL 作業(yè)的框架，以進(jìn)一步提高性能。

更多 TiDB 7.1 版本新功能，請(qǐng)查閱 TiDB 官網(wǎng) Release Notes ， 立即 下載試用 ，開(kāi)啟 TiDB 體驗(yàn)之旅。

崔歡歡