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

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

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

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

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

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

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

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

TiDB 7.1 提升了 TiDB 讀、寫以及管理操作的性能,以提供更好的用戶體驗(yàn)。新版本中,TiDB 增加了多值索引以提供對 JSON 的查詢效率。此外,在寫入吞吐、分析查詢速度和后臺任務(wù)效率方面也進(jìn)行了大量的改進(jìn)和優(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)建多值索引來定位特定郵政編碼存在于哪一行。

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

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

2.2.3 延遲物化加速分析查詢(GA)

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

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

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

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

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

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

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

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

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

● 更小的單位存儲消耗,使得集群可擴(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 將宣布這個特性 GA。

有關(guān)更多詳細(xì)信息,請參閱產(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 版本新功能,請查閱 TiDB 官網(wǎng) Release Notes , 立即 下載試用 ,開啟 TiDB 體驗(yàn)之旅。

分享到

崔歡歡

相關(guān)推薦