七實驗評估
7.1微基準
這裡從強調RAPID DPU中的查詢處理構模組化塊的性能微基準測試開始。
硬體分區。分區是許多運算符（例如連接配接、分組，排序等）的核心元件。是以，在硬體中動态分區資料的同時，實作接近記憶體帶寬的帶寬傳輸至關重要。在微基準測試中，我們對DMS進行程式設計，在具有4列每列為4位元組的表上應用32路硬體分區。我們使用DMS支援的所有硬體分區政策來進行微基準測試：基數；分别使用1、2、4個鍵進行哈希；以及範圍分區。基數分區使用所選鍵的最低有效5位進行分區。哈希分區對1、2、4個鍵應用哈希分區。在範圍分區中，我們同一選擇輸入基數的範圍。
圖8中的結果表明，硬體分區在所有的情況下，都達到了9.3GB/s的處理速度。而這明顯優于了目前最先進的硬體加速器（為6GB/s）。此外，DMS能夠獨立于dpCore來完成這些工作。dpCore可以在軟體中進行額外的32路或者更多分區，進而将fan-out一次性增加到1024以上。雖然也有其他的優化分區政策，例如在X86架構上一次性實作類似的fan-out，但是這樣可能會需要更高的成本支出。
圖8 DMS的硬體分區性能
DMS的資料移動速度。如上所述，DRAM和運算符之間的資料傳輸，由關系通路器（RA）執行。RA使用DMS的DMA引擎将資料傳輸到DMEM，然後将資料以tile的形式提供給運算符（即一次性執行64行以上）。資料的寫入也是類似的。在圖9所給的實驗中，将tile的大小從64行更改為256行，并将通路模式更改為隻讀，或者讀寫模式。這裡顯示了列為4位元組的結果。
圖9 使用DMS的讀寫性能
基于上述圖形，可以看到，随着列數的增加，性能會略有下降。由于DMS每次隻擷取一列資料，是以在擷取非連續性DRAM頁面時會有較小的延遲開銷。其次，DMS配置開銷可以通過更大的tile設定來進行補償（參考128rw和64rw）。最後，對于總緩沖區大小為8KB（即128行/緩沖區，4X4位元組，每個r&w的雙緩沖區）的情況，DMS實作了>=9GB/s的帶寬表現，這大約是DDR3峰值帶寬的75%。
7.2運算符性能
過濾器性能。在測試中，單個dpCore實作了4.82億元組/s的帶寬，即每個元組消耗1.65個CPU周期。32個dpCore的峰值記憶體帶寬為9.6GB/s。總的來說，過濾器算子内部的計算，成功地隐藏在了DMS傳輸操作之後（即overlap）。并且算子的執行，接近早期通過DMS讀取實作的記憶體帶寬。其結果與圖9類似。
軟體分區性能。軟體分區對于在32路硬體分區之上實作更改的fan-out非常重要。為了評估分區的性能，進行了圖10所示的實驗。這裡特意使用了2列4位元組的列設定，并禁用了輸出端的雙緩沖區設定。圖10中的結果說明了兩件非常重要的事情：1）高達64路分區的軟體分區性能是可以的，且不會顯著降低性能；2）當有更多的DMEM可用時，最好為軟體分區算子使用更大的tile設定。總的來說，使用32個核心的32路分區性能約為9.48億行/s。使用大于128的tile時，實作的帶寬為7~7.6GB/s。軟體分區的性能與硬體分區提供的吞吐量相比對。是以，可以說，硬體分區和軟體分區組合，能夠在接近記憶體帶寬的情況下運作，同時實作一輪1024路fan-out的目标。
圖10 軟體分區運算符的性能
7.3連接配接性能分析
建構運算符的性能。連接配接算子被分為兩個微算子，并且在RAPID中的同一個任務中執行。可以根據tile和hash-bucket的大小來評估建構運算符的性能。其實驗結果如圖11所示。該實驗的一個明确資訊為，哈希bucket的大小對建構運算符的性能沒有任何直接的影響。這主要是因為hash-bucket數組完全在DMEM當中，并且DMEM甚至為随機通路提供了單周期的延遲通路。另外一方面，tile對性能的影響與其他算子類似。将tile從64行增加到1024行時，可以看到性能提升了39%。對于256行的tile設定，每個dpCore的性能約為4600萬行/s。由于32個核心是完全獨立的建構運算符的線性擴充，是以每個DPR的總吞吐量約為15億行/s。
圖11 連接配接建構運算符的性能
探測運算符的性能。在探測算子的性能實驗中，我們将哈希表的命中率固定為50%。并改變tile的大小和哈希bucket的參數。圖12的結果表明，隻要哈希bucket完全在DMEM當中，使用更大的哈希bucket數組也不會影響性能。此外，由于tile較大，我們也就看到了類似的效果：當tile從64行增加到1024行時，性能最多提高了30%。是以，可以看到每個DPU的總體探測算子性能，在8.8億行到13.5行/s之間。
圖12 連接配接探測運算符的性能
矢量化帶來的性能提升。可以通過在一批行上執行操作而不是一次一行的方式來提高效率，并減少查詢執行原語所帶來的設定開銷。為了說明這一點，我們隔離并運作了帶有以及不帶有矢量化的TPC-H Q3的連接配接運算符。如圖13所示，在啟用矢量化的情況下，性能大約提升了46%。此外，分支未命中預測的百分比也顯著降低。總的來說，它說明了矢量化在RAPID中的重要性。
圖13 矢量化帶來的性能提升
7.4系統總體性能分析
可以将RAPID與廣泛使用的商業資料庫系統進行內建，同時也能夠提供記憶體查詢執行能力。RAPID與MDS結合，能夠提供端到端的分析查詢處理能力。
性能/功率增益。RAPID的基本設計目标，就是提供比商用X86硬體上運作的其他系統更好的每瓦性能。在圖14所示的實驗中，我們展示了RAPID的這一關鍵方面。與內建了RAPID的系統相比，我們實作了平均15倍的每瓦性能提升。在實驗中，我們在有和沒有RAPID的情況下，在資料庫系統上分别運作了一半的TPC-H查詢。其查詢的每瓦性能比從10倍到25倍不等。總體而言，結果表明RAPID實作了極其重要的性能/功率目标。
圖14 RAPID與X86系統的每瓦性能比較
執行時間分布。由于RAPID是用于執行分析查詢的解除安裝引擎，是以擁有合理的解除安裝量，以便從RAPID執行中獲得最大的性能收益就非常重要。為了評估這一方面，我們運作了一半的TPC-H查詢，以了解RAPID的解除安裝百分比。結果如圖15所示。由于全表掃描、過濾器、group-by、top-k以及連接配接都完全解除安裝到了RAPID上，是以大部分執行都是在RAPID上完成的。從本質上講，我們看到平均97.57%的運作時間都花費在了RAPID上。
圖15 RAPID和資料庫系統已用時間對比
RAPID的純軟體性能。盡管針對DPU進行了定制，但由于有效利用了現代硬體的架構和算法，RAPID的軟體設計在X86上也可以獲得更好的性能。為了展示RAPID純軟體方面的優點，我們将其與X86上的高端記憶體資料庫進行了比較。這裡忽略了電源方面，并在8台Intel X5-2伺服器上将兩個系統與1TB TPC-H資料（比例因子1000）進行了比較。結果如圖16所示。雖然RAPID的軟體加速比從1.2倍到8.5倍不等，但是運作查詢的平均加速比為2.5倍。必須要注意的是，這裡RAPID并未對X86架構進行調整。是以，總的來說，該實驗結果表明，除了功率優勢之外，RAPID卓越性能的另外一個重要原因，來自于軟體設計。
圖16 RAPID軟體與X86上的商業記憶體系統性能對比
八相關工作
為資料庫使用定制硬體的想法并不新鮮，它可以追溯到上個世紀70年代。作為早期系統之一，Gamma資料庫機提倡在32個處理器上采用無共享架構和并行處理。
但是，由于當時的商品化硬體發展迅速，資料庫機器的硬體設計和實作跟不上，是以成本就變得過于昂貴了。
最近，Q100 DPU引入了一組異構加速器tile，并能結合粗粒度指令來表達關鍵的資料庫處理原語。相比之下，我們使用的ISA則更為通用，并能夠提供通用的加速、異步資料移動以及分區功能。
HARP是一種用于範圍分區的硬體加速器，與我們這裡的架構不同，尤其是在DMS方面。首先，我們将高性能引擎與CPU核心分離，以實作獨立操作。其次，我們的DMS使用是異步的。相比之下，HARP要求核心為每64個位元組的資料執行指令。第三，在HARP中，核心不能立即消耗分區資料，因為資料需要先進入DRAM。
SPARC M7則包含了一個定制的資料庫分析加速（DAX，Database Analytics acceleration）引擎，該引擎用于優化Oracle In-Memory資料庫的性能。32核M7處理器可以利用8個DAX引擎直接通路使用者記憶體空間。加速器可以解壓縮輸入資料，并執行過濾、範圍比較，以及集合成員查找等操作。
Tomahawk MPSoC由4個資料庫加速器、1個核管理器、全局記憶體管理以及通過分組交換的片上網絡連接配接的FPGA組成。資料庫加速器是基于Tensilica RISC的處理器，該處理器通過專門的指令集進行擴充，以便用于哈希、位圖壓縮，以及排序集操作。
Hayes等人聲稱X86中的SSE/AVX SIMD擴充不足以表達出資料庫處理的資料級并行性。作為解決方案，他們為X86的哈希表探測提出了新的矢量ISA擴充。Widx也用來處理哈希查找，但隻是作為片上加速器。它将key 哈希與清單周遊進行分離，并在一組可程式設計的walker單元上并行處理多個key值。
也有人建議使用智能SSD來提高性能和能源效率。他們将簡單的過濾器和聚合運算符編譯到SSD固件當中。不過，目前SSD中的處理器很快就成為了新的瓶頸。也有人進行了使用網絡處理器來解除安裝順序/索引範圍掃描以及哈希連接配接等實驗。
還有許多研究人員研究了将資料庫處了解除安裝到GPU上的可能性。作為定制硬體的替代方案，許多研究人員考慮使用FPGA來進行資料處理。LINQits引入了預先設計的模闆來将過濾器、哈希分組/聚合以及哈希連接配接等操作解除安裝到FPGA。Woods等人則使用稱之為lbex的FPGA和SSD來實作智能存儲引擎，該引擎支援投影下推、複雜過濾，以及分組聚合等操作。Netezza，IBM的資料分析裝置，則将選擇和預測并行推送到多個FPGA。
九結論
随着資料庫引擎需要越來越高的性能，它們也變得越來越耗電。為了解決性能/電源效率問題，我們通過軟體和硬體的重新設計來建構新的查詢處理引擎。也就是這裡描述的RAPID引擎。通過實驗，可以表明與那些在商業硬體上運作的現有高端系統相比，RAPID每瓦性能至少要高出一個數量級。
出處：https://www.modb.pro/db/180675