TOP
>
調査レポート
> pgpool
オープンソースの適用可能性を示す
第8回:PostgreSQLを使い切るためのノウハウを徹底解説する その2
著者:
SRA OSS 石井 達夫
2006/5/16
前のページ
1
2
3
pgpool
筆者が開発しているPostgreSQL用のシンプルなレプリケーションサーバだ。2台のPostgreSQLサーバに同じ問合わせを投げることで、DBの内容を同期させる。リアルタイムに同期するので、同期レプリケーションの一種ということになる。
pgpool
http://pgfoundry.org/projects/pgpool/
検索処理の負荷分散をサポートしているので、検索処理性能は通常のPostgreSQLの最大2倍にまでなる。一方、気になる更新処理でも、性能低下はSlony-IやPGClusterほどは大きくない。
またpgpoolでは、2台のDBサーバのうち、1台が故障すると自動的にそのサーバを切り放し、DBシステムを止めることなく運用を続けることができる。このように、可用性は高いといえるだろう。
ただし、故障したサーバを復旧させるには、一度システムを止めてDBの内容を事前に一致させておく必要がある。その他、一部のSQLで制限があるものがある。詳細はドキュメントを見てほしい。
HAやレプリケーションはそれぞれアーキテクチャがまったく異なり、またそれぞれに得意不得意がある(表1)。
PostgreSQL
HA
Slony-I
PGCluste
pgpool
可用性
×
○
△
○
○
費用
○
×
△
×
△
実績
○
○
△
△
△
移行性
○
○
△
△
△
検索性能
△
△
△
○
○
更新性能
○
○
△
×
△
フェールオーバー
×
○
×
○
○
負荷分散
×
×
×
○
○
耐ディスク障害
×
×
○
○
○
表1:レプリケーションソフトの機能・性能比較
開発への参加こそOSSの究極の活用法
PostgreSQLの究極の活用方法は、その開発自体に参加することだ。そうすれば、必要な機能を追加していくこともできるし、何よりベンダに頼らず自社でPostgreSQLをメンテナンスできるようになる。
もちろん、PostgreSQLをカスタマイズすることも可能だ。また、PostgreSQLの開発者が増えれば、PostgreSQL自体の進歩も加速され、自分達のメリットになる。
製造業などでは、DBに限らず、動いているソフトウェアをなかなか入れ替えることができない。例えば、やむを得ずOSをバージョンアップしたとする。するとその上で稼働しているソフトもバージョンアップが必要になる場合が多い。
その点OSSなら、再コンパイルだけで移行できる。仮にコンパイルできなくても、PostgreSQLの内部構造に対する知識があれば容易に対応できる。また、バージョンアップのリスクや、再テストの工数を最小限に抑えることも可能だ。
要員の育成のハードルが高いが、長い目でみれば大きなメリットがあるだろう。
できるだけ多くの方がPostgre-SQLの開発に参加して「究極のメリット」を享受できるようになることを期待したい。
参考文献
オープンソースソフトウェアのTCOガイド(2005年):日本OSS推進フォーラム
http://www.ipa.go.jp/software/open/forum/business/download/oss_tcoguide.pdf
ビジネスユースにおけるオープンソースソフトウェアの法的リスクに関する調査(2004年):日本OSS推進フォーラム
http://www.ipa.go.jp/software/open/forum/business/download/oss_risk.pdf
前のページ
1
2
3
著者プロフィール
SRA OSS,Inc. 石井 達夫
SRAを経て、現在はSRA OSS,Incの日本支社長として、日本でのOSSビジネスを推進する立場にある。個人的にもPostgreSQLの開発、普及活動に取り組んでおり、名実ともにPostgreSQLを最強OSSDBにするのが夢。主な著書は「PostgreSQL完全攻略ガイド」など。
INDEX
第8回:PostgreSQLを使い切るためのノウハウを徹底解説する その2
ミッションクリティカルな用途にPostgreSQLを適用する
Slony-I
pgpool