第5回: PostgreSQL安定運用のコツ2009、DBサーバーのパフォーマンスチューニング
PostgreSQLは使ったことも運用したこともほとんどないので端から端までわからないかなと思っていたのだけど、みんながよく言うVACUUM処理の原理的な必要性が理解できたし、統計系コマンドが充実していることを知ることができたのでとても良かった。スライドが判りやすくまとまっている。前提知識として頭に入れておけば、いつか本格的にPostgreSQLを使わなければならなくなったときにとても役に立ちそう。
MySQLは一番業務で利用しているRDB。SIerの頃はOracleだったけれども、今となってはMySQLの利用経験の方が多くなっている。
まだ最後の章が読み切れていないのだけど、Linux-DB システム構築/運用入門 (DB Magazine SELECTION)がとても良本なので（読み終わったら書くつもり）、松信さんの発表にとても期待していた。そしてその結果、とても勉強になったし、過去の自分のCREATE文に反省もした。
特に勉強になったと思うのは次の点（自分の意見も混じっているのはご了承ください）。
- パフォーマンスを考える上ではデータサイズを小さくすることが重要。印象に残ったのが、idをbigintにしているケースへの指摘。intなら4byte、bigintなら8byteなのは良く知られているけれども、なんとなく安心のためにintで済むところを4byte分太らせてbigintにしてしまうケースがあるのではないかと思う。本当に40億以上のレコードを1テーブルで扱うつもりか、というところで再考させられる。
- InnoDBでは列の768byteまでが行データ内に含まれる（768byteを超えると別の場所に配置される）ため、大きい列があるとそれだけ行の走査に影響が出る。この構造のために、SELECTでその列を指定していなくても走査に時間がかかってしまう。大きい列を毎回参照する必要がないのであれば、大きい列のみ別テーブルに移すことでパフォーマンスを向上させることができる。ただし、正規化を崩すことになるので必要でなければやらない方が良い。SELECTで列を指定しなくても影響がでるのは盲点だったし、このことからも行のデータサイズを小さくすることは重要だと思った。
- Covering Indexを活用する。取得したい列がすべてIndexに含まれている場合には、リーフだけで必要なデータが得られるので高速に結果を返すことができる（テーブルデータを参照する必要がないため）。O/Rマッパで全ての列を自動的に取得してしまっている場合は、ほぼCovering Indexが使えていないので、再検討の必要があると思った。
- InnoDBのbuffer poolは今まで時系列に「young領域 => old領域 => 破棄」されてしまうことがあったが、最新のInnoDB Pluginでは最適化されるようになり、最初はold領域に保存され一定時間経つとyoung領域に移動することが可能。これの恩恵として例えばバッチなどで大量データを読み込んだときにbuffer poolのデータが追い出されるのを防ぐことができる。
- メモリ重要。SSDに比べてもメモリはとにかく速い。当たり前のことなのだけど再確認。
アプリケーションからみて扱いやすいテーブルにすることは今までも特に気にかけていたのだけど、パフォーマンスを意識した設計は十分にできていなかった。パフォーマンスのためにアプリケーションがぐちゃぐちゃになるのは御免だけど、そうならない方法論も確認できたので、今後に活かしたい。