LLVM技術在GaussDB等資料庫中的應用

本文分享自華為雲社區《【GaussTech第3期】LLVM技術在GaussDB等資料庫中的應用》，作者：GaussDB 資料庫。

Hi，別急！

讓技術觸達每一個角落，賦能更多的人，GaussTech第3期《LLVM技術在GaussDB等資料庫中的應用》，不僅帶來滿滿的技術乾貨，還推出【分享集贊回帖贏好禮】活動，參與就能贏好禮，文末見驚喜哦！

萬物互聯的態勢下，數據量的激增使得“如何提升數據處理性能”成為各家資料庫共同面臨的挑戰。作為編譯優化技術的代表，基於LLVM的CodeGen技術，能為每個查詢生成定製的機器碼替代原本的通用函數，減少實際查詢時冗餘的條件邏輯判斷、虛函數調用並提高數據局域性，從而達到提升查詢整體性能的目的，成為資料庫性能優化的一項重要技術。

LLVM能在分析類場景中給用戶帶來較大的收益，也能在特定的交易性場景中給用戶帶來一定的收益。接下來詳細解讀一下LLVM技術在GaussDB等資料庫中的應用吧。

LLVM和資料庫

LLVM（Low Level Virtual Machine）是一款流行的開源編譯器框架，是CodeGen（生成源代碼的工具）技術的事實標準，被廣泛運用於資料庫（如KES, AnalyticDB, GaussDB）、大數據（如Spark）、AI平臺（如tensorflow）等領域，用於提升數據處理的性能。

在沒有引入LLVM這類CodeGen技術之前，資料庫會使用通用的處理邏輯來處理數據。但通用邏輯“笨重”（遞歸、封裝、類型判斷轉換）的代碼實現方式，存在虛函數開銷、緩存使用率低下、對指令集不敏感等性能短板。

引入LLVM之後，可以為具體的查詢生成定製化的機器碼，並儘可能地將數據存儲在CPU的寄存器中進一步加快計算的速度：

• LLVM天然支持JIT，該技術可以解決條件邏輯冗餘的問題；
• 減少大量的虛函數調用；
• 將數據儘可能地從記憶體載入到Cache上；
• LLVM做了很多自動矢量化的工作；

比如，下圖左側是通用代碼，右側是CodeGen之後的代碼。CodeGen根據實際情況消除了不必要的迴圈和判斷。

▲ 圖1 通用性處理邏輯和LLVM代碼示意

另外，LLVM技術可以有不同的實現粒度。比如：可使用LLVM加速表達式計算，或再進一步，將多個運算元融合編譯成定製的機器碼，或將自定義函數、存儲過程等編譯成定製的機器碼。

▲ 圖2 LLVM的實現粒度

資料庫在執行引擎中，運用LLVM技術提升SQL的執行速度。如下圖所示：

▲ 圖3 LLVM技術運用於執行引擎

LLVM適用場景

LLVM對所有類型的SQL都會有收益嗎？

因為執行實時編譯本身需要耗費一定的時間（簡單表達式能做到毫秒級，複雜情況在百毫秒級），對於查詢本身耗時較少的場景，加入LLVM反而會導致性能劣化。

因此，目前LLVM在OLAP/HTAP分析型業務場景中收益較大，有著廣泛應用，而在OLTP交易型業務場景中，則相對沒有那麼廣泛。

LLVM在OLTP中就一定沒有收益嗎？

答案同樣是否定的。

找對場景，一樣有收益。比如根據ISPRAS 2017年發表的實驗結果（jit-compiling sql queries in postgresql using llvm）可知：pgbench測試下，OLTP場景中簡單的查詢加上JIT（Just-in-time及時編譯，LLVM天然支持）擴展沒有帶來性能的提升，甚至將TPS（事務數/秒）從21.8降低到了7.8。

但是在Prepared query（plan cached）的情況下，和簡單的查詢相比，Plancache + CodeGen將TPS從21.8提升到了43，性能上有了約兩倍的提升。

▲ 圖4 簡單查詢、CodeGen流程、Plancache和“Plancache +CodeGen”流程的性能對比

GaussDB中的LLVM

1. LLVM在華為應用於資料庫的時間線

