爲啥 TiFlash 又變快了？

TiFlash 這個項目的核心思路與和 TiDB 同樣：持續聽取用戶反饋、持續改進、持續優化、高速迭代。最近幾周陸續有數十家用戶已經率先體驗了 TiFlash，測試的過程當中不少同窗注意到一個現象，短短几周時間，每次 TiFlash 的版本更新都會帶來新的性能的改進，速度愈來愈快，也會問到 TiFlash 愈來愈快的原理，因此就有了這篇深度解析。

TiFlash 加速之謎

TiFlash 誠然本質是依靠列存加速，但它也藉助了 ClickHouse 計算層的優異實現，所以它也不只僅是列存。TiFlash 與 TiKV 同樣，擁有協處理機制。簡單來講，協處理器就是替 TiDB 分擔計算的機制。下面咱們看下這個例子：

SELECT COUNT(*) FROM LINEORDER;

看這樣一個簡單的 count 計算的執行計劃，其中 operator info 欄目中 count(1) 的被標記爲 cop[tiflash]，這表示 TiFlash 將會執行 Hash 聚合計算 count(1)，而實際須要返回給 TiDB 的數據，僅僅是聚合完以後的結果，在大多數場景下，返回的數據將會很是少。這種協處理器機制，將會由各個 TiFlash 按照 Region（數據分片）爲單位分佈式執行。因爲 TiFlash 配備了優異的計算模塊，所以這部分下推優化是 TiFlash 加速的關鍵因素之一。

這裏就有一個關鍵因素：並非全部計算均可以徹底下推到 TiFlash 進行加速。

哪些計算沒法加速？

若是有函數在 TiFlash 沒有實現，那麼它將阻礙計算加速。

讓咱們看下這樣一個查詢：

SELECT COUNT(*) FROM LINEORDER WHERE DATE_FORMAT(LO_ORDERDATE, 「%Y」) >= ‘1998’;

上面的執行計劃中，TiFlash 只承擔 TableFullScan 也就是掃表部分，而 count(1) 卻並無在 TiFlash 中執行。這是爲什麼？其實緣由也很簡單：由於暫時 date_format 函數在 TiFlash 中並無實現，所以從謂詞過濾以及全部以後的計算都將沒法加速。這也許會帶來幾倍甚至十幾倍的速度差距。
因此遇到這樣的狀況該怎麼辦？你能夠很簡單改寫爲：

SELECT COUNT(*) FROM LINEORDER WHERE LO_ORDERDATE >= ‘1998-01-01’;

改完這個查詢從將近 5 分鐘加速到 1.61 秒。

不過這並非咱們在這裏但願你默默忍受的。咱們但願你告訴聯繫咱們，告訴咱們這裏下推不知道爲何不工做了，咱們會幫你分析，若是有缺漏的下推，咱們會迅速補上。

Super Batch 優化

有用戶反映，當 Region 數量很是多的時候，TiFlash 的加速會放緩。這是因爲當 Region 過多時，TiDB 會產生數量大量的 Region 讀取請求，而形成調度延遲放大。這個效果有些相似 Hadoop 上小文件過多而形成的性能影響。咱們以前給出的建議是，打開 Region Merge，並在可能的狀況下將 Region 大小調至 192M 而非默認的 96M。但就算這樣，仍然可能有超大表包含數千甚至上萬 Region 數讓性能降低。

對於這樣的問題，近期咱們推出了 Super Batch 優化，當開啓優化時，TiDB 將會把全部須要發送到同一個 TiFlash 的請求合併，而 TiFlash 則會在內部自行進行 Raft 相關的讀取容錯。

經過這樣的方式，TiFlash 再也不對 Region 大小敏感。以下是 ontime 數據集的測試對比。

如上測試結果能夠看出，多數查詢有接近一倍的提速，而這只是在較小數據量下（10 億規模之內）的結果，若是數據量進一步增長，加速效果將更爲顯著。

JOIN 加速

有一些測試的朋友告訴咱們，他的分析計算是星型模型，有很多 JOIN，執行起來彷佛沒有變多快。是的，以協處理器的模型，對 JOIN 類計算並不能很好加速，由於 JOIN 沒法在這個框架下分擔計算，進而都必須由 TiDB Server 獨立承擔。因爲 TiDB Server 計算單元目前並非分佈式設計，所以只能由單機慢慢算了。

那是否這樣的場景就沒法優化了呢？

只要有足夠多的的用戶呼聲，咱們就會開動腦筋 :)

通過一番努力，如今 TiFlash 實現了針對星型模型 JOIN 的優化方案：類 Broadcast JOIN。

經過將小表 Build Hash 動做在 TiFlash 中實現，咱們得以將整個 JOIN 操做下推並分佈式化，這個優化不止讓 JOIN 自己得以在 TiFlash 中分佈式計算，並且也讓後續操做例如聚合等，均可以完整下推到 TiFlash。

而這個優化的加速效果也至關明顯。咱們針對標準的 Star Schema Benchmark 進行了測試，結果以下。

總共 13 條 SQL，你們能夠在 這裏 找到。大部分查詢都有明顯加速，其中 6 個甚至有數量級（最多 44 倍）的加速。

相信在完整的 MPP 實現以前，這樣的設計也能夠知足不少用戶的需求。而有些場景用不上這個優化，好比大量的大表 JOIN，則能夠直接用 TiSpark。

更多溝通，更多加速

上述各個優化，都是由用戶反饋而作出的針對性優化。咱們也會不斷快速迭代，快速演進。可是這一切的前提都是， 你的使用和反饋。與咱們聯繫，嘗試 TiFlash，在解決你問題的同時，也能與咱們一塊兒打造真正符合你們需求的產品，畢竟，TiDB 是一個以社區爲本的產品。社區的前進，離不開每一個用戶。

歡迎體驗

TiDB 4.0 可使用全新的 TiUP 進行部署。你們可使用兩條命令單機部署體驗或者參考 官網文檔 部署集羣。

curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh 
tiup playgroud

注：部分上述優化還未包含在 4.0 RC，請與咱們聯繫參與體驗。另，TiFlash 部署暫時只支持 Linux 環境。

上週直播咱們演示了 Real-time HTAP 概念是如何在 TiDB 4.0 中成爲現實的。本週讓咱們看看 Serverless 在 TiDB 4.0 是怎麼被實現的？此次直播的主題是模擬線上不可預測的流量，嘗試各類手段驗證 TiDB 4.0 的上限在哪裏。一樣的負載在 MySQL 中的表現又會如何呢？

嘉賓：黃東旭，PingCAP 聯合創始人兼 CTO & 唐劉，PingCAP 首席架構師