PostgreSQL導入に向けての取り組み ～大規模システムへの適用を目指して～(6)

5. PostgreSQL の適用検討 -コスト面-

本章では、コスト面で着目する点について話を掘り下げて行きたいと思います。PostgreSQL ではライセンス費用が発生しない点が、大きな魅力の一つです。 その一方で、注意しておく点もあります。ここでは2つの注意点について紹介いたします。

5.1 コスト面の着目点 1： 追記型であるが故にかかるコスト

PostgreSQL は追記型アーキテクチャを採用しているため、テーブル単位に不要領域が蓄積されます。 この「不要領域分のストレージコストと、VACUUM する際の I/O リソース」が非追記型 DBMS に比べ増加する傾向にあると言えます。 また、「不要領域がどれくらいになるのか、VACUUM の影響はどの程度か」などの検証や検討・設計コストも非追記型 DBMS ではかからないコストになると考えられます。

PostgreSQL 8.3 で HOT が導入され不要領域をそれほど意識する必要はなくなりましたが、 弊社では、データ量や更新量が多いシステムについては特に注意し、コスト算出の際に検討対象として取り上げるようにしています。

5.2 コスト面の着目点 2： 商用 DBMS からのマイグレーションコスト

弊社で扱っているシステムでは、ハードウェアの老朽化やソフトウェアの陳腐化に伴うシステム更改案件が数多くあり、 頻繁に商用 DBMS から PostgreSQL へのマイグレーション可否について検討を実施しています。

図5.2-1は、UNIX サーバ＋商用 DBMS からそのまま同じ製品の最新版へマイグレーションした場合のコストと、IA サーバ＋PostgreSQL へマイグレーションした場合のコスト例を示しています。 システム更改の場合、コストをいかに抑えるかということが重要になりますが、その際特に重要な点は、「システムで商用 DBMS 独自の機能を使用していた場合、 PostgreSQL で該当機能を実現させるコストがどの程度か」を、マイグレーションの検討段階で算出しておくことです（図の「増加コスト」の部分）。

図5.2-1

商用 DBMS 独自機能を使用していても、PostgreSQL に搭載されている機能で代替できる場合は掛かるコストをある程度低く抑えられますが、 そうでない場合、機能の検討・開発が必要となり、結果的にコスト増となりかねません。そのため、弊社ではマイグレーションの初期検討を特に重要視しています。

実際の事例としては、他システムとの連携部分で商用 DBMS の独自機能を使用していたため、 連携先システムへも影響が出てしまうことが課題として挙がり、PostgreSQL 適用を見送ったケースもありました。

6. まとめ

最後に、性能／運用／コスト面について総括します。

以上のように、弊社では特に PostgreSQL8.3 以降、システムへの適用範囲が広がっていることから、今後も PostgreSQL 導入を視野に入れて提案・開発を行っていきたいと考えています。

最後に、今後の PostgreSQL へ期待する事を3つ挙げさせていただきます。

(1) VACUUM を部分実行・一時停止できる機能

本番システムでは 1 テーブル数十 GB などの大容量テーブルを持つシステムも存在するかと思います。 現状では、大容量テーブルに対して VACUUM を実行すると数時間、場合によっては数十時間と長い VACUUM 処理時間が必要となります。 そのような場合、まとまった VACUUM 時間を確保できないシステムに対しては、PostgreSQL の適用が難しくなってしまいます。 VACUUM を部分実行する機能や、一時的に停止させる機能があれば、VACUUM 時間の制約を軽減でき、 また、VACUUM 実行中に PostgreSQL がダウンした場合、再起動後のクラッシュリカバリ処理の時間の短縮にも繋がりますので、 エンタープライズ領域での利用をさらに拡大できるのではないでしょうか。 実際に、弊社で扱うシステムでも、大容量テーブルを含むケースが少なくありません。

(2) データファイルの破損・改ざん検知機能

現在、データファイルが破損・改ざんされた場合、PostgreSQL 自体で検知する仕組みを持っていません。 より強固なデータベースとするためには、データファイルが破損・改ざんされたことを検知できる機能が必要と考えます。

(3) 監査機能の充実

より多くの本番システムへ適用していくためには、DBMS そのものの機能ではありませんが、監査機能の充実も重要なファクタとなると考えます。 4.4 節で紹介したような機能の拡充を期待します。

 

最後になりましたが、今後も PostgreSQL がさらに発展することを熱望いたします。