[請益] GPU-based SQL 資料庫

看板VideoCard作者 (Willy)時間7年前 (2016/08/04 16:16), 7年前編輯推噓5(5推 0噓 26→)
留言31則, 4人參與, 最新討論串1/1
想請教有沒有人有使用GPU加速SQL速度的經驗 雖然我還沒實作，但以下是我的猜測 （Centos 7, C++, CUDA in C++, MariaDB, CPU八核心） ﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍ 程式的執行是由int main開始 接著併發一千個cuda thread, parse 「mysqlcppconn」 lib給每個thread （mysqlcppconn 是一個mysql寫給C++ lib, mariadb也可用） 每個thread單獨連接mariadb，mariadb不設thread pool，也就是one thread per connection cuda thread 執行完query, 返回結果給int main ﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍ 根據我的猜測，以下這幾點是不是正確的呢？ 1. mariadb的query 執行一樣是CPU，不管是直接c++呼叫，還是從一千個cuda thread 2. 根據1, 只是一千個query在CPU一直task switch 另外，上網查GPU-based的SQL, 好像SQLite目前有支援GPU執行 https://www.cs.virginia.edu/~skadron/Papers/bakkum_sqlite_gpgpu10.pdf http://wscg.zcu.cz/wscg2014/Short%5CK17-full.pdf 我還沒時間仔細看，但直接看結論，似乎SQLite可以真正作到 把「SQLite」包在每個cuda thread，真的是同時執行一千個sql query 而不是還要透過CPU一層 希望可以聽到有經驗的人的分享，謝謝 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.133.16.181 ※ 文章網址: https://www.ptt.cc/bbs/VideoCard/M.1470298594.A.DD1.html
推
08/04 17:36, , 1F
DB可以用udf把資料丟到cuda排序
08/04 17:36, 1F
推
08/04 20:36, , 2F
等你測試@@因為我覺得用in memory DB解決I/O bound或簡化
08/04 20:36, 2F
→
08/04 20:37, , 3F
改用NOSQL。資料庫bound不太容易在CPU吧
08/04 20:37, 3F
推
08/04 20:40, , 4F
小弟拙見 參考看看 就我所知,cuda thread計算能力不比
08/04 20:40, 4F
→
08/04 20:40, , 5F
CPU 純粹是靠數量多撐起來的效能，那差別可能像國小跟大
08/04 20:40, 5F
→
08/04 20:41, , 6F
學生的程度,因為我並不清楚sql query真正在處理什麼
08/04 20:41, 6F
→
08/04 20:42, , 7F
但是可以預見的應該是很多條件判斷式，這對cuda thread
08/04 20:42, 7F
→
08/04 20:42, , 8F
來說是很難的事，速度會很慢 我猜應該是這個原因所以做
08/04 20:42, 8F
→
08/04 20:43, , 9F
的人很少，基本上gpgpu做的運算都是非常簡單的運算才會
08/04 20:43, 9F
→
08/04 20:43, , 10F
快得起來的
08/04 20:43, 10F
→
08/04 20:44, , 11F
我會認為如果同時有大量sql squery的需求才做這種研究
08/04 20:44, 11F
→
08/04 20:44, , 12F
要想透過GPU加速，你可能要先試試看單個cuda thread的
08/04 20:44, 12F
→
08/04 20:44, , 13F
我印象中GPGPU能執行的任務有滿大的限制
08/04 20:44, 13F
→
08/04 20:45, , 14F
response time有多久，可以接受再繼續做會好一點
08/04 20:45, 14F
→
08/04 20:46, , 15F
GPGPU另外一個瓶頸在PCI-E的頻寬，除非資料量夠大也夠平
08/04 20:46, 15F
→
08/04 20:47, , 16F
行化，不然最簡單算上資料從記憶體複製到GPU，在用cuda
08/04 20:47, 16F
→
08/04 20:47, , 17F
thread處理，這時間應該會是一個考量的點
08/04 20:47, 17F
→
08/04 20:49, , 18F
一點拙見 參考看看 如果有錯誤的地方還請指正
08/04 20:49, 18F
→
08/04 20:50, , 19F
我跟樓上想法差不多，補充一下，運算都簡單的話代表資料庫
08/04 20:50, 19F
→
08/04 20:51, , 20F
不複雜，那瓶頸改用NOSQL就能改善很多；複雜的話，GPGPU並
08/04 20:51, 20F
→
08/04 20:51, , 21F
不會比CPU更適合。所以我很好奇到底哪種情境會適合SQL。
08/04 20:51, 21F
謝謝以上的分享，其實我很久以前就有這種想法 但也因為上述的原因，一直找不到情境適合來作 但最近開始在建立伺服器端的「搜尋」系統，其實現在沒多少資料，也是不必要 但假如這是一個上千萬比資料的伺服器（類似Google搜尋） 不知道Google的作法，但目前我是建立一隻「搜尋爬蟲」，反正大家搜尋的內容大部分一樣 先呈現的結果都是已經事先搜尋好的cache給上去而已，不是即時搜尋，即時會太慢 目前想試試看如何加速搜尋爬蟲，從用CPU改成GPU 目前可能想試試看 1.mariadb的被搜尋資料建立在sqlite 2. 看要用哪一種方法切分資料成一千等分 3. 只是很簡單的"select content from table where content like '%apple%'" 情境：『很簡單的query, 但就是資料量很多』 當然現在資料量很少，但想實作看看 ※ 編輯: hn12404988 (220.133.16.181), 08/04/2016 23:11:38
推
08/05 14:30, , 22F
全文檢索？我覺得建metadata可能幫助比較大
08/05 14:30, 22F
→
08/05 14:34, , 23F
但是你想想，上千萬筆同時被query又沒索引，bound一定是在
08/05 14:34, 23F
→
08/05 14:35, , 24F
Disk而不會是運算單元阿。
08/05 14:35, 24F
推
08/05 14:42, , 25F
我是覺得可以參考SAP HANA full text search
08/05 14:42, 25F
→
08/05 21:36, , 26F
提一點想法 你提到很簡單的query，但就是資料量很多
08/05 21:36, 26F
→
08/05 21:37, , 27F
多是多少？比GPU的記憶體還多嗎？如果是的話，會卡PCI-E
08/05 21:37, 27F
→
08/05 21:37, , 28F
一般GPU最多好像就12GB 應該很容易超過?
08/05 21:37, 28F
→
08/05 21:42, , 29F
那假設沒超過好了，我依舊認為雖然你認為簡單的操作，
08/05 21:42, 29F
→
08/05 21:42, , 30F
對CUDA thread來說應該是很難的事
08/05 21:42, 30F
→
08/05 22:05, , 31F
那如果以上都不考慮，先從簡單的等分資料就可以開始做吧
08/05 22:05, 31F
‣ 更多 hn12404988 的文章
文章代碼(AID): #1NeldYtH (VideoCard)