PostgreSQL導入に向けての取り組み ～大規模システムへの適用を目指して～(4)
4. PostgreSQL の適用検討 -運用面-
本章では、運用面で着目する点について話を掘り下げて行きたいと思います。本番システム運用する際、システムをいかに安定して運用できるかが重要なファクタとなってきます。 ここでは、それを実現するために着目する点 4 つを紹介いたします。
4.1 運用面の着目点 1： 性能問題発生時の迅速な解析
PostgreSQL に関する性能問題が発生した際に状況を確認すると、解析に必要な PostgreSQL に関する情報が不足しているため、「問題の再現待ち」になってしまうケースも少なくありません。 これではお客様が求める「安定した運用」が出来ないことになります。
このような状況に陥らないために「pg_statsinfo」の 導入を推奨します。
pg_statsinfo は、性能解析に必要な情報を一元的にスナップショットとして取得し、ログとして蓄積することができるツールです。
例としてキャッシュヒット率を求める場合で説明します。
pg_statsinfo が未導入の場合は、全てのキャッシュ要求（heap_blks_read, heap_blks_hit の合計）に対しての heap_blks_hit の割合を求めるSQLを作成し、実行する必要があります。 また、キャッシュヒット率以外の情報を収集する場合にはその都度、SQL を作成し、個別に実行する必要があります。 pg_statsinfo を導入していれば、スナップショット取得時に収集されたログから性能レポートを生成する事により、図4.1-1 のようにキャッシュヒット率だけでなく、 性能分析などに必要となる様々な情報（テーブル毎の seq_scan 数や dead_tuple など）が一元的に収集できるようになります。
- 図4.1-1
pg_statsinfo は、NTT OSSセンタで開発した BSD ライセンスの OSS で、pgFoundry の1つのプロジェクトとなっています。 PostgreSQL 8.4 対応の pg_statsinfo からは、処理時間の長い SQL や関数の分析も可能となっており、今後さらに改善が期待できるツールと言えます。
pg_statsinfo を導入することにより、性能解析に必要な情報を確実に収集でき、収集した情報の分析も容易にできることから、運用管理の効率化を図ることができますので、ご検討ください。詳細については以下のアドレスを参照願います。
リンク先： http://pgstatsinfo.projects.postgresql.org/index_ja.html4.2 運用面の着目点 2： 運用中の実行計画変更リスクへの対処
そもそも運用中に実行計画が変わることをリスクと思わない方もいると思います。 「オプティマイザが統計情報から適切な実行計画を策定しているため、データが変われば適切な実行計画も変わって当然」という考え方は コストベースオプティマイザを採用しているデータベースとしては極めて当たり前のものです。
しかし、運用途中に突然オプティマイザが最適な実行計画を選択しなくなり、レスポンスが悪化してしまった場合への対処方法を検討することは、 システムの安定運用を実現するために重要だと考えています。
統計情報の再取得（ANALYZE の実施）や、サンプリング係数の調整（default_statistics_target の調整）などの対策で意図した実行計画が得られれば問題ありませんが、 期待した実行計画が得られない場合、実行計画自体を制御したいケースも場合によっては発生します。 そのような場合に備え弊社では主に以下の 2 つの対応を検討しています。
(1) SQL 書き換えでの実行計画の制御
図4.2-1 にあるように、検索条件の列にキャストや計算式を付与することで、今使用されている索引スキャンの代わりに意図的に他の索引や表スキャンを使用させることができます。 その際、演算には結果に影響の無いものを使用します。
- 図4.2-1
図4.2-2にあるように、「enable_*」という設定パラメータを指定し、オプティマイザに対して特定の処理の使用可否を設定することで、実行計画を制御できます。 ただし、パラメータ設定時の影響度を最小限にするため、該当トランザクションに限定した「SET LOCAL」で設定する必要がある点にご注意ください。
- 図4.2-2
(2) 統計情報の凍結やバックアップによる制御
図4.2-3 にあるように、適切な実行計画が得られている時点で統計情報を固定し、実行計画そのものが変わらないように制御する方法と、 統計情報をバックアップして万が一の場合に以前の統計情報に戻すことで実行計画を制御する方法が考えられます。
しかし、現時点でこの機能を提供するPostgreSQLツールはありません。そのため、弊社では、利用者側の工夫として独自にツールを作成し、統計情報を固定する方法で対応しました。
- 図4.2-3
ここでは 2 つの対処方法を紹介しましたが、これらの対処はあくまでも最終手段で、 まずは SQL チューニング・設計の見直しなどによる対処を検討した上で、補完的な対策としてこれらの方法の利用を検討するようにしています。