なぜ、人はSQLをループさせたがるのか：Database Watch（2012年8月版）（1/2 ページ）

　今月は2つのユーザーコミュニティを紹介します。DB2のClubDB2ではデータベースの達人が「ダメな設計」を解説し、JPOUGは初の大規模イベントを開催してパネルディスカッションやライトニングトークで盛り上がりました。

[加山恵美，フリーライター]

設計者にもうれしいO/Rマッパ「DBFlute」

　7月13日、DB2の勉強会などを開催するコミュニティ「ClubDB2」が開催されました。冒頭のライトニングトークではフリーランスのオープンソースプログラマであり、DBFluteのメインコミッタでもある久保雅彦さん（写真）がDBFluteをアピールしました。

　DBFluteを端的に説明すると、「DB設計者にもうれしいO/Rマッパ」だそうです。ただ、O/Rマッパを乱用されるとパフォーマンスに悪影響を及ぼしかねないので、データベース管理者からすると「えーやめてー」と忌避されがちです。しかし、DBFluteはデータベースの変更に強いという特徴があります。カラムの追加など、データベースの変更履歴を自動生成し、開発環境にスムーズに反映させることができます。それゆえにプログラマには当然のこと、管理者にも役に立つO/Rマッパと言えます。

　また久保さんは「データベース設計には国家資格はない」ため、医者や弁護士のように資格を取得してから仕事に就けるものとは違い、経験を積みながら成長していくものだと話していました。そのため、「こういった勉強会に出席することが大事」と言い、参加者から喝采を浴びていました。ライトニングトークは後3枚というところで時間切れ。惜しかったです。

データベースの達人ミックさんがClubDB2に登場

　ClubDB2のメインパートは、ミックさんの「達人が語る こんなデータベース設計はヤダ！」でした。ミックさんは「達人に学ぶ DB設計徹底指南書」などデータベース関連書籍（写真）を著していることで有名です（来年新刊発行の予定あり）。

　そのミックさんが講師として登場することもあり、事前に申し込みを締め切るほどの人気でした。

　普段のミックさんはSIer勤務で、性能設計やチューニング、時にはプロジェクトの火消しに出動することもあるそうです。経験に基づいた解説を温厚な様子で話しながら、時にどきっとするような鋭いタイトルをプレゼン画面に混ぜて聴衆を惹きつけます。

　例えば、物理設計の話題では「サイジングでCPUしか見ないやつ、一歩前に出ろ」。

　もちろん、本当に出席者を前に出させるようなことはしません。ここでは「サーバのサイジングではCPUに比重が置かれることが多い」という話をしていました。これがアプリケーションサーバなら妥当と言えるでしょう。「しかし、データベースサーバの性能を決めるのは、（アプリケーションサーバとの比較で）相対的にストレージ。大抵はストレージがネックになってしまいます」とミックさんは指摘しました。

　ストレージのサイジングについては、いろいろと話が出ましたが、最近では「オンメモリに」という流れになってきています。その背景は、ディスクの回転数をこれ以上上げるのは簡単ではありませんし、メモリが安価になってテラバイト級のメモリを搭載するサーバも出てきました。SSDも実用化されていることが大きいようです。

　実際こんな話もよく耳にします。「近年ではソフトウェアでチューニングを熱心にやるより、データを全部オンメモリにできるほどの大容量メモリを購入したり、SSDを購入してデータをHDDではなくSSDに格納できるようにした方が、よっぽど少ない手間で性能を劇的に改善できる」など。そんな情勢にミックさんが冗談を交えて一言。

　「ディスクに触ったら負けかなと思っている」

　（それだけ今はメモリやSSDの効用が大きいので、そちらにも目を向けましょうという意味です）

　次に論理設計では「手続き型の呪い」。これもまたぞっとするタイトルです。これはSQLを扱う上で重要な考え方を指摘していそうです。これに気づかないうちは「呪われている」のです。

　ミックさんは「ループが便利すぎて困る」と苦言を呈していました。

　データベースでは「カーソル」を使ってデータを操作できます。よくあるのがループさせて使うケース。当日は「ぐるぐる系」と呼ばれていました。こうした処理は手続き型言語と発想が似ているため、プログラミングで多用されがちだそうです。しかし、パフォーマンスで行き詰まりを起こしやすい側面があります。

　なぜ、ぐるぐる系は良くないのか。

　理由の1つに、ぐるぐる系だと「直列的にしかデータにアクセスできないため、並列アーキテクチャにしても、その良さを生かせなくなってしまうから」とありました。その代わり「がつん系」、テーブルからデータをまとめて取得して操作すると、同時並行にアクセスできるため、並列アーキテクチャの良さを生かせるようになるということでした。

　ここで言う「呪い」とは、手続き型言語の感覚でSQLを扱ってしまうことです。なぜ人はSQLをループさせたがるかという理由について、ミックさんは多くが「テーブルをファイルだと思っている」と分析しています。一般的なプログラミング言語（手続き型言語）とは対照的に、RDBは集合論が基になっています。データを「がつん」とつかむように発想を変えるのが大事、と指摘していました。

　当日はQ＆Aの時間を多くとり、設計に関する「トレードオフ」など深く有意義な議論が多く交わされました。資料はこちらで公開されています。