文章目錄

• 一、背景
• 二、GPU 數據庫分類與層次
• • 1.商用型C-GDBMS 中分為3類
  • 2.研究型R-GDBMS
• 三、查詢編譯器
• • 1.GDBMS編譯模型
  • 2.GPU數據處理模型
• 四、查詢處理器
• • 1.GPU關系代數和并發原語
  • 2.復雜關系算子
  • 3.空間數據查詢
  • 4.KBE查詢執行引擎
  • 5.GPU事務處理
• 五、查詢優化器
• • 1.代價模型
  • • 1.GDBMS 代價模型之難
    • 2.算子代價估計的方法
    • 3.算子的選擇率估計
  • 2.查詢重寫
  • 3.異構計算任務隊列
  • 4.真實GDBMS系統中的優化器
• 六、存儲管理
• • 1.GDBMS數據存儲體系
  • 2.GPU數據壓縮
  • 3.GPU索引技術

一、背景

1.GPU性能極高

• GPU 與 CPU 具有不同的體系結構和處理模式,將更多的片上空間用于計算單元,控制單元和緩存單元相對很少,使得單塊 GPU 上擁有數千個并發計算核心。因此,在同樣的主頻下,GPU 能夠取得更高的并發計算能力,也使 GPU 具有滿足大數據處理需求的巨大潛能。

• 在時空數據 OLAP 分析任務和結果的可視化展示方面,幾十個 GPU 的 GPU 數據庫可以取得近千臺普通 CPU 服務的數據庫處理能力,而其響應時間甚至更短。

2.GPU數據庫功能上日趨完善

• 基于商務智能 BI 的可視化交互式圖表查詢界面支持標準 SQL 查詢語言，往往只要幾分鐘就可以完成以往數天乃至一周的工作。

• GoAI(GPU open analytics initiative,GPU 開放分析計劃)產業聯盟和 GPU 數據幀(GPU data frame,GDF)構建了數據庫庫和人工智能應用程序之間數據交換標準,使數據科學家可以停留在 GPU 上的同時探索數據,訓練機器學習算法并構建人工智能應用程序。

GPU數據庫領域的核心研究內容：

• 查詢編譯器(query compilation)：將用戶的 SQL 語言描述的查詢需求轉化為 CPU- GPU 異構計算環境下的查詢計劃;

• 查詢處理器(query processing)：應用 GPU 并行計算技術實現關系型數據處理的各種算子,挖掘 GPU 峰值計算能力;

• 查詢優化器(query optimizer)：用機器學習乃至人工智能技術,結合 CPU-GPU 異構計算環境和查詢計劃特點以及數據分布特征,生成最優(次優)的異構查詢計劃;

• 存儲管理器(memory management)：需要在異構數據存儲管理、數據存儲格式、數據壓縮、數據訪問等問題上做出決策

二、GPU 數據庫分類與層次

GDBMS(GPU database management system or GPU accelerated database management system，使用 GPU 進行或加速數據增刪改查的數據庫管理系統)。

分為研究型R-GDBMS: for research和商用型C-GDBMS: for commercial

1.商用型C-GDBMS 中分為3類

• 第 1 類是支持 GPU 計算的傳統數據庫.
  這類 GDBMS 在已有傳統數據庫基礎之上,將特定算子部署到GPU 上用以加速的查詢處理,包括以 PostgreSQL 為基礎的 PG-Storm 系統和 DB2 的擴展模塊 DB2 BLU.

• 這類數據庫與現有數據庫集成度高、周邊工具完善、且具有一定的與 OLTP 系統集成的能力;

第 2 類是非內存型 GDBMS,

• 使用 GPU 完成全部或者大部分數據庫關系運算,可以分析超過 10TB 的數據量,包括 SQream 和 BlazingDB;

第 3 類是內存型 GDBMS,

• 該類系統將數據全部駐留內存,以發揮 GPU 的全部潛在性能、提高數據處理速度,可以處理 1TB~10TB 的較小數據集,包括 OmniSci(原 MapD),Kinetica(原 GPUDB),MegaWise,
  Brytlyt