華為資料庫在LLVM上的研究還是非常超前的。早在2015年，華為就作為PostgreSQL全球開發者大會的贊助商，在會上發表的動態編譯（Go Faster with Native Compilation）演講並引起了很大的反響。

當時社區領袖Josh Burkus在其博客裡面，用一節篇幅專門詳細介紹了華為動態編譯的議題。

▲ 圖5 2015年社區領袖Josh Burkus介紹華為的動態編譯議題

在2017年，華為在面向OLAP場景的資料庫內核中突破了LLVM動態編譯技術，併在運營商、金融證券等多個行業的POC項目中幫助客戶提升數據處理性能，同時，在軟體開發過程中充分模塊化、通用化介面設計，將LLVM同年落地到面向OLTP的資料庫設計中。

目前，GaussDB資料庫對於LLVM也在不斷地演進開發。

2. GaussDB LLVM實現簡析

GaussDB針對向量化引擎（主要用於分析場景）、行存（主要用於交易場景）都實現了CodeGen。如下圖所示，從代碼模塊層次來看：

1) GaussDB通過API介面層封裝處理了LLVM環境、資源、基本元素等。

2) GaussDB在CodeGen層調用API介面進行了不同粒度的實現。

3) GaussDB在執行引擎側根據情況使用CodeGen技術進行性能優化。

▲ 圖6 GaussDB LLVM 模塊層次圖

GaussDB啟動後會進行LLVM的初始化工作，檢查CPU對CodeGen的支持情況，併進行環境初始化。

在執行啟動階段，以表達式為例，程式會判斷當前表達式是否可JIT，是的話，則會進行IR函數的生成和生成定製機器碼，及原本表達式執行函數的入口替代工作。

在實際執行過程中，運行處理函數（該函數已經在上一階段進行了入口替代）進行實際執行工作。

在執行結束後的清理階段，釋放LLVM相關資源。

▲ 圖7 GaussDB CodeGen編譯執行流程簡圖

GaussDB使用了閾值codegen_cost_threshold來估算當前查詢使用LLVM技術是否能帶來收益。如果處理數據的規模大於該閾值後，才會繼續使用LLVM技術進行相關處理。該閾值代表行數，也可以理解成處理數據的規模，預設值為100000行，可以調節。

在OLAP場景中，GaussDB在判斷是否能夠對於一個運算元進行CodeGen後（如：數據類型，運算元類型判斷等），開始生成對應的IR bytecode片段，之後MCJIT模塊會調用生成的LLVM Module單元進行執行。

在OLTP場景中，GaussDB則會在Plan Cache場景下結合CodeGen框架，通過緩存機器碼的方式，節省下編譯生成中間語言IR Func以及優化成機器碼的時間，整個過程是非同步的。因此，在大量重覆查詢的場景下，後續的查詢也會因為LLVM技術而受益。

另外，為了避免行數估計錯誤而選擇CodeGen導致性能劣化，GaussDB還研發了當前業界獨有的非同步編譯功能，即在查詢語句確定要使用CodeGen的時候，將編譯工作轉交給後臺線程，工作線程在JIT函數編譯完成前繼續使用原始執行邏輯執行，編譯完成後，再替換成JIT函數執行。

3. GaussDB LLVM支持加速的場景

支持LLVM的表達式：

行存表達式計算支持的數據類型不受限制。

在向量化執行引擎中，僅當表達式出現在Scan節點的filter、Hash Join節點中的complicate hash condition, hash join filter, hash join target, Nested Loop節點中的filter, join filter, Merge Join節點的merge join filter, merge join target, Group節點中的filter表達式時，才會考慮是否使用LLVM動態編譯優化。

在行執行引擎中，除一次性的表達式計算外，會考慮為所有運算元的filter和Targetlist表達式都使用LLVM動態編譯優化。

支持LLVM的運算元：

其中，HashJoin運算元僅支持Hash Inner Join，對應的hash cond僅支持int4, bigint, bpchar類型的比較；HashAgg運算元僅支持針對bigint, numeric類型的sum及avg操作，且group by語句僅支持int4, bigint, bpchar, text, varchar, timestamp類型操作，同時支持count(*)聚集操作。Sort運算元僅支持對int4, bigint, numeric, bpchar, text, varchar數據類型的比較操作。除此之外，無法使用LLVM動態編譯優化，具體可通過explain performance工具進行顯示。

4. GaussDB LLVM使用建議

GUC參數：

enable_codegen：控制LLVM特性的打開和關閉。目前資料庫內核側預設打開。

codegen_cost_threshold：使用處理行數控制是否開啟codegen，預設為10000。10000是通過實驗驗證得出的優化值，不建議將此值設置的過低。

另外，在開啟LLVM特性的前提下，建議在允許的條件下儘可能設置較大的work_mem，如果出現大量下盤，則建議關閉LLVM動態編譯優化。用戶可通過analysis_options為on(LLVM_COMPILE)，執行對應查詢語句，在User Define Profiling中就可以看到LLVM的編譯時間。結合此數據，可對codegen_cost_threshold進一步調整以獲取更好的查詢性能。

5. GaussDB LLVM性能表現

GaussDB實驗室分別就codegen打開和關閉進行了TPCH性能測試。

▲ 表1 測試環境

測試結果顯示，打開codegen時，帶有qual的SQL，查詢性能都有明顯提升，且提升比例與qual在整個SQL中的占比相關，像Q6、Q12、Q19等qual占比較高的查詢，性能提升也較多。

▲ 表2 TPCH 部分Query的測試結果

TPCC的性能提升並沒有TPCH那麼多，但據實驗室數據，打開codegen後，tpmC提升了約7%。

PostgreSQL中的LLVM

1. LLVM在PostgreSQL應用的時間線

LLVM在PostgreSQL社區中的技術討論開始的比較早：

2015年，上文提到的華為在PostgreSQL開發者大會上做的演講；

2016年，PostgreSQL社區開始對JIT的實現進行了討論；

2018年，PostgreSQL11中，第一次正式採用LLVM加速表達式計算。

2. PostgreSQL LLVM實現簡析

如下圖所示，和GaussDB相同，PostgreSQL執行引擎使用CodeGen技術做性能優化。針對錶達式求值和元組分解為所需的屬性集合兩大性能瓶頸，做了可選的編譯執行加速。

▲ 圖 8 PgSQL LLVM 模塊層次圖

PostgreSQL使用了三個參數來判斷是否使用CodeGen優化：

• jit_above_cost，表示超過多少cost 的查詢才會使用JIT 功能。預設為100000，如果設置為-1 則關閉JIT。
• jit_inline_above_cost，表示超過多少cost 的查詢使用JIT 的inline 功能。預設為500000，-1則關閉inline 功能。
• jit_optimize_above_cost，表示超過多少cost 的查詢使用JIT 的optimization 功能。預設為500000，-1則關閉優化功能。

其中，後兩個參數都需要設置得比jit_above_cost大，否則沒有意義。這和GaussDB的使用數據集大小來控制是否開啟CodeGen思想類似。

另外，PostgreSQL對於LLVM生成的位元組碼目前無法在plan cache中復用。這個功能的實現在PostgreSQL的中長期計劃中。

3. PostgreSQL LLVM支持加速的場景

當前，PostgreSQL的JIT實現支持對錶達式計算以及元組拆解的加速。

表達式計算被用來計算WHERE子句、target lists, aggregate聚合和projections投影。通過為每一種情況生成專門的代碼來實現加速。

元組拆解是把一個磁碟上的元組轉換成其在記憶體中表示的過程。通過創建一個專門針對該表佈局和要被抽取的列數的函數來實現加速。

總結

華為和PostgreSQL關於LLVM特性的研究都起步很早，華為作為LLVM技術應用於資料庫先驅者引領了PostgreSQL的技術發展。對於LLVM應用於資料庫，GaussDB和PostgreSQL各有實現方法。GaussDB作為企業級資料庫，對比PostgreSQL資料庫，其實現特性多於PostgreSQL。

“【分享集贊回帖贏好禮】LLVM技術在GaussDB等資料庫中的應用”活動來啦！參與就有機會贏取華為背包、華為雲定製短袖、藍牙音箱、書籍等好禮！

活動時間：2024/5/28-6/10

如何參與？

長按識別二維碼，即可參與！

點擊關註，第一時間瞭解華為雲新鮮技術~