推 locklose: DB可以用udf把資料丟到cuda排序 08/04 17:36
推 Litfal: 等你測試@@因為我覺得用in memory DB解決I/O bound或簡化 08/04 20:36
→ Litfal: 改用NOSQL。資料庫bound不太容易在CPU吧 08/04 20:37
推 nick5130: 小弟拙見 參考看看 就我所知,cuda thread計算能力不比 08/04 20:40
→ nick5130: CPU 純粹是靠數量多撐起來的效能,那差別可能像國小跟大 08/04 20:40
→ nick5130: 學生的程度,因為我並不清楚sql query真正在處理什麼 08/04 20:41
→ nick5130: 但是可以預見的應該是很多條件判斷式,這對cuda thread 08/04 20:42
→ nick5130: 來說是很難的事,速度會很慢 我猜應該是這個原因所以做 08/04 20:42
→ nick5130: 的人很少,基本上gpgpu做的運算都是非常簡單的運算才會 08/04 20:43
→ nick5130: 快得起來的 08/04 20:43
→ nick5130: 我會認為如果同時有大量sql squery的需求才做這種研究 08/04 20:44
→ nick5130: 要想透過GPU加速,你可能要先試試看單個cuda thread的 08/04 20:44
→ arrenwu: 我印象中GPGPU能執行的任務有滿大的限制 08/04 20:44
→ nick5130: response time有多久,可以接受再繼續做會好一點 08/04 20:45
→ nick5130: GPGPU另外一個瓶頸在PCI-E的頻寬,除非資料量夠大也夠平 08/04 20:46
→ nick5130: 行化,不然最簡單算上資料從記憶體複製到GPU,在用cuda 08/04 20:47
→ nick5130: thread處理,這時間應該會是一個考量的點 08/04 20:47
→ nick5130: 一點拙見 參考看看 如果有錯誤的地方還請指正 08/04 20:49
→ Litfal: 我跟樓上想法差不多,補充一下,運算都簡單的話代表資料庫 08/04 20:50
→ Litfal: 不複雜,那瓶頸改用NOSQL就能改善很多;複雜的話,GPGPU並 08/04 20:51
→ Litfal: 不會比CPU更適合。所以我很好奇到底哪種情境會適合SQL。 08/04 20:51
謝謝以上的分享,其實我很久以前就有這種想法
但也因為上述的原因,一直找不到情境適合來作
但最近開始在建立伺服器端的「搜尋」系統,其實現在沒多少資料,也是不必要
但假如這是一個上千萬比資料的伺服器(類似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
推 locklose: 全文檢索?我覺得建metadata可能幫助比較大 08/05 14:30
→ Litfal: 但是你想想,上千萬筆同時被query又沒索引,bound一定是在 08/05 14:34
→ Litfal: Disk而不會是運算單元阿。 08/05 14:35
推 locklose: 我是覺得可以參考SAP HANA full text search 08/05 14:42
→ nick5130: 提一點想法 你提到很簡單的query,但就是資料量很多 08/05 21:36
→ nick5130: 多是多少?比GPU的記憶體還多嗎?如果是的話,會卡PCI-E 08/05 21:37
→ nick5130: 一般GPU最多好像就12GB 應該很容易超過? 08/05 21:37
→ nick5130: 那假設沒超過好了,我依舊認為雖然你認為簡單的操作, 08/05 21:42
→ nick5130: 對CUDA thread來說應該是很難的事 08/05 21:42
→ nick5130: 那如果以上都不考慮,先從簡單的等分資料就可以開始做吧 08/05 22:05