ClubDB2参加記録 第177回 DB2 BLUとイントラパラレル試してみたよ（ゲスト講師：永安氏)に行ってきました。

club DB2

久しぶりのblogです。
もっとアウトプットする癖を定着させたいですが、なかなかうまく行かないですね。

さて、表記の通りで、久しぶりにCLUB DB2に参加してきました。
最近は気持ちの余裕が足りてなく、勉強会からもついつい足が遠のいていましたが、「このままじゃダメだ」と思い、思い切って業務を切り上げて参加してきました。

DB2 BLU(ブルー)アクセラレーションのご紹介（by @sumi_chan )

簡易的に高速分析処理をさせるテクノロジー
  • カラムストアによるI/O削減
    • 列単位で保管。DWHの場合、行全部ではなく一部の列にアクセスすることが多い → 余計な列をI/Oしない分I/Oを減らす
  • 効率のよい圧縮
    • 列単位で圧縮 ＝ 同じ（似た）データが繰り返しやすい ＝ 圧縮率が上がる
    • 高頻度のデータは高圧縮にする圧縮アルゴリズム
    • 圧縮状態で演算が可能 → 解凍コストが不要
      • ”＝”だけでなく、”＞”、”＜”演算も可能！
  • SIMDを使うことで高速
    • SIMD：Single Instruction Multiple Data
    • 1回の命令で複数のレジスタを演算するH/W命令。
      • （例）v4si_add命令（gccで使える命令）
        • v4si_add(a,b)
        • {4,13,28,43} + {17,97,53,8} = {21,110,81,51} を1命令（1クロック）で処理する仕組み。ストア命令の分を考慮すると4倍以上命令数が少ないはず。
    • IBMの技術というわけではなく一般的な技術（？）
  • データスキッピング
    • 何らかのデータの塊（ページ単位？）毎にデータ範囲のタグを持つ。不要なページヘのアクセスをスキップすることでI/Oを減らす。
    • (例)5年分のデータを保管しているDBで直近1年分だけアクセスする場合、不要な4年分にはI/Oしない。
  • エンティティ単位でカラムナを選択できる
    • Create TableのOrganize by [COLUMN|ROW]で指定
BLUの強み
  • 全体的に早くなることもメリットだけど、極端に遅いことを回避することが大きなメリット

DB2 BLUとイントラパラレル試してみたよ！(by 永安さん）

毎度ながら訳の分からない長文になるので、心に残ったキーワードを中心に。

  • PostgreSQLで限界を感じることがあるため、テクノロジーとしてイントラパラレルを試してみたかった
    • PostgreSQLはシングルプロセス、シングルI/O
    • グリーンプラムは？と思ったら、内部に複数のPostgreSQLが動いているらしい
  • 元データ 100GBをDB格納すると
    • Non-BLU ： 189GB（TBL+Index）
    • BLU ： 48GB
      • この時点で約4倍の差。Non-BLUが圧縮なしとはいえ、この時点で大分性能が出そう。
  • 検証結果として、すっごく早くなったクエリが沢山と、そんなに早くなっていない（それでも通常の行指向DBと同じぐらいのパフォーマンス）のクエリがある。
  • 早くなるパターン
    • 利用する列が少ない ＝ I/Oが大量に減る
    • I/Oが1/30に減る例も！
    • その分CPUバウンドになって、CPU利用率が上がっている
    • CPU利用率が上がっても総処理時間が短くなっているので、総CPU利用量は下がっていそう。
  • イマイチなパターン
    • select *を含むクエリ
      • 内部で列をくっつけて行を作りなおすJoinが動くので、どうしてもオーバーヘッドが大きい。
      • でも、Non-BLUに負けてないんだからすごい。
  • データによって差が出るのでPoC重要

カラムナーDBの実装

本編最後のQAで非常に有意義なことを知ったのでメモ

  • 行の再構成コストを削減するために、カラムナーDBはいろんな実装がある
    • 行指向DBをマスターとして保持しつつ、アドホック・クエリー用に列指向DBを同時持ちする
    • 1つずつではなく、複数の列をまとめて格納する
    • BLUは1列ずつのデータしか保持しない
      • 今回の例は、行の再構成コストを払ってもお釣りが来るほど、I/O削減が効いているパターンだと思われる
      • 確かにDBによっては30倍の圧縮効率が出ていた。
  • カラムナーDBをOLTPに使うのはさすがに無理
    • INSERT/DELETEまでは何とかなるがUPDATEが致命的
    • UPDATE文を内部でDELETE/INSERTに置き換える実装をしているが、遅い
  • DB2 for z/OSにはBLUは提供されていない
    • BLUの代わりにAnalytics Acceleratorがある
      • Analytics Accelerator：ｚの後ろにNetezzaをおいて、アドホック・クエリーをNettezaに自動でオフロードする仕組み
    • 結局、CPU課金が大きいので、ｚ上のDB2で処理するBLUではなく、Netezzaにオフロードする方がメリットが大きい。

雑談

当然ながら2次会にも参加しました。永安さんの正面という一番美味しい席に座らせてもらって、楽しい＆有意義な時間を過ごさせてもらいました。楽しかった〜。
本編で、かなりの質問をさせていただいたのですが、2次会でも遠慮せず（失礼しました！）色々と質問させていただきました。
毎度のことながら終電の関係でお先に失礼しましたが、非常に楽しい＆有意義な時間でした。
でも、お酒の席の会話、半分ぐらい忘れちゃってる。。。もったいないので、次からはメモ持参で参加しようかな（笑）

その他のキーワード

  • 検証結果を非公開（配布資料なし/UStreamなし）理由
    • 前提条件を無視して、数字だけがひとり歩きしかねないので数字は公表しなかった
    • 数字だけひとり歩きして嫌な思いをさせたくない
    • 追試可能な状態にしてある。再現性がある
  • 最近の永安さんの肩書：チーフデータマエショリスト（笑）
    • 一瞬、どんな肩書なのか真剣に考えてしまいました。

  • 30日で検証準備からプレゼン準備を実施
    • 最初にWBSを作成！

最後に

毎度のことではありますが、運営して頂いているClubDB2の皆さん、いつもありがとうございます。
また、お忙しい中検証結果をシェアしていただいた永安さん、ありがとうございました。
またまた、2次会でお会いした皆さんとも楽しい時間を過ごすことが出来ました。