なぜオープンソースのデータベースはGPUを使わない？ 52
ストーリー by headless
高速 部門より
高速 部門より
insiderman 曰く、
米ジョージア工科大学の研究者らが、NVIDIAと共同でGPUによるデータベースのクエリ処理の高速化を研究しているそうだ(論文アブストラクト、 本家/.)。
論文ではLogiQLを実装した商用データベースLogicBlox 4.0を使い、GPUによる高速化を試みている。GPUを利用することで、並列クエリ処理はXeon E5-2670×2(16コア、32スレッド)のAmazon EC2ノードの6.48倍、PCIeの転送時間を除いた計算時間のみで比較すると7.86倍高速という結果が出ている。また、逐次クエリ処理の場合、12GBのメモリーを搭載したCore i7-920マシンの65.92倍、計算時間のみでは79.94倍高速という結果になったとのこと。
LogiQLはDatalogベースのクエリ言語で、SQLなどの一般的なクエリ言語とは異なるため単純にほかの分野に応用できる感じではなさそうだが、GPUならではの構成を使ったデータベースというのは面白そうだ。
なお、本家/.記事は、ここ数年GPUによるデータベース処理高速化の研究が次々に発表されているにもかかわらずオープンソースのデータベース向けのコードが出てこないことについて、何が障壁となっているのかという疑問で締めくくっている。
単に (スコア:1)
まだ研究中だから実装レベルまでには至っていないからじゃないの？
商用DBが実装しているなら違うけど、実装してるDBあるのかな。
Re:単に (スコア:3, 参考になる)
いろいろ研究されてるそうだから、こんなことは全部解決されてるのかもしれませんが、
素人なりに憶測すると、単にGPUが得意なことと、データベース処理に必要なこととが、微妙にズレてるからってだけな気がします。
GPUは中で、中だけで完結して計算をぐるぐる回すようなことはめっぽう速いそうですけど、
その計算の材料や、また計算結果であるデータ自体の、外部との受け渡しの速度は、別にそんなに特筆して爆速ってわけでもないのでは？と。
つまり、たとえば、三角形の頂点３個ぽっちのような、少ないデータをGPUに渡して、その少ないデータから、様々な角度に回転させた何億通りもの頂点を瞬時に計算するような処理は得意だろうけど、
一方、データベースから検索するような処理って、まず膨大なデータを検討材料として渡さないと始まらないから、とにかくGPUに渡すことになると思いますけど、渡す所はべつにそれほど速くないのだから、結局そこがボトルネックになって、GPUの計算速度というおいしい部分が相殺されてしまって効果がそれほど上がらないとか、そういうことなんじゃないかな？と思いました。
適当なこと言ってます。
Re:単に (スコア:2)
バッチ処理ソリューションとかも利用するの無いのかな。
請求計算とかSIMDチックにできそうな気がして適切な場面にならないかなぁと思っているのですが。
Re: (スコア:0)
GPUっていうか、専用の石があった方がよさそうには思うけど、なんちゃらプロファイルみたいなので、「このサーバーに必要な計算はコレだ！」って風には決められないのかなぁ。
Re:単に (スコア:1)
Netezza は FPGA を使ってるらしいです。 2007 年のホワイトペーパー [datamgmt.com]には、専用の石 (ASIC) は柔軟性に欠けるから FPGA の方がいいよ、と書いていました。
Re: (スコア:0)
余ったPCIスロットに挿すだけでいい、という程度の安価なHWが出来たなら導入が進む気もする。
でなければ、使われてないIntel HDGを使って処理を高速化するとか。
いいグラボ挿してる人は、ゲームなりCGなり映像編集のために挿してるのであって、
他のアプリケーションにGPUを使われても困る。
Re: (スコア:0)
Xeon Phiとか無かったっけ？
Re: (スコア:0)
だってサーバー用PCのGPUはオンボード程度じゃん
長期に渡ってぶん回すようにできてないでしょう
Re:単に (スコア:1)
デスクトップの仮想化（負荷の高い描画もできるだけサーバ側でやる）と、サーバを想定したグラフィックカードが
去年くらいに流行っていた気がする。
やろうと思えば今でもできるはず。
Re:単に (スコア:1)
サーバー用はサーバー用にTesla GPU [nvidia.co.jp]なんてのがあります。
DisplayPortやHDMIとか、ディスプレイ出力さえ持っていない計算専用。
TomOne
Re: (スコア:0)
オラクルがHSA Foundationに参加したので順調に行けばオラクルから出るでしょうな
PGstrom (スコア:1)
これ [postgresql.org]はどうでしょう?
Re: (スコア:0)
私もニュース的に聞いたことがあったのを思い出しました。
実際に動かしたことはない（動かせるものなの？）のですが、Amazon RDS で PostgreSQL が入ったので、実は少し期待してます。
高速なGPUを導入する予算が (スコア:1)
Re: (スコア:0)
な～に、XeonPhiを導入するより安いからガンガン積みましょうぜ！
Re: (スコア:0)
Tesla K20X採用、単精度浮動小数点演算で京を大幅に超えるTsubame2.5に掛かった費用は京の1/50以下という低コスト。
http://pc.watch.impress.co.jp/docs/news/20130729_609529.html [impress.co.jp]
ソーティングの結果 (スコア:1)
研究者は自分が思いついたor実行可能な研究ネタの内最も良さそうなものに着手します。
大抵の研究者には自分より優れた能力の研究者がおり,そのような研究者は自分が思いつかなかったより良いネタを研究している中、自分は自分より優れた研究者なら誰もが気がついたにもかかわらず選ばれなかったネタを研究しているので、そのような研究ネタのソーティングに気がついていない研究者は自分の研究ネタは誰もが思いつくようなネタなのに何故誰もやっていないのだろう、と言う印象を抱くことになります。
Re: (スコア:0)
# と無理矢理自己肯定してみる
Re:ソーティングの結果 (スコア:1)
びっくりするような結果が出ず、隙間を埋めうるだけの結果に留まったとしても、知識の不備な領域を少しずつ埋める事には十分な意義があると思いますよ。
高望みして何も成果を出さないのが一番良くないと思います。
なぜ高速化するのか？ (スコア:1)
GPUの得意分野って、怒涛の積和演算であって、
データベースといまいち相性が良くないような気がします。
データベースでは比較演算が多そうなのですが、
GPUはその比較演算処理を並列化できたりするんでしょうか？
信頼性 (スコア:0)
計算がミスっていないことをどのように保証しましょう？
Re: (スコア:0)
前からずっと気になっていたのだけど
ソフトウェア処理は正確で、ハードウェア処理は早いけどあまり正確じゃないのはなんでなんだろう。
エミュレータで顕著だけど。
DBにも同じことが言えるならいくら早くても何の役にも立たないとは思う。
1分で1000の仕事だがミスは絶対にない奴と
1分で100万の仕事をするが1/10000でミスをする奴なら前者の方がいいし。
多少ミスっても許容できる仕事なら後者の方がいいけどさ。
Re:信頼性 (スコア:3, 参考になる)
元々GPUは画像処理だけだったから多少エラーが多くても許されてたけど、最近ではGPUのエラー発生率もCPUと同じくらいになってる、って噂は聞いてる。
ちなみにCPUだからって「ミスは絶対にない」なんて事は無い。ただ極端にエラー発生率が低いだけ。
# 「何でもは知らないわよ。知ってることだけ」みたいな感じなのでIDで
Re:信頼性 (スコア:2)
1+1が失敗する確率が違うの？
Re:信頼性 (スコア:1)
GPU使ったスパコンはエラー率考えると実行効率が公称の1/10
それを加味すると普通のスパコンとコストパフォーマンス変わらない
という記事は以前読んだ事が
ベクトル型スパコンは高価だけど実行効率考えるとスカラー型より優秀な場合がある
事とか考えると、どれもアプローチや向き不向きが違うだけで、
同じくらいのコストパフォーマンスなのかも
TomOne
Re:信頼性 (スコア:2)
float精度の話？
Re: (スコア:0)
Firefoxだったか、doubleをfloatに変更する事で大幅に高速化とか
Re: (スコア:0)
「結果が変わらない場合のみ無駄な倍精度演算の命令を生成しなくなった」って話がなぜか歪曲されてる件
Re: (スコア:0)
最近ならハードウェアエンコーダとかじゃない、ソフトウェアより速いけど、質は良くない。バグがあっても直せないし。
Re: (スコア:0)
何を言っているのでしょう?
Re: (スコア:0)
どんな例なのか具体的にしりたいな。名前だけでいいので教えてください。
Re: (スコア:0)
ゲーム機のエミュレータでグラフィック設定をソフトウェアエミュレーションだと遅いけどうまくいくけど、
ハードウェアエミュレーションにすると早いけど再現性が低いってことを言ってるの？
あれはハードウェアでサポートしている似た機能にマッピングして擬似的に再現するか、すべての点を書くところまでソフトウェアで面倒見るかってことだとおもうんで、どっちもソフトウェアの範疇じゃないか？
実装してコミットすればいい (スコア:0)
この人は誰かにやるなと脅されているのか？
あほなのか
Re: (スコア:0)
誰にでも出来ることを自分しかしてなかったら、
不思議に思うのは普通のことだろう。
Re: (スコア:0)
既存のDB開発者はGPGPUに詳しくないんじゃね？長らく分野違いだったから。
この人は詳しいというのなら、ぜひいろんなとこにコミットして欲しいものだ。
Re: (スコア:0)
必要性を切に感じてる人がいないor少ないんだろうね。
Re: (スコア:0)
OracleやMS SQL ServerのソースをNDAか何か結んで見たことがあるので貢献したくてもできないとか。
障壁 (スコア:0)
・頻繁に変わるアーキテクチャ
・NDA
あと、何がありましたっけ？
Re:障壁 (スコア:1)
・一般人が持ってるPCのGPUでは高速化されないむしろ遅くなるケースが多い
Re:障壁 (スコア:1)
ボトルネックを明確にせずにチューニングを行なうのは, 往々にして徒労に終わりますからね.
query中心の用途だと, まずはIOがネックになって, 次にデータを主記憶に貼り付けることが出来たとして主記憶-GPU間の帯域が問題になりそうってのが予想できますね. その辺が対応できるような環境・用途なら価値は有ると思いますけど, 汎用のオープンソースDBを使うような用途では無くはないけど主流ではないでしょうね.
transaction系だと, ほとんど意味は無いでしょうし.
Re: (スコア:0)
そもそもRDBMSのボトルネックって、クエリ処理なの？
HDDアクセスとかそっち方面じゃないかと言う気がしてならない。
Re: (スコア:0)
ミッションクリティカルなものだと、256コアのSMPで256GBのオンメモリDBなんてものを束ねて数十TBクラスのDBクラスタを構築するなんてことが存在している世界だからなあ。たかだか数GBメモリしか扱えないものに分散しても、制御および管理コストの方が高くついて、速度は出ないし実用的ではないんですよ。
Re: (スコア:0)
GPUのメモリにドカドカ流し込んでグルグルポンできないかなぁとか思ったりします
Re: (スコア:0)
だから研究ではPCIeの転送時間を除いた計算時間のみで比較してるんでしょうね。
GPUを使わないのにはそれなりの理由があるって事でしょう。
Re: (スコア:0)
・そんなことに使うなんて勿体ない
GPU（性能）が確定的な環境として期待出来ないから (スコア:0)
まぁオプションとして存在するのはアリだと思いますが。
Re: (スコア:0)
規模のスケーリングと管理コスト、クエリのターンアラウンドタイムが稼げないから、割に合わないんです。
GA上のメモリにオンメモリ展開できる数GBクラスのDBで、ターンアラウンドタイムに余裕があるケースならありだろうけれど。
仮想化 (スコア:0)
仮想化された鯖も普及してますからねぇ
そこがGPU仮想化対応しているかとか
オーバーヘッドでむしろ遅くなるとか
リソース占有率とか
その辺も考慮しないとあかんよね
分野が違う (スコア:0)
・GPUを弄ってる人のなかにDBMSに興味のある人が少ない。
・DBMS弄ってる人のなかにGPUに詳しい人がいない。
というだけじゃないですかね。
データベースの計算速度は間に合っているの？ (スコア:0)
各種ＤＢの集計・OLAP関数の計算速度には、みなさんあまり不満はないのでしょうか？計算はＤＢからデータを抽出した後でやるから関係ないとか？