為啥 TiFlash 又變快了？

TiFlash 這個項目的核心思路與和 TiDB 一樣：持續聽取用戶反饋、持續改進、持續優化、高速迭代。最近幾周陸續有數十家用戶已經率先體驗了 TiFlash，測試的過程中很多同學注意到一個現象，

TiFlash 加速之謎

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

<code>SELECT COUNT(*) FROM LINEORDER;/<code>

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

這裡就有一個關鍵因素：並不是所有計算都可以完全下推到 TiFlash 進行加速。

哪些計算無法加速？

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

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

<code>SELECT COUNT(*) FROM LINEORDER WHERE DATE_FORMAT(LO_ORDERDATE, “%Y”) >= ‘1998’;/<code>

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

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

改完這個查詢從將近 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 進行部署。大家可以使用兩條命令單機部署體驗或者參考 官網文檔 部署集群。

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

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

閱讀更多 PingCAP 的文章

關鍵字: Hadoop 分佈式計算 設計