這個問題是2016年的問題，現在是2021年底，GPU數據庫已經基本GG了。我解釋下一些基本的原因。
數據庫的「瓶頸」是個非常復雜的問題，把數據庫瓶頸歸結於IO肯定是不準確的，因為每個數據庫系統、每種workload的瓶頸都不一樣。通常來說，我們把數據庫分為TP(事務)和AP（分析）。GPU數據庫的目標場景是AP，所以我們的討論限定在AP場景。我說下GPU的一些核心缺點。
- 視訊記憶體不足。 GPU的視訊記憶體空間比較有限，復雜的AP SQL通常是比較吃記憶體的。正常情況下，如果記憶體不足就要落盤，涉及到落盤的場景GPU就搞不定了 。還有一些其他方面的原因，展開講就需要討論很多細節了。阿裏內部的同學可以去ATA看下我的文章，有詳細分析。
- 並行不足 。數據庫通常是高並行場景，GPU處理不了。
- 不劃算 。即使是AP數據庫，瓶頸也不是都在計算上。有的SQL瓶頸可能在網絡，有的可能在計算，有的在IO。花大價錢買了GPU卻只能加速計算，其實是很不經濟的。有這個預算可能不如升級下ECS的規格。
- 現有的AP數據庫，計算的瓶頸普遍不在硬件上 。做硬件加速的前提，是軟件的最佳化空間已經被壓榨幹凈了。但是目前的分析性數據庫系統（OLAP）的軟件效能遠遠沒有被壓榨幹凈。雖然已經有很多論文研究了很多數據庫計算引擎的最佳化方法（SIMD，向量化，codegen等），但是產品實踐上落地的還非常少。尤其是國內數據庫圈子，真正懂數據庫引擎的人少之又少。隨便誰看了兩篇文章都可以評論下數據庫計算引擎該怎麽設計，但是大多數人實際上連概念都搞不清楚。
5. 系統設計理念問題 。數據庫系統普遍對通用性要求非常高。比如今天有個使用者有10種workload(T0-T9)，數據庫不需要每個workload都跑的很完美，但是至少需要每個都能跑。如果用GPU加速數據庫，由於我上文提到的種種原因，結果很可能是：T0/T1跑的很好，T3-T5效能還不如CPU，T6及以上由於視訊記憶體不足等原因跑不通。這種情況對於一個數據庫產品來說，顯然是無法接受的。
澄清一下，我沒有針對GPU啊，我是說「硬件加速」這個idea在數據庫領域，都不work。
