GaussDB作為企業級的資料庫，經過了多年的技術發展，具備豐富的技術特性，使用LLVM技術後提升了系統的查詢性能，使得開發者在OLAP和OLTP多場景中均受益。 ...

GaussDB作為企業級的資料庫，經過了多年的技術發展，具備豐富的技術特性，使用LLVM技術後提升了系統的查詢性能，使得開發者在OLAP和OLTP多場景中均受益。

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）的情況下，疊加 JIT技術之後將TPS從20.7提升到了43，性能上有了兩倍的提升。

GaussDB中的LLVM

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

華為雲資料庫在LLVM上的研究還是非常超前的。早在2015年，華為就作為某流行開源資料庫社區的全球開發者大會的贊助商，在會上發表的動態編譯（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的運算元：

Join ：HashJoin（僅向量化執行引擎支持）

Agg ：HashAgg

Sort（僅向量化執行引擎支持）

其中，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性能測試。

操作系統	EulerOS release 2.0 (SP8)
CPU	128核 * aarch64
記憶體	2.0Ti

表1 測試環境

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

TPCH	數據量	qual（Expr）	測試結果（s）	性能提升
關	開
Q6	0.9億	l_shipdate >= '1994-01-01'::date and l_shipdate < '1994-01-01'::date + interval '1 year' and l_discount between 0.06 - 0.01 and 0.06 + 0.01 and l_quantity < 24;	66	52	21%
Q12	6.0億	and l_shipmode in ('MAIL', 'SHIP') and l_commitdate < l_receiptdate and l_shipdate < l_commitdate and l_receiptdate >= date '1994-01-01' and l_receiptdate < date '1994-01-01' + interval '1 year'	306	210	31%
Q19	6.0億	and l_shipmode in ('AIR', 'AIR REG') and l_shipinstruct = 'DELIVER IN PERSON'	296	208	30%