PG-Strom勉強会

昨晩、PG-Strom勉強会 (2/18) : ATNDに行ってきた。

備忘のために #pgstrom ハッシュタグTweetベースで簡単にメモを書いておく。きちんとまとまったレポにはなってないけど。

会場

  • 恵比寿ネオナート5階。恵比寿駅から直近だけど、降りる場所を間違えたのでちょっと迷った・・・。
  • 19時ぎりぎりに到着。

PG-Strom

  • 名前
    • (Manabu Oriさん)streamのドイツ語がしゅとろーむ(strom)らしい。
      • stormじゃない。
      • 最初、てっきりGPUの嵐が吹き荒れる!みたいな感じで間違えて覚えていたw
    • (Takeshi Yamamuroさん) GPUのコアがstream-processorだからpg-strom
  • 基本的な考え方
    • GPU を使用してクエリの処理を非同期かつ並列に実行する。
  • 目指すもの
    • (Ryo Fujitaさん) 一番コスト対効果の高いビッグデータソリューションにしたい。
  • 適応領域
    • PG-Stromは万能の高速化ではない。適用領域がある。
    • PG-stromはシンプルなインデクススキャンプランには向かない。生PostgreSQLのほうが向いている。
    • フルスキャン、複雑な条件などではPG-Stromの効果がある
    • (Ishikawa, Kohkiさん) PG-Stromが効果的と予測されるのは、Indexが効かずスキャンが必要な場合。NetezzaのFPGA併用とも構造的には似ている気がする...GPGPUの特性上データを篩い落とすタイミングがメインメモリへのロードの前と後で違いそうだけど
  • 役割分担。
    • GPUは簡単な四則演算など。CPUはNWやディスクI/OなどCPUにしかできないことをやらせる、というのが基本のアイディア。
    • GPUでの配列計算の例。配列要素1つに対して演算ユニットを割り当てる。
    • GPUのコードをhostメモリからdeviceメモリに転送してから実行する?その間はCPUが並列に動作できるということか?
    • (Takeshi Yamamuroさん) 最新のGPUだと分岐命令(分割統治法的な分岐)、少し強化されましたよね
    • GPUで実行するコードのことをGPU世界の人ではkernelと呼ぶらしい。
    • GPUを呼び出す関数には同期モードと非同期モードがある。サンプルは簡単さのために同期モードで書いている。
    • ホストからはソース形態でGPUコードをGPUに配布する。GPU内で実行時コンパイルする。これにより互換性を高くしている。
    • (Ryo Fujitaさん) CPUとGPGPUも使う場合の比較。長所は超並列で非同期なこと。短所はホスト・デバイス間のDMA転送コストとコードの複雑化。
  • SQL/MEDの利用
    • (Ryo Fujita さん) SQL/MED(Management of External Data)を利用して、クエリ実行の負荷をOracleMySQLに外出し出来る。
    • FDWを使って、別サーバの他情報源にクエリを投げている間はCPUが空く。同じように、FDWを経由してGPUに仕事をさせたい。
  • FDW内の挙動
    • PFDW plannerで条件句からGPU用Kernel codeを自動生成
    • FDW ExecutorでJITコンパイル&shadow tableからのロードとGPUの演算を並列に実施するイメージ。
    • IteratorForeignScanの中で非同期実行している。現状のPostgreSQLアーキテクチャでは1プロセスは1PCUまで割り当てという決まりがあるらしい。並列I/Oサーバが将来的に必要になるだろう。
  • Background Worker
    • background workerからPG-StromのGPU制御用バックエンドプロセスを起動する。
  • 測定結果
    • 2000万行のテーブルでGPU使うとだいたい10倍くらい速くなった
    • WHERE句にx,yの距離計算を書いてフルスキャンする場合だと、PG-Stromで10倍近く高速に処理できた。
    • そしてGPUのカードは安いのもポイント。
  • 改善したいところ
    • 現状の疑似コード生成→GPU内で疑似コードを逐次処理するのは、やはり遅いのでJITコンパイラに置き換えたい。
    • (Takeshi Yamamuroさん) OpenCLはgitコンパイル用のIFがあるのか・・・
  • 列指向
    • PG-Stromで列指向の考え方を使っている理由。PCI-Eの帯域と共有メモリを節約したい。
    • shadow tableというのは行指向のデータを列指向に変換するもの?
    • (Takeshi Yamamuroさん) pg-strom、shadow-table経由でcolumnar-storageになっている、values部分が型が同一のarrayになっているようだけど、これ内部的にはvarlena?整数なら、整数圧縮が効きそう、逆にLZ系は効果が薄そう
  • Writable-FDWとの関連
    • Writable-FDWの副産物。FDWで定義したカラム以外の疑似カラムを持たせられる(9.3でコミットされれば)
  • 今後
    • (Manabu Oriさん) 今はCUDAで実装、今後はOpenCLに移行予定
    • (ishikawa84gさん) CUDA やめて OpenCL で作り直す
    • 今後の話。OpenCL対応、可変長データ対応(データブロックに似た考え方?)、複雑な処理をSQL関数から呼び出し。
  • QA.
    • 複数枚でも対応可能か?原理上は可能なはず。スケジューラはもう少し最適化出来そうな気もするとのこと。
    • (Hokuto Takaiさん) Xeon Phiだとx86動くし,TCP/IPで繋がっているように使えるのでGPUよりオフロード出来る部分が増えると思うのだがどうか?A.GPUだと複雑な分岐処理できないが,Phiだと複雑な正規表現でもPhi側で処理できるようになると思う.
    • PG-Stromのライバルのプロダクトは?→今のところ商用プロダクトとは競合しないと思っているとのこと。イメージ処理、遺伝子情報のデータベースなどが適用先?
    • 今の改善が一段落したあとの大改造プランはある?→GPU管理サーバを複数持たせる。NW帯域と複数サーバによる並列化とどっちが早いか。
    • NUMAの場合、PostgreSQL間のメモリ転送がネックにならないか?→今は考慮していない。NUMA対応はPostgreSQLの共有バッファから考え直さないと厳しいかも?

行レベルセキュリティ

  • あるユーザの場合、特定のユーザしか見えない行を制御する。Oracleのバーチャルプライベートデータベースみたいなもの(らしい)
  • ユーザ定義関数にトンデモな低いコストを返すようにしてしまうと、ビューに対して検索しても、本来見せたくない行が見えてしまう!
  • この問題の解決方法の本質は、最適化を犠牲にするということか。なるほど。
  • Leakproof関数の話。今更ながらやっとで、この関数の意味がきちんと分かった気がする・・・
    • ALTER文で設定すると、セキュリティバリアなクエリに展開され、確実に安全な関数のみ内部クエリに落とすという仕組みっぽい。
  • QA
    • Leakproofかどうかの判断は自動判別できない。スーパーユーザの判断に任せるしかない。

ビアバッシュ

  • KaiGaiさんがドイツのビールを持ってきてくれた!ビール&ピザ&オードブルでウマー。
    • IT技術者たちがビールの開け方に苦労するの図w
    • ちょっと甘目の味のビールでした。
    • Ryo Fujitaさん曰く、小麦が入っているので少し白っぽい→白ビールとのこと。
  • Ryo Fujitaさんのライトじゃないライトニングトーク
    • ビールって奥が深い・・・
    • 日本だとほんの一部のビールしか大手メーカが作ってないのね。
  • ビアバッシュ参加費は200円でした♪