SQLで問い合わせを書けば、欲しいデータを持ってきてくれる。そんな夢のようなシステムが昨今のRDBMSです。SQL文で「何を取ってくるか」を指定すれば、検索の絞り込みも、順序の並び替えも、面倒な結合も何も考えなくていいのです。挙げ句の果てには、同時に同じデータにアクセスしても整合性を維持したりすることまでやってくれます。本当に便利なツールです。
そんなRDBMSは、かつては非常に高価なものでしたが、ここ最近はずいぶん気楽に利用できるようになりました。普通の開発者でも、
- （たいていはプログラムで）SQL文を作り
- それをRDBMSに投げてデータを持ってきて
- それをプログラムで加工して出力する
という使われ方はすっかり一般的になりました。
しかし一方で、便利なRDBMSを使うことによるトラブルも絶えないのが実情です。その中でも一番多く、且つ深刻なのが、
- 時間がたつにつれ問い合わせが遅くなった
- 特定の条件の時だけ非常に遅くなる
- システムの利用ユーザーが増えることで性能が悪くなってきた
といった性能面に関わるものです。こういうのは、まあ、いろんな理由があって発生するのですが、おおむね利用者の視点から見ると理解しがたいもの。まさに気まぐれ、まさに表題の通り「女心（男心）と秋の空」ならぬ「データベースと秋の空」が似合います。
SQL言語はその論理さえ理解すれば非常に簡単です。裏でどんな大変なことをしているのか知る必要はありませんし、むしろ基本的には積極的に利用者に見せないようになっています。これはわかりやすい反面、起こっている問題に非常に気づきづらいのです。だから中を知らないとRDBMSの行動は非常に気まぐれに見えます。
このような気まぐれが引き起こす問題の予防・対処には、RDBMSの立場に立って物事を考え、RDBMSの考えを理解するのが一番の近道だと筆者は考えています。RDBMSも所詮は人の作ったプログラム、理解すればその行動はだいたい予測の範疇になってきますし、予測から外れていても、ログ・計測データ・統計データなどの様々な情報源からデータベースの行動を読み解くことが出来るようになります。
本連載では、オープンソースであり、コードと構造が公開されているPostgreSQLを題材にして、RDBMSが本当は何を考えつつどう行動しているのかを読み解いていきます。幸い、ほかのRDBMSも似た構造を採用している部分も多く、考え方の根底は応用できるでしょう。
一見気まぐれなデータベースも、その本心を学べばもう掌握したも同然です！