以一臺普通服務器配備多個 GPU 顯卡就能取得分布式大數據系統一個集群的處理能力.超大吞吐量、超低時延以及更低的成本,讓 GDBMS 在 OLAP 業務上優勢明顯

2.研究型R-GDBMS

研究原型 GDBMS 將重點放在了全 GPU 計算上，DB的數據數據可以在 GPU 顯存上存儲的情況下,GPU 加速所能獲得的最高性能.根據支持顯卡廠商,可分為專用 GDBMS （因為使用 CUDA 而只能在
Nvidia 顯卡上運行）和通用 GDBMS（后者使用 OpenCL,在 Nvidia 卡和 AMD 卡上都可以運行）。

三、查詢編譯器

? 首先,查詢編譯器需要利用 CUDA\OpenCL 編譯工具生成 GPU 可執行代碼,同時要創新 SQL 編譯模式,盡可能減少 SQL 編譯的開銷,使整體的性能最優;

? 其次,傳統的“火山模型”不適合 GPU 計算,GDBMS 查詢編譯器面臨著關系數據處理模式的變化,需要將向量化(vector-wise)、一次一算子(operator-at-a-time)和批量執行(bulk processing model)這 3 種策略結合起來
（1）向量化，原指將多個關系型數據以向量形式作為一個 SIMD(single instruction multiple data)指令的多個操作數來處理的方法,可以有效提高查詢處理吞吐量.
（2）在 GPU 中,向量化思想可以用 GPU的單指令多線程(single instruction multiple thread,簡稱 SIMT)進一步加大數據處理的吞吐量;
（3）“一次一算子”與“一次一數據”是數據處理的兩種模式:
前者就是先將所有數據同時完成第 1 個算子的處理,并保存中間結果,作為下一個算子的輸入數據,直至全部處理完;
而后者是指先讓一條數據經過所有算子計算得出結果,再計算下一條數據的策略,是基于 CPU 計算常采用的策略;
（4）批量執行就是盡可能一批處理更多的數據,通過提高單次處理數據的數量,彌補處理頻次不高的缺點;

GDBMS 借鑒了 CPU 計算中的向量化、 “一次一算子”、批量執行這 3 種策略,并使之適應 GPU 大規模并發計算的特點

1.GDBMS編譯模型

DBMS 大多采用解釋型的 SQL 前端

• 通過語法解析、語義解析模塊將查詢query解析為，可為查詢執行引擎使用的內部任務表示，即邏輯執行樹

GDBMS 查詢編譯器采用 3 種不同的編譯模型來解決異構環境下 SQL 編譯難題,即 JIT 代碼生成(并發原語)、 SQL 虛擬機和適配器模式

• 基于底層虛擬機(LLVM)編譯器框架來即時編譯 SQL 代碼（預編譯并發原語），是目前 GDBMS 系統編譯器實現的主流方法。
  （1）該方法使用基于 LLVM[32]的 nvcc 編譯器，將關系算子分為更小的原語 primitives，并把原語預編譯為架構無關匯編代碼 PTX，在運行時，由編譯器只需完成 SQL 語言到算子的編譯工作；
  （2）查詢執行器在優化器指導之下完成算子到并發原語的映射。
• 虛擬機模式
  優點：將 SQL 編譯為操作碼(opcode)作為中間表示,將整個 DB 系統視為一個虛擬機,Opcode 操作碼對應的算子被預編譯為cudabin 可執行代碼,直接發送到 GPU 端執行（CUDA 編譯器由google提出）。
  缺點：虛擬機模式放棄了SQL 優化的機會,無法提供查詢重寫、基于代價的優化;
• 適配器模式
  GPUDB 編譯器直接使用代碼生成模塊,將 SQL 直接編譯為 CUDA 或 OpenCL 驅動能執行的代碼，以算子為單位進行即時編譯，適配器模式在運行時的編譯負載會比較高。

2.GPU數據處理模型

,從數據處理模型來看,可分為 3 種:

• 迭代模式(iteration)
  改進版的火山模型，如增加每次迭代的數據量、使用 SIMD 指令一次處理多個數據、推拉結合的數據獲取方式等

• 批量模式(batching)
  將每個查詢編譯為可執行代碼，采用完全物化的方式處理所有數據。
  但在實現 ad-hoc 查詢上,面臨靈活度不夠、物化存儲空間要求過高的問題。

• 二者的混合
  比如微批量化查詢處理.該類方案使用不同的粒度作為數據處理的單元,仍然在邏輯上組織成樹型結構,讓數據自底向上流動完成查詢操作,兼具迭代模型的靈活性和批處理的高吞吐量的優點

GDBMS 普遍采用向量化一次一算子數據處理模式,并以此改造查詢編譯器，原因如下：

• 首先,迭代模式并不適合 GDBMS,因為火山模型賴以存在的虛函數機制因為 GPU 缺乏對應的復雜邏輯控制模塊,在 GPU 上不可實現或者引起嚴重的線程分支惡化問題。
  GPU應采取的操作是：
  將列數據細粒度分配給 GPU 線程,并用循環展開的方式,可有效減少控制指令總量,有效降低分支惡化的風險

• 列式處理更適合 GDBMS
  一次一列來處理數據時,由于每列數據類型一致,可以用向量化方式處理,避免了分支判斷劣化性能問題；
  GDBMS 系統普遍采用列式處理模型[30],比如 Ocelot[13],CoGaDB[10]等

• 由于 GPU 的大規模并行編程模型依賴于對數據的并行處理,很多算法想在 GPU 上運行必須適應單指令多線程(SIMT)的編程范式,所以需要對關系算子進行并行化改造
  “一次一算子”的數據處理模式就是:讓數據在 GPU向量化算子間流動，每次采用完全物化的策略保存算子輸出的中間結果，作為下一個算子的輸入數據

• 為了降低物化代價，通過適當分區切分數據，采用數據流水化處理(pipelining data processing),有效提高數據處理并行度

四、查詢處理器

GDBMS 查詢處理引擎，接受處理查詢編譯器輸出的查詢計劃樹 QEP(query execution plan)并執行查詢返回結果。

GDBMS 查詢處理引擎面對的核心問題是：

• 功能上，如何利用 GPU 實現關系代數運算,即實現選擇、投影、連接、聚合基本的關系算子,同時還需要實現的空間數據(geo-spatial data)處理、 OLAP 聚合查詢等功能復雜的算子
• 在執行模式上，GPU 上執行的代碼被稱為 kernel 核函數，以核函數為基礎的查詢處理技術(KBE)是GDBMS 查詢處理引擎的必然選擇
  （1）如何在 GPU 高并發SIMT 模式下以何種粒度切分關系查詢樹來最大化查詢處理性能，是 GDBMS 面臨的性能挑戰
  （2）GDBMS采用的策略：
  在邏輯查詢樹級別，用 KBE 融合或切分的策略，提升 GPU 的資源利用率和查詢并發度;
  在算子級別，則采用了設計專門針對 GPU 優化的算子的方法，即數據并發原語的方法

1.GPU關系代數和并發原語

在 GPU 上實現選擇、投影、連接等基本關系代數算子,是實現 GDBMS 數據庫的基礎。

• .CUDA/OpenCL 賦予了程序員使用 C\C++代碼控制 GPU 大規模并行環境的能力,簡化了GDBMS 開發的難度,促進了GDBMS 的繁榮。
• GDBMS使用分層設計，將關系代數功能拆解為算子層(operator)和原語層(primitives)兩部分，設計了一系列的適應 GPU 計算的數據并行原語(primitives)。
  如下所示是大部分的 GPU 并發原語
  
• eg：比如:scatter 原語[43]通過分區散射操作,在每個 load-store 周期內處理一個分區的散射操作,增加了數據訪問聚合讀寫；
  很多算子映射成原語的單個或多個組合,能夠充分利用 GPU 高并發計算能力.通過以上原語的排列組合,大部分簡單的關系代數算子可以進行有效拆解.比如選擇算子可以用 filter 原語實現,同時,filter 原語是由 map 原語、 prefix sum 原語和 scatter 原語實現的。

2.復雜關系算子

Join 算子

• :GDBMS 在處理 Join 算子上比 CPU 方案效果好得多，這是由于 Join 算子是計算制約算子(compute-bounded)決定的
• 如何進一步優化GPU 上 Join 算子算法以及如何調整連接順序(join-order problem)，仍是GDBMS 領域收益最高的研究熱點之一

OLAP 聚集函數算子

• 聚集函數算子是又一個計算負載很高(compute-bounded)的關系代數算子,適合使用 GPU 加速。
• 在 OLAP 分析工作任務中,切片(slicing)、切塊(dicing)、上卷(Roll-up)、向下鉆取(drill-down)以及數據立方(cube)函數是OLAP 業務中經常用到的算子，結合
  sum,average,maximum,minimum,median,count 等各類聚集函數，提供給用戶

3.空間數據查詢

在空間索引方面，將歷史數據構建駐留GPU 的空間索引，能夠處理大部分時空數據查詢，是未來發展方向之一。

4.KBE查詢執行引擎

在查詢執行引擎實現方式上，由于 GDBMS 普遍采用的 CUDA\OpenCL 以核函數(kernel)為載體執行協處理器計算。

• 所以大部分 GDBMS 使用基于核函數(kernel based execution,簡稱 KBE)[40]的查詢執行引擎

• 一種自然的實現 KBE 的方法就是將每個關系算子以一個 kernel 函數執行,大部分 GDBMS 基于此實現自己的查詢處理引擎,比如 CoGaDB,MapD 等。

• 在此基礎之上,已有研究在核函數的層次上進行合并融合或細致切分兩種策略:
  （1）針對數據量大或計算復雜的任務,通過將多個核函數融合(kernel fusion)到一起,共同完成查詢處理;
  （2）而對于相對簡單的任務,則進一步切分核函數(mini-kernel),做到精細化管理,以合理利用 GPU 資源

核函數融合

• 優點：核函數融合技術通過增加 GPU 函數處理操作的數量來優先使用 GPU 資源,使得同樣配置下更能發揮 GPU 高并發高速率的優勢,同時減少核函數的數量,減低了系統調用和管理的開銷,非常適合 GPU 多計算少邏輯控制的硬件特性
• 缺點：核函數融合技術并不能增加單位數據的計算強度,不能從根本上提高加速比;其次,核函數融合技術增加了單個核函數處理所需要的資源,以降低 GPU 資源重復利用率為代價;
• 最后,核函數融合技術目前還不能有效地跟查詢優化器結合起來,如何有效融入真實 GDBMS 系統中是個未解之題

核函數切分

• 核函數切分能夠以更精細的粒度管理 GPU 資源,使流水化成為可能,提高了資源利用率的同時,降低了單個核函數的運行周期,可以進一步提高查詢并發度。
• 但是核函數切分是以更頻繁的核函數調度為代價的,數據換入換出頻率更高,受 PCIe 總線瓶頸影響更大,如果控制不當,很可能降低系統整體性能

小結

• 基于核函數的查詢執行模式適應 GPU 編程的范式,是目前 GDBMS 采用的主流技術.該技術兼顧靈活性和實效性,通過將算子預編譯為不同粒度的核函數,在運行時根據數據的規模啟動不同維度的線程塊(warp)執行查詢,同時保留了進一步優化的空間
• 但是,基于核函數的執行策略還面臨數據傳輸瓶頸的考驗和核函數容易崩潰的問題,當數據超過一定限度或者中間結果物化代價過大超過顯存容量時,需要引入全局的優化策略避免核
  函數失敗重做的代價.同時,KBE 策略普遍沒有考慮數據規模的問題,依賴于在運行時啟動多少核函數、分配多大顯存的策略,在實踐中,這樣的策略往往過于復雜而采用全列運算來避歸,付出了過大的計算代價.

5.GPU事務處理

如何在 GPU 上實現數據庫事務的并發執行還是一個開放問題,需要在 GPU 并發控制算法、 GPU 數據高效獲取、日志和故障恢復機制、 GPU 高效鎖實現機制、樂觀并發控制策略等方面進一步研究。

五、查詢優化器

首先,如何建立 GDBMS 查詢處理的代價模型

• 是查詢優化的核心問題;其次,在代價模型指導下,構建適應 GPU 查詢處理的啟發式規則體系對查詢樹進行等價改寫,是 GDBMS 優化器的重要問題；

再次,GDBMS 查詢優化問題在一定程度上可以抽象為算子在何種類型的計算核心(CPU or GPU)上進行處理的問題

• 即算子分配問題,解決了算子分配問題,就能最大程度地發揮GDBMS 整體性能優勢;

最后,如何在真實系統中設計實時高效的查詢優化器，與數據庫系統的其他模塊協同工作，是制約 GDBMS 發展的關鍵問題

1.代價模型

代價是數據庫內核對給定 SQL 任務執行成本的估計,在傳統數據庫中包括 CPU 執行代價和 IO 代價兩部分

• 是邏輯查詢計劃向物理查詢計劃轉化過程中選擇最優物理執行計劃的依據

下面介紹構建 GDBMS 代價模型所面臨的挑戰以及兩種常用的采用代價估計方法

• 基于代碼分析的“白盒方法”
• 基于學習的“黑盒方法”，并簡要介紹算子選擇率的估計方法

1.GDBMS 代價模型之難

SQL 優化過程可以分為邏輯優化和物理優化兩個階段:

• 在邏輯優化階段
  優化器根據關系代數等價定律、算子下推啟發式規則、子查詢重寫等規則對邏輯執行計劃進行改寫,以得到執行代價更小的物理執行計劃;
• 物理優化階段
  需要為邏輯查詢計劃中的算子選擇特定的算法和數據訪問方法，并選擇其中代價最低的一條生成路徑作為最終的查詢計劃；

傳統磁盤為中心的數據庫查詢執行代價估計

• 以磁盤 IO 和 CPU 計算的加權平均和作為最終的查詢執行代價

分布式數據庫的代價估計

• 通信代價

內存數據庫的代價估計

• 代價估計的重點是內存訪問

造成 PCIe 總線數據傳輸開銷成為了 GDBMS 代價估計的重點和難點的原因如下：

• 在 GDBMS 中,必須根據 tuple 計算的位置(在 CUP 中還是在 GPU 中)來分別計算其代價.在 GPU 中,計算的代價由于其速率更高所以必須乘以一個經驗系數(比如 0.1);
• GDBMS 中存儲層次體系更加復雜——既包括傳統的緩存-內存-硬盤三級存儲管理,又包括主機內存與 GPU 設備內存的異構存儲體系管理,這決定了 GDBMS 必須設計獨有的、能夠充分反映 GDBMS 存儲特性的訪存代價估計函數。
• GDBMS 的性能瓶頸在于主機內存與 GPU 顯存之間的數據拷貝，可以類比于分布式數據庫中的網絡通信開銷,這也是在代價估計中必須考慮的最重要的因素.
• 其次，在多 GPU 環境的系統中，由于多 GPU 往往共享 PCIe 總線，因此多 GPU 下性能并不呈現簡單的線性增長，而且與之相關的管理成本和決策空間也相應變大。

2.算子代價估計的方法

基于代碼分析的方法認為,查詢的執行取決于生成指令的代碼，因此可以通過靜態的代碼分析方法將 GPU 上執行的關系代數算子的執行代價精確估計,包括傳輸代價、計算代價、傳回代價及內存訪問代價。

• 這種方法依賴于對每個算子的精確估計
• 缺點：
  由于采用了靜態的“白盒”分析的方法,只能針對算子級別進行分析,沒有考慮多查詢并發情況下算子之間的相互影響以及系統運行時
  的負載情況，不可避免地將在運行時發生錯誤；
  而且隨著系統的進化,任何代碼上的微小改動都將對代價估計產生影響，對代價估計模塊的維護成本也隨之增高，在擴展性和可維護性上面臨巨大挑戰

基于學習的方法將算子視作黑盒通過機器學習的方法,經過觀測算子的過往行為,估計該算子的執行代價，并在運行時利用反饋機制修正算子代價.

• 這種方法在一定程度上避免了靜態方法的一些問題,但同樣不夠完美:
• 首先，基于學習的方法需要一定的訓練過程,這在實際生產環境下面臨冷啟動缺乏基礎統計數據的問題，造成優化器可發揮作用的時效性低，切換任務后面臨新的“訓練空窗期”；
• 其次，基于學習的方法對算子代價的估計是不精確的
  執行計劃的代價估計需要考慮的空間過大,很難在訓練階段窮舉所有的情況,這就造成了對算子代價的估計模型的訓練上面臨訓練樣本空間和測試樣本空間不重疊、訓練樣本過少的問題,模型必然存在精度不高的問題
• 最后,現有基于學習的方法沒有考慮多顯卡、多計算節點分布式的應用場景,低估了 PCIe 總線瓶頸的影響.

3.算子的選擇率估計

對于一個特定的關系算子來說,基數估計(cardinality estimation)就是對算子運行前后數據的變化量評估的技術。

• 選擇率是指滿足算子條件的數據數量與數據總量之間的比值。
  算子選擇率的精確估計對中間結果大小估計、算子代價估計、最優 join 順序等都有重要影響，不但直接決定了優化器的準確性，甚至對 GPU 內存管理產生直接影響
• 目前最好的解決方案是基于抽樣的柱狀圖方法，即等寬或等值地抽取數據，事先建立多區間的統計條形圖，查詢時，結合查詢條件及柱狀圖信息估計算子的選擇率

2.查詢重寫

查詢重寫是指優化器對邏輯查詢樹等價變形，以達到提高查詢效率的目的。

• 目前的研究主要致力于改進 Join 算子的性能和合理消減 copy 算子來控制數據 PCIe 總線傳輸總量上。

• join算子改寫
  文獻針對 SSBM 測試提出了 invisible join 技術,對星型模式下的事實表與多個維表外鍵連接(star join)進行優化。
  該技術通過將 JOIN 重寫為事實表上的多個 Select 操作,并用布爾代數將多個選擇的結果合并,以減少后續 JOIN 階段的整體數據量。

• 減少 copy 算子
  對于查詢優化,可以通過查詢重寫技術減少 copy 算子的數量為目標,來減少在 PCIe 上來回反復傳輸的數據量，從而提升性能

• 表連接的順序是查詢性能優化的關鍵.在現有的 GDBMS 中,各系統放棄了連接順序的優化,采用確定性的查詢計劃構建方法，目前,多表連接順序判定仍然是數據庫優化領域開放問題之一,還沒有一個可以利用GPU 加速該問題求解的成熟方案

3.異構計算任務隊列

GDBMS 與傳統 CPU 數據庫的不同之處在于,可以利用 CPU-GPU 異構計算平臺并行處理數據

• 為保證多個計算設備(CPU 和 GPU)處于“繁忙”狀態，保證系統整體性能，給每個計算核心維護一個工作隊列，根據啟發式規則，將查詢計劃樹中相互獨立的算子分配給工作隊列并發執行

4.真實GDBMS系統中的優化器

HyPE 優化器框架采用可移植分層設計,在很好地解決了查詢性能預測(query performance prediction)和算子分配問題

• 該系統采用基于學習的方法,由 3 個部分組成:代價估計器(cost estimator,簡稱 STEMOD)、算法選擇器(device-algorithm selector,簡稱 ALRIC)、異構查詢優化器(hybrid query optimizer,簡稱 HOPE）
  
  ? 首先,在 HyPE 中,假設算子跟其處理的數據是一個整體 OP(A,D)，OP 表示算子、 A 表示使用的算法、 D表示處理的數據。
  則物理執行計劃可視為一個算子的流處理器；
  對于邏輯執行樹進行拓撲排序來序列化算子，消除算子間的數據依賴，保證每個算子執行時其子算子均已執行完畢；
  ? 其次,算子流中的算子依次經過優化器 HyPE 中,經由代價估計器(cost estimator,簡稱 STEMOD)，算法選擇器(device-algorithm selector,簡稱 ALRIC)、異構查詢優化器(hybrid query optimizer,簡稱HOPE)[70]，為特定算子選擇合適的實現算法，并根據啟發規則為算子分配合適的處理器

HyPE 的 3 個模塊內部工作流程如圖 4 所示

• 對于查詢計劃中的每個算子 O，在算法選擇器中選出其對應的CPU\GPU 算法 A，經由代價估計器，以測試數據集 D 和算子的參數 P 運行機器學習算法，估計對應算法的代價，最后由異構查詢優化器按照啟發式規則選擇最終的算法和執行計算核心，并將選擇結果反饋給系統作為后續
• 盡管 HyPE 優化器基于機器學習的方法估計算子執行代價，并組合多種啟發式規則選擇算子的物理實現算法，但是將查詢優化問題等價為在運行時處理算子分配問題的優化策略對 GDBMS 來說未必是最有效的
  

PG-Storm，brytlyt/BrytlytDB基于開源數據庫 PostgreSQL，復用了 PostgreSQL 優化器模塊。

• 通過計算 cost,在查詢執行加護中插入適合的 GPU 算子(Join、 Scan、聚合等),將計算任務分配到 GPU 端加速,取得了較好的效果。
  這種編譯期靜態分配的任務分配策略，避免了 HyPE 優化器在運行時決策算子分配問題的負載，可以取得確定性的性能提升

六、存儲管理

傳統的 DBMS 與 GDBMS 在存儲管理器上存在以下不同.

• 第一，從功能上說,面向磁盤的數據庫主要包括內存管理和外存管理兩部分;而對于 GDBMS 來說,還增加了 GPU 顯存管理的任務.如何充分發揮異構存儲體系的性能優勢,是 GDBMS 數據管理最核心的問題;
• 第二，壓縮數據能夠有效減少需要處理的數據總量，進而成比例增加 GDBMS 的性能。
  如何在 GPU 異構顯存體系下盡可能獲得更大的壓縮比,充滿了挑戰;
• 第三，索引能夠加速以硬盤為中心的數據查詢處理，但是在 GDBMS 大量物化的全量處理模型中是否還有存在的價值、如何發揮索引長處加速查詢處理，也是 GDBMS 存儲管理需要研究的重要問題.

1.GDBMS數據存儲體系

GDBMS 普遍采用內存駐留(memory-resident)的技術,將數據盡可能放在內存中(甚至放在 GPU 顯存上)來避免磁盤 IO 瓶頸。

列式存儲在 OLAP 業務中比行式存儲在性能上有明顯優勢。

2.GPU數據壓縮

用輕量級壓縮算法 WAH 壓縮位圖索引以支持范圍查詢,數據首先以壓縮形式發送給 GPU,再在 GPU 上以 DecompressVector 技術解決 WAH 壓縮數據無法用 GPU 并行處理的問題,實現了在壓縮數據上直接進行查詢,性能較 CPU 并行算法最高提升了 87.7 倍

3.GPU索引技術

傳統數據庫中,使用 B+樹等索引結構減少訪問數據時磁盤讀寫的負載.在 GDBMS 中,由于索引結構在訪存特性上的隨機性,不滿足 GPU 對齊合并訪問的特點，傳統的索引結構照搬到 GPU 異構計算環境下性能不高;

甚至由于 GDBMS 全內存存儲和一次一算子全物化的查詢處理方式,不使用索引一樣可以達到很高的性能。

因此,在 GDBMS 中,如果使用全顯存存儲數據,索引可能是多余的模塊;

但對于要直接從硬盤存取數據的 GDBMS,索引可在絕大多數情況下有效消除了磁盤 IO.

• 比如:PG-Storm 由于要從磁盤讀取數據，且無法改變 PostgreSQL 的存儲引擎，因此選擇用 BRIN-index 減少查詢需要傳輸到 GPU 的數據量

總結

以上是生活随笔為你收集整理的《GPU 数据库核心技术综述》论文学习的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。