作者hn12404988 (Willy)
看板VideoCard
标题[请益] GPU-based SQL 资料库
时间Thu Aug 4 16:16:32 2016
想请教有没有人有使用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://webptt.com/cn.aspx?n=bbs/VideoCard/M.1470298594.A.DD1.html
1F：推 locklose: DB可以用udf把资料丢到cuda排序 08/04 17:36
2F：推 Litfal: 等你测试@@因为我觉得用in memory DB解决I/O bound或简化 08/04 20:36
3F：→ Litfal: 改用NOSQL。资料库bound不太容易在CPU吧 08/04 20:37
4F：推 nick5130: 小弟拙见 参考看看 就我所知,cuda thread计算能力不比 08/04 20:40
5F：→ nick5130: CPU 纯粹是靠数量多撑起来的效能，那差别可能像国小跟大 08/04 20:40
6F：→ nick5130: 学生的程度,因为我并不清楚sql query真正在处理什麽 08/04 20:41
7F：→ nick5130: 但是可以预见的应该是很多条件判断式，这对cuda thread 08/04 20:42
8F：→ nick5130: 来说是很难的事，速度会很慢 我猜应该是这个原因所以做 08/04 20:42
9F：→ nick5130: 的人很少，基本上gpgpu做的运算都是非常简单的运算才会 08/04 20:43
10F：→ nick5130: 快得起来的 08/04 20:43
11F：→ nick5130: 我会认为如果同时有大量sql squery的需求才做这种研究 08/04 20:44
12F：→ nick5130: 要想透过GPU加速，你可能要先试试看单个cuda thread的 08/04 20:44
13F：→ arrenwu: 我印象中GPGPU能执行的任务有满大的限制 08/04 20:44
14F：→ nick5130: response time有多久，可以接受再继续做会好一点 08/04 20:45
15F：→ nick5130: GPGPU另外一个瓶颈在PCI-E的频宽，除非资料量够大也够平 08/04 20:46
16F：→ nick5130: 行化，不然最简单算上资料从记忆体复制到GPU，在用cuda 08/04 20:47
17F：→ nick5130: thread处理，这时间应该会是一个考量的点 08/04 20:47
18F：→ nick5130: 一点拙见 参考看看 如果有错误的地方还请指正 08/04 20:49
19F：→ Litfal: 我跟楼上想法差不多，补充一下，运算都简单的话代表资料库 08/04 20:50
20F：→ Litfal: 不复杂，那瓶颈改用NOSQL就能改善很多；复杂的话，GPGPU并 08/04 20:51
21F：→ 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
22F：推 locklose: 全文检索？我觉得建metadata可能帮助比较大 08/05 14:30
23F：→ Litfal: 但是你想想，上千万笔同时被query又没索引，bound一定是在 08/05 14:34
24F：→ Litfal: Disk而不会是运算单元阿。 08/05 14:35
25F：推 locklose: 我是觉得可以参考SAP HANA full text search 08/05 14:42
26F：→ nick5130: 提一点想法 你提到很简单的query，但就是资料量很多 08/05 21:36
27F：→ nick5130: 多是多少？比GPU的记忆体还多吗？如果是的话，会卡PCI-E 08/05 21:37
28F：→ nick5130: 一般GPU最多好像就12GB 应该很容易超过? 08/05 21:37
29F：→ nick5130: 那假设没超过好了，我依旧认为虽然你认为简单的操作， 08/05 21:42
30F：→ nick5130: 对CUDA thread来说应该是很难的事 08/05 21:42
31F：→ nick5130: 那如果以上都不考虑，先从简单的等分资料就可以开始做吧 08/05 22:05