PG-Strom勉強会
昨晩、PG-Strom勉強会 (2/18) : ATNDに行ってきた。
備忘のために #pgstrom ハッシュタグのTweetベースで簡単にメモを書いておく。きちんとまとまったレポにはなってないけど。
会場
- 恵比寿ネオナート5階。恵比寿駅から直近だけど、降りる場所を間違えたのでちょっと迷った・・・。
- 地上に降りたら負け。
- ネオニートじゃないぞ!
- 19時ぎりぎりに到着。
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の利用
- FDW内の挙動
- Background Worker
- background workerからPG-StromのGPU制御用バックエンドプロセスを起動する。
- 測定結果
- 改善したいところ
- 列指向
- 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でコミットされれば)
- 今後
- QA.
- 複数枚でも対応可能か?原理上は可能なはず。スケジューラはもう少し最適化出来そうな気もするとのこと。
- (Hokuto Takaiさん) Xeon Phiだとx86動くし,TCP/IPで繋がっているように使えるのでGPUよりオフロード出来る部分が増えると思うのだがどうか?A.GPUだと複雑な分岐処理できないが,Phiだと複雑な正規表現でもPhi側で処理できるようになると思う.
- PG-Stromのライバルのプロダクトは?→今のところ商用プロダクトとは競合しないと思っているとのこと。イメージ処理、遺伝子情報のデータベースなどが適用先?
- 今の改善が一段落したあとの大改造プランはある?→GPU管理サーバを複数持たせる。NW帯域と複数サーバによる並列化とどっちが早いか。
- NUMAの場合、PostgreSQL間のメモリ転送がネックにならないか?→今は考慮していない。NUMA対応はPostgreSQLの共有バッファから考え直さないと厳しいかも?
行レベルセキュリティ
- あるユーザの場合、特定のユーザしか見えない行を制御する。Oracleのバーチャルプライベートデータベースみたいなもの(らしい)
- ユーザ定義関数にトンデモな低いコストを返すようにしてしまうと、ビューに対して検索しても、本来見せたくない行が見えてしまう!
- (ishikawa84gさん) Leaky VIEW まとめ - KaiGaiの俺メモ
- この問題の解決方法の本質は、最適化を犠牲にするということか。なるほど。
- Leakproof関数の話。今更ながらやっとで、この関数の意味がきちんと分かった気がする・・・
- ALTER文で設定すると、セキュリティバリアなクエリに展開され、確実に安全な関数のみ内部クエリに落とすという仕組みっぽい。
- QA
- Leakproofかどうかの判断は自動判別できない。スーパーユーザの判断に任せるしかない。