データベースの索引がイケてない話

以前、とある業務システムで検索スピードが要件を満たさずにリリースが延期されたという話を耳にしたことがあります。それを聞いた時、かつて少し関わっていた現場で、検索するとCPU負荷が100%に張り付くシステムや、ちゃんと動いていたのにある日を境に検索がタイムアウトするようになったシステムの存在を思い出しました。

この手の話はデータベースの索引が適切でないことに原因があることが多いのですが、データベース設計の教科書でも索引は基本的な単元であるにもかかわらずわりと良く聞く話でもあったりします。プログラムはゴリゴリ書けるけど、DB設計をきちんと学んだことが無い人が作っているという可能性もあるのですが、もしかしたらある程度きちんと機能する索引を付けるにはそれなりに経験を積んでセンスを磨く必要があるということなのかもしれません。

索引は検索キーやソートキーに付与するというのが基本ですが、複数カラムを指定して検索する場合にその索引が使われなければ、別途使われるような索引を付与するといったことをします。ただ、あまり索引を付け過ぎると更新処理のパフォーマンスが落ちるので、検索スピードが欲しい場合はマスタとは別に検索用のテーブルを用意することもよくあります。最初は普通に結合して選択していたものが、段々パフォーマンスが落ちてきたために途中で検索用テーブルを追加するといったことは別におかしいことではありません。

適切な索引が無ければどんなにSQLを効率的に記述してもパフォーマンスは出ませんし、また、基本的な索引は理論だけで行けるとしても、RDBMSの実行計画は実際にテーブルに格納されているデータの件数だけでなく内容によっても変わってきます。なので、もし絶対に止めてはいけないようなシステムの場合は、テストの段階で本番さながらのテストデータを使って本番さながらの件数を格納した上で動作を確認しチューニングする必要があります。

チューニングの作業は私は結構楽しいと思っていますけれど(例えばチューニングして検索スピードが10分の1になったら楽しくないですか?)、面倒くさいと感じる人はなるべくやらずに済ませたいと思ってしまうのでしょうか。


知らない本に出会えるビブリオバトル

去る15日にJSDGの東京ミニ研修会が開催され、参加してきました。今回の企画は事例発表でもワークショップでもなく、JSDG初の「ビブリオバトル」。ビブリオバトルというのは各自自分の好きな本についてプレゼンテーションを行い、どの本が一番読みたくなったかという観点の投票によりチャンピオンを決定するというものです。私もビブリオバトルという名前は聞いたことがあった程度でイメージがつかず今回は発表は敬遠したのですが、参加者の皆さんの発表がとても面白く、次回は私も発表してみたいと思いました。

今回参加者13名に対して発表者9名で、当然IT業界で働く方ばかりなのですが、持参された本は意外と文学などITとは関係のないテーマの本ばかりでした。発表者は5分(タイマーで管理されてました!)発表したあと簡単な質疑応答を行い、途中休憩をはさみながら9名が順次発表していきました。そして最後に投票と集計を行い、優勝者には賞状が贈られました。

単に本の紹介をしたのでは面白くなく、いかに読みたいと思わせるかを考えるところが面白いと思いました。中には本の内容ではなく本の装丁についてプレゼンテーションした方もおり、読みたいではなく持ちたいと思わせる本を紹介するという発想もありなのだなと、なにもルールに縛られることなく自分の好きな観点でアピールして良いのだなという点が面白いと思いました。

また、小説などはネタバレするかしないかギリギリのところの判断が問われ、ネタバレしてしまえば読まなくてもいいやって思うし、あまり披瀝しないと魅力が伝わらなかったりするので、その辺のさじ加減は難しいですね。でもそれぞれの発表者が熱い思いを語るのを聴くにつけ、本の世界にぐいっと引き込まれていく体験も得難いものです。