GPU 資料庫 MapD 性能超傳統資料庫 70 倍，資料庫瓶頸不是 IO 嗎？

---

資料庫瓶頸是IO，說的是Oracle,MySQL,PostgreSQL等傳統資料庫，磁碟順序訪問最多只有幾百M/S（bandwidth是內存的1/100），隨機訪問就更是慘不忍睹了（latency是內存的100000倍），因此IO成為了瓶頸，需要做很多工作來克服IO的問題，如Buffer Manager，其他的問題就沒有那麼重要了。

但是內存資料庫就完全不一樣了，尤其是純內存資料庫，也就是所有數據都在內存中，不需要磁碟IO。這時內存bandwidth，CPU性能，L1 cache miss, branch prediction miss, Lock都成了至關重要的東西。舉個例子，從L1 cache中讀數據的latency是0.5ns, 從內存中讀數據的latency是100ns，這樣就差了200倍，但是L1 cache只有32KB,所以內存資料庫中就需要充分利用L1 cache的數據結構。再比如, 實現並行hash join，lock free版的就會比用mutex.lock()/unlock()快很多。但是傳統資料庫中，因為大部分時間都用在了IO上，這些問題都不是很重要了。

具體到MapD【３】，目前為止我看到了2個使得它性能非常高的原因。

１．GPU不管是每秒浮點數運算(FLOPS)，還是從內存（顯存）讀數據的bandwidth都比CPU強很多，比如NVIDIA Tesla K80的FLOPS為　8.74TFLOPS，bandwidth為500G/S，對應的CPU能有50GFLOPS和30G/s就不錯了，參見【１】。數據從內存到顯存需要時間，不過如果一直在同一份數據上做分析，可以先把數據全部載入到顯存，之後的運算就不用內存參與了。

２．查詢引擎，傳統資料庫基本上都用的iterator model，會有很多虛函數調用和interpretation overhead，而MapD的做法是將SQL語句轉為LLVM，參見【２】，再編譯成機器碼，再執行，雖然編譯要花一些時間(如20ms)，但是跑OLAP查詢的時候可以忽略不計。舉個例子，如執行select count(*) from t where c=1;如果是一個大表，查詢時間會遠高於20ms，因此編譯產生的overhead可以忽略不計，有很多expression運算，join的複雜查詢優勢就更大了。

iterator model：

每處理一個新的tuple，都會有很多的虛函數調用，極大的影響了性能

class Operator{
public:
virtual Tuple next() = 0; //獲取下一個tuple
virtual void open() = 0; //初始化
virtual void close() = 0;
}

class TableScan : public Operator{
public:
TableScan(string t) : t(t){}
virtual Tuple next(){
read something to tuple;
return tuple;
}
private:
string t;
}

bool predicate(int value){
return value==1;
}

class Select : public Operator{
public:
Select(Operator *operator) : operator(operator){}
virtual Tuple next(){
while(!end){
Tuple tuple = operator-&>next();
if(predicate(tuple))
return tuple;
}
}
private:
Operator *operator;
}

class Aggregation:public Operator{
public:
Aggregation(Operator *operator) :operator(operator){}
virtual Tuple next(){
operator-&>next();
count++;
}
private:
Operator *operator:
int count=0;
}


編譯（用Ｃ++示範，實際上是轉化為LLVM代碼）：

把SQL轉化為這種代碼，運行時編譯為機器碼，並執行，顯然快很多，在複雜一些的查詢中，Vectorization, SIMD等能使得速度更快

int count=0;
for(int i = 0; i &

對內存資料庫感興趣的朋友可以關注一下德國慕尼黑工業大學(TUM)資料庫組的Hyper（HyPer: Hybrid OLTPOLAP High-Performance Database System），可以說是世界上最先進的內存資料庫之一，早在2011年就在查詢引擎中使用LLVM了，裡面用到的各種技術都在主頁的論文列表裡。

【1】 https://devtalk.nvidia.com/default/topic/451750/gpu-vs-cpu-comparison-over-the-last-years/?offset=6

【２】http://www.vldb.org/pvldb/vol4/p539-neumann.pdf

【３】MapD: Massive Throughput Database Queries with LLVM on GPUs

---

一般宣稱gpu在什麼什麼通用計算任務有超過CPU二十倍性能的言論(比如上百倍，上千倍)，基本可以認為是忽悠。要麼是用一款很差的cpu，要麼是用cpu單核做比較，要麼是用根本沒優化過的cpu代碼(甚至是三者的組合)。因為不管是浮點峰值，還是內存帶寬，一般都是10倍左右的差距。

極個別情況有例外，比如nvidia新發布的伏達，在某些特定任務下。

最後考考大家，對於一款haswell架構的八核cpu，如果主頻固定3.0 GHz，那麼L1 cache的帶寬是多少？

---

vldb13的一篇paper[1]測量了gpu資料庫的各種情景，結果是：gpu資料庫的瓶頸在host向device的數據傳輸上，因為顯存相對於內存仍然太小了。gpu資料庫一般默認數據放置在內存里。如果擴展到磁碟，那麼磁碟io就是瓶頸。一些資料庫操作不適合gpu，所以一個趨勢是CPU和gpu協同計算。有的gpu資料庫（非常少）支持transaction，一篇綜述有總結[2]。

[1] Yuan, Y., Lee, R., Zhang, X. (2013). The Yin and Yang of processing data warehousing queries on GPU devices. In Proceedings of the VLDB Endowment (Vol. 6, pp. 817–828). http://doi.org/10.14778/2536206.2536210

[2] Bre?, S. (2014). GPU-Accelerated Database Systems: Survey and Open Challenges. Transactions on Large-Scale Data- and Knowledge-Centered Systems XV

---

開發厲害就開發厲害，關文科生屌事，這兩天的持續戾氣都是這種智障問題搞出來的……

如果新聞都少一點標題黨，世界將會變成美滿的人間。

---

GIS資料庫中的很多運算非常吃浮點運算性能，I/O反而不是瓶頸，技術上來說，這麼做是不錯的，也符合資料庫research的趨勢，但是具體到應用，說實話我還沒有想到合適的scenario

---

這就是國外文科生和國內文科生的區別。你們忘了德布羅意本科是學歷史的了?

---

mapd 17年5月開源了有了社區版。社區版有除了高可用和分散式之外的所有功能，可視化immerse工具非商用。

目前個人使用中。使用環境為虛擬機（8核e5v3+64g）+1080ti直通。

看法：

1、性能上沒benchmark過。

2、特性上我能用得上的主要是server side rend，例子就是官網的tweet demo，可以實現快速互動式的地圖展示（圖上有很多點）。

3、大規模的使用方案沒搞過。但可能會成為小規模（個人、小企業）數據計算（超過傳統資料庫能承受的分析計算量）的一個很好方案。因為使用所需的技術成本低於hdp,ambari等。硬體成本初步估算也低於如前所說技術的環境所需的cpu、內存。

---

推薦閱讀：