のた犬のうまい猫めし

どら猫が作る、のた犬のための飯、略称、どら飯について語りつつ、各種技術、経済系セミナーに参加した報告、OSSいじってみた等のネタを入れていきます。更新情報はtwitterの@nota_inuにて。

db tech showcase 2014 Tokyo「GPGPUがPostgreSQLを加速する」NEC海外氏


db tech showcase 2014 Tokyo「GPGPUPostgreSQLを加速する」超メニーコアによる検索高速化 NEC OSS推進センター 海外浩平氏 @kkaigai

 

(JP) GPGPUがPostgreSQLを加速する

 

  • SELinux、PosgreSQL、SE-PostgreSQL、PG-Stromなどを担当。HPC→OSS/Linux→SAP→GPUによるPostgreSQL高速化
  • 処理性能向上のアプローチはスケールアップ、スケールアウト。スケールアウトすると象の色が青から黄色(Hadoop)へ。ホモジニアス・スケールアップ、ヘテロジニアス・スケールアップ(特性の異なるCPUを追加して、得意領域に任せる)
  • GPU:Graphic Processor Unit。コアの数が多い。(値段の割に。)CPUが12のtころ2688個とかw。CPUはCache、Controlの占める割合が大きい。GPUは割り切った構造で、チップ上の大部分を演算コアが占める。並列に動作する演算ユニットを使って演算したりする。
  • 縮約アルゴリズム:16個の要素の配列の合計値を計算:シンクロナイズして動くので、0と1、2と3……を足し、0と2、……を足し、を繰り返す。最終的に4ステップで最終結果を作れる。(log2Nステップ)
  • 半導体のトレンド:CPUの上にGPUを乗せて出荷(IntelAMDも)。AMDは46%がGPU。これまではソフト側に手を加えなくてもハードの性能が上がってソフトの性能も上がったが、今後GPUが増えてくると、特性を意識してソフト側を設計しないとダメ。
  • Dark Silicon問題:ある時点から電力消費削減率が集積率に追いつかなくなる。熱が上がる。チップ上のすべての回路に同時に電力を入れられなくなる。解決策の一つが、特性の異なる回路を実装すること。特性が違うとピークが異なり、ピークの消費電力を抑えられる。あるいは走っているコアだけターボブーストさせる。
  • RDBMSボトルネック:以前はRAMが希少で必要に応じてメモリにロード、だったが、今はちょっとしたシステムならメモリに乗る。RAMに乗ったデータをどう処理するか。(将来的にはStorageが無くなり、広帯域RAM、不揮発型RAMになる?) ボトルネックがStorageからRAMの間だった時代は、SeqScan、IndexScanなど、戦略はIO量、ディスク分散(RAID)。帯域数百MB/s~数GB/s。RAMとProcessorの間にボトルネックが移り、Join、Aggregation、Sort、Projection。戦略は並列アルゴリズムの適用。RAMに乗っているから早いとは限らない。できるだけ単純なメモリコピー、ポインタの付け替えで済むような工夫を。

PG-Strom

  • PostgreSQL用の拡張モジュール。(ピージーシュトロームとよむ) Full-Scan、Hash-JOIN、Aggregateワークロード(GPUで効率化できるもの、動かすとうれしいものだけ)に対応。SQLワークロードの一部をGPUで並列実行。SQL文からGPU用ネイティブ命令を生成。CUDA、Open-CL。ある程度C言語ライクな。SQLもwhere句は機械的に変換できる。CPU側がIO、GPU側が計算に特化。CPUはIOだけにフォーカスし実行時間を短縮。トータルのレスポンスタイム改善。利用者からみるとただのPostgreSQL。(周辺ツール、ドライバなどは手を加えず使える。)GPUが割と値段が安いので、低コストで性能改善がはかれる。いかに高速にデータを送り込むかがネック。処理するデータはバッファ(メモリ)に乗っていることが前提。
  • 構文解析、実行計画作成、クエリ実行するが、実行計画作成時に、PG-Stromが使われる。Custom-Plan APIs。GpuScan、GpuHashJoin、GpuPreAgg。GPU Code Generator、PG-StromOpenCL Server、GPU Program Manager。
  • OpenCL:言語仕様にランタイムコンパイラ含む。NVIDIAAMDだけではなくCPU並列にも適用可能(そういうモードがある)。ヘテロジニアス計算環境を用いた並列計算フレームワーク
  • 行指向データ構造:PostgreSQLの共有バッファをDMA転送元として利用する。列指向が最適だが行列変換がコストが高いため。
  • Hash-Join:Hash表探索時に一気に実施。並列処理も一気に実施。2億件×10万件×10万件のInner Joinをテーブル数を変化させながら実施すると、標準のPostgreSQLでは200→11754だが、GPUでは29→66.ほとんど増えない。
  • FDW:ForeignDataWrapper。外部データソースをPostgreSQL表として見せるためのAPI群。データ構造を自由に規定できる。
  • 実装当時はForeignTableのみGPUアクセラレーション。当時はReadOnly。特別なデータロード関数が必要、デバイス初期化で初回クエリもっさり。まずPostgreSQL本体の改造を。Ver9.2からBackgroundWorkerなどで、GPUデバイスの初期化を常駐プロセスが一度実行するように。
  • ただFDWが本当に適切か? →Custom -Plan APIs。SQL実行ロジックを標準のものと同列に並べて取捨選択を。どのロジックがよいか。拡張モジュールでも標準実装と同列にコストベースで取捨選択。外部テーブルだけでなく通常テーブルでも。
  • T-Tree Columnar Cache:行列変換。列指向のほうが、隣接するコアがまとめて処理するのでよい。帯域が変わる。ただしPostgreSQLは可変長の位置ずれ、NULLの取り扱いなど。ただ処理すると行列変換時間が7割に。GPUで処理する時間は短くなったのに受け渡しで時間がかかる。
  • CPUは希少リソースであり、仕事をさえないかがポイント。仕事をさせる場合にはメモリ性能を発揮させやすいパターンを。
  • 対応している関数:四則演算、大小比較、浮動小数点型数値計算、集約演算(min、max、sum、avg標準偏差
  • AWSでも楽々デプロイできる。