Club DB2で講演します

DB

　5/15にClub DB2（恵比寿ガーデンプレイス）で講演を行います。タイトルは「ループをめぐる物語――SQLにおける手続き型の復権」です。中身は、『SQL実践入門』の内容についての解説ですが、特にウィンドウ関数の使い方にスポットをあてて、これまでループの代用として使われてきた自己結合や相関サブクエリに比べて、直観的でわかりやすく書けて性能もよいというメリットについてお話しようと思います。

　大量データを入れたテーブルを使って、実際にSQL文を実行して性能を見ながら、なぜそのような差が生じるのかということを、実行計画を確認しながら解き明かしていくというデモも予定しています。

　お楽しみに。

2015/5/19追記
　講演資料をアップしました。当日はたくさんの方にご来場いただきありがとうございました。そして200回続けてこられた運営の方々、お疲れ様でした。毎回好き勝手しゃべらせてもらって、寛大さに感謝です。

　さて、当日のダイジェストをざっくり私の視点でまとめるとこんな感じです：

  • 講演のテーマは、タイトルのとおりSQLの中で手続き型の考え方（行の順序を意識したコーディング）が復活しつつあって、それを利用するととてもいい感じなのではないかと。
  • 具体的には、今回の本の主役であるウィンドウ関数が最強伝説すぎる。これを使うと相関サブクエリと結合を消去できるのでウソみたいに性能が良くなるし、実行計画も安定して一石二鳥。
  • 結合というのは性能問題の温床なので、ない方が性能的にはいいに決まっている。Nested Loops/Hash/Sort Mergeとアルゴリズム変動しちゃうし、それが起きなくても駆動表がひっくり返るだけでもNested Loopsの性能はブレブレ。
  • Hashの方が駆動表の変動に対する感度が小さいので、Nested LoopsよりむしろHashを基本に据えた方がよいのでは？ それは単性能ベース見た場合なだけで、実際は多重走行するとHashはけっこうメモリ食いなので怖いのですよ。テーブルが小さければTEMP落ちも起きないけど、テーブル小さならそもそもNested Loopsで十分ですしねえ。
  • そのようなわけで、MySQLがNested Loopsしか結合アルゴリズムを持っていないのは、利用シーンを考えると一つの見識だとかねがね思ってます。実際同時実行数の多いWeb系のシステムでHashやSort Mergeが選択されたらメモリ不足ですぐに爆死してしまうのではないでしょうか。
  • MySQLがウィンドウ関数を持っていないのも同じ理由によるのではないかと。「Oracle買ってね（はぁと）ってことでしょ」とか、憶測でものを言うのはよろしくないですな。AにはAの、BにはBの仕事がありましょう。
  • ビッグデータ分析はSQL/RDBとは別のアーキテクチャ（R言語+NoSQLとか）で実現する方が適切ではないのか？ 私もそんな気がするのだけど、SQL/RDBって長年何かにとってかわられると言われ続けてなかなかくたばらないんですよね。こんだけ寿命長く一線にとどまる言語も珍しい。なんでか？ うーんなんででしょうね・・・。
  • 以前ぐるぐる系は性能が悪いってdisっちゃったけど（事実なんだけど）、やっぱり実行計画が安定するというメリットは無視できないのではないか、と思い直しました。特にゼロリスク願望の強い日本の風土にはよくマッチする処理方式なのかも。日夜複雑なSQLの実行計画の最適化に心を砕いているDBベンダの方が見ると「・・・」な気分になっちゃうかもしれないけど。
  • ジョジョネタはしばらく封印。

　それでは、250回記念でまたお会いしましょう。