PostgreSQL Conference 2012 に参加してきました！
PostgreSQL Conference 2012 に参加してきました！
いろいろと興味深い話が聞けてよかったです。
その中でも一番興味を持った項目が pgpool-II のオンラインメモリクエリキャッシュ
簡単にまとめると、pgpool-II 側で PostgreSQL に以前発行したSQLの
Fetch 結果をキャッシュし、キャッシュが有効であれば PostgreSQL か
らのデータの読み込みせずに pgpool-II 側でキャッシュからデータを返
すというもの。
キャッシュのバックエンドに使えるものは以下の二つ。
memcached をキャッシュとして使用するのは非常に興味深いです。
libmemcache を使用しているとのことで、libmemcache から使えるものであれば、例えば kumoFS でも問題ないとのこと。こりゃ便利！と思いましたが、もちろん制約がある。
以下のケースにおいてキャッシュクリアが正常に行われない。
pgpool-II のオンラインメモリクエリキャッシュでは、delete や update が流れた場合には、その対象の表のキャッシュをクリアし、新しい結果をセットする動作になっている。
しかし、これが cascadeつきのSQLであった場合には、キャッシュクリアされない。例えば、partition table を削除する際に drop table ... cascade 構文を実施した場合等がこれに該当する。
このようなSQLを実施すると PostgreSQL 側が自動で必要な table を操作し、削除してくため pgpool-II からしてみれば、勝手に PostgreSQL が動いて削除するものなんて検知しようがないよ。といったためです。
pgpool-II 側にキャッシュ対象の表を指定することもできるみたいですし、手動でのキャッシュクリアもできることを検討しているみたい。
うまく利用すれば、パフォーマンスはかなり期待できる。が、今度はmemcachedサーバの運用も+α必要となる。
実際に使えるようになるには、いろいろと悩ませる箇所も非常に多いと思う。
データベースの負荷を減らすには、スキーマをいくら効率が良いものにしても、SQLをいくら簡単なものにしてもアクセスが多いことが一番のネックになる。そのため、今までは、そもそもDBへのアクセス回数を減らすため、APサーバからDBへそもそもcallしないようにする。システムを作らなければならなかった。
そのためには、アプリケーション側でキャッシュを用意し、動作させる必要があり、開発管理運用が大変になっていったが、この pgpool-II の新機能をうまく利用することでアプリケーション側でのキャッシュは必要なくなるかもしれない。そうしたら、構成もシンプルになるし開発工数も減る。ハッピーだ。
Release Date は、2012年5月を予定している。
後日、PostgreSQL 9.2 の新機能についても記載したいと思います。
