技術情報
PostgreSQL に関する FAQ
PostgreSQL についてよく聞かれることとその回答です。 回答には、弊社の PostgreSQL サービスのご利用案内もあります。
目次
- PostgreSQL とは？
- PostgreSQL の読み方は？
- PostgreSQL の稼働可能プラットフォームは？
- PostgreSQL でアプリケーションを作る場合、どんな言語が使用可能？
- PostgreSQL で日本語は使用可能？
- 日本語で書かれた書籍や情報は？
- 帳票出力は？
- 1000 万件の参照用サーバに PostgreSQL を適用することは可能 (PostgreSQL の最大値)？
- バックアップ機能は？
- リカバリ機能は？
- 商用データベースと比較してパフォーマンスは？
- SMP だとパフォーマンスは上がる？
- PostgreSQL にバグがあった場合は？
- PostgreSQL のお勧めのバージョンは？
- 古いバージョンの PostgreSQL をバージョンアップするときの注意点は？
- 更新削除が頻繁にある 24 時間 365 日連続稼働システムで、PostgreSQL は使用可能 (VACUUM)？
- PostgreSQL を利用したシステムの開発中に、疑問や問題が発生した場合は？
- PostgreSQL のインストールや使い方、運用管理の習得方法は？
- PostgreSQL を使用したシステムを運用中、万一トラブルが発生した場合は？
- PostgreSQL にデータローダツールは？
- レプリケーションやクラスタリング機能は？
- トランザクション機能は？
- Oracle のストアドプロシージャに相当する機能は？
- トリガ機能は？
- 1. PostgreSQL とは？
-
PostgreSQL は、商用データベースと同等かそれ以上の機能、信頼性を備えた本格的なオープンソースデータベースシステムです。 商用目的も含めて無償で利用でき、ソースコードもすべて公開されています。
PostgreSQL は、大学のデータベース研究プロジェクトから生まれました。 1980 年代中頃から 1990 年代中頃にカリフォルニア大学バークレイ校 (UCB) コンピュータサイエンス学科の Michael Stonebreaker 博士のグループにより開発された University POSTGRES が前身です。
PostgreSQL は、大学の研究プロジェクトを祖先とするため、コンピュータサイエンスの理論的な裏打ちがあるシステムです。
現在はインターネットを利用して、世界中のエンジニアのボランティアで開発維持されています。
- 2. PostgreSQL の読み方は？
-
スペルを見ただけでは読みづらいのですが、「ポストグレス」、「ポストグレエスキューエル」、「ポストグレスキューエル」、「ポスグレ」などと読みます。
- 3. PostgreSQL の稼働プラットフォームは？
-
PostgreSQL は他のベンダのデータベースと同様に、アプリケーションが動くクライアントとデータベースが置かれるサーバとで構成された、クライアントサーバアーキテクチャを採用しています。 PostgreSQL ではサーバ側をバックエンド、クライアント側をフロントエンドと呼びます。
PostgreSQL が動くプラットファーム (バックエンドならびにフロントエンド) は、PostgreSQL ソースファイルの INSTALL というファイルに稼働実績があり下記が挙げられています。
Linux、FreeBSD、Solaris、AIX、BeOS、BSD/OS、Tru64、HP/UX、IRIX、Mac OS X、NetBSD、OpenBSD、SCO UnixWare、Windows (PostgreSQL 8.0 以降)
バックエンドのプラットフォームとして、Windows を選択する場合には、Windows 2000、XP、2003 といった NT 系 Windows でなければなりません。
- 4. PostgreSQL でアプリケーションを作る場合、どんな言語が使用可能？
-
C、C++、Perl、Java、Tcl/Tk、PHP、Python、Lisp などが使えます。 また、日本語版 ODBC ドライバを使って Windows から PostgreSQL にアクセスすることも可能です。 詳細はインターウィズの 片岡裕生氏の Web ページ を参照してみてください。
「月刊オープンデザイン 2001 年 8 月号」に、ODBC、Perl、PHP、libpq (C 言語)、Java、Ruby から PostgreSQL にアクセスする記事があります。
- 5. PostgreSQL で日本語は使用可能？
-
はい、扱えます。 詳しくは、ソースコードに添付されている doc/README.mb.jp ファイルをご覧ください。 下記は、PostgreSQL 8.0 の doc/README.mb.jp ファイルからの抜粋です。
PostgreSQL におけるマルチバイトサポートは以下のような特徴を持っています．
- マルチバイト文字として，日本語，中国語などの各国の EUC，Unicode，mule internal code, ISO-8859-* がデータベース作成時に選択可能． データベースにはこのエンコーディングのまま格納されます．
- テーブル名にマルチバイト文字が使用可能
- カラム名にマルチバイト文字が使用可能
- データそのものにもマルチバイト文字が使用可能
- マルチバイト文字の正規表現検索が使用可能
- マルチバイト文字の LIKE 検索が使用可能
- character_length(), position(), substring() などの文字列関数でのマルチバイトサポート
- フロントエンド側のエンコーディングがバックエンド側と異る場合に，自動的にエンコーディング変換を行ないます．
- ユーザ定義のエンコーディング変換を作成可能．
- 6. 日本語で書かれた書籍や情報は？
-
書籍やコミュニティによる 日本語マニュアル、日本語メーリングリスト など、日本語で書かれた書籍や情報は充実しています。 また、PostgreSQL ソースファイルの doc/FAQ_japanese というファイルに日本語で書かれた FAQ があります。
ただし、最新バージョンの PostgreSQL を利用する場合でマニュアルが未翻訳の場合などは、英文マニュアルとなります。
- 7. 帳票出力は？
-
PostgreSQL はあくまでもデータベースですので、PostgreSQL 自体に帳票出力の機能はありません。 クライアントアプリケーション側で、ポストスクリプトファイルを生成して出力するなどの方法となります。
PostgreSQL には、大きな画像データやバイナリファイル扱うためのラージオブジェクトというものがあります。 それを使うことによって生成した帳票データを PostgreSQL に保管することも可能です。
- 8. 1000 万件の参照用サーバに PostgreSQL を適用することは可能 (PostgreSQL の最大値)？
-
はい、可能です。 しかし、ハードウェアの構成やテーブル設計により性能などは異なります。 PostgreSQL の最大値は下記のとおりとなります。
なお、実際にはメモリやディスク、OS の容量制限に依存します。
項目 最大値 1 つのデータベースの大きさ 無制限 (ただし、1 パーティションに収まる必要がある) 1 つのテーブルの大きさ 32 TB まで 1 つの行の大きさ 7.1 以上であれば無制限 1 つのフィールドの大きさ 7.1 以上であれば 1 GB まで 1 つのテーブルの行数 42 億個以内 (ただし、7.2 以上であれば無制限の指定が可能) 1 つのテーブルのカラム数 1600 1 つのテーブルのインデックスの数 42 億個以内 PostgreSQL はデータベースのサイズを見積もってデータベース用の領域を事前に確保する必要はありません。 データベースの大きさはデータベースが置かれているファイルパーティションの空き領域の大きさに依存します。 したがって PostgreSQL は日常の運用の手間は比較的少なくて済みます。 VACUUM の説明 も参照してください。
- 9. バックアップ機能は？
-
データベースを運用したままのバックアップ、つまり、ホットバックアップが可能です。 バックアップには pg_dump という PostgreSQL 専用バックアップツールを使います。 バックアップ中にデータの更新や削除ももちろん可能です。 データベースクラスタ全体、データベース単位、テーブル単位にバックアップが可能です。 なお、ラージオブジェクトやオブジェクト ID (OID) を使用している場合は、pg_dump に適切なオプション (-b -Fc -o など) を指定する必要があります。 また、バックアップ中でも、さほどパフォーマンスへは影響ありません。
PostgreSQL 8.0 以降では、前回バックアップした内容からの差分バックアップ、特定時間までの巻き戻しが可能です。 しかし、バックアップ中にテーブルやインデックスの生成や削除は行えません。 また、VACUUM などの排他的なロックが必要な処理をバックアップ中に行うと、バックアップが待たされるなどの影響があります。 なお、各種設定ファイル (postgresql.conf ファイル) や PostgreSQL の起動スクリプトなどはホットバックアップの対象にはなりませんので、別途バックアップが必要です。 前述のホットバックアップ以外にデータベースのサービスを一旦正常に停止する必要がありますが、tar などの Unix ツールを用いてデータベースがあるディレクトリをバックアップする方法があります。
ちなみに、バックアップに要する時間の目安ですが、Pentium III 550 MHz、メモリ 256 MB のマシンにおいて、約 8 GB のデータベース (pgbench で作成、データ件数 500 万件) を PostgreSQL 7.3 の pg_dump -Fc で SCSI 接続された AIT ドライブにブロックサイズ 1 MB でバックアップした場合、46 分ほど掛かりました。 また同じデータを pg_restore でリストアした場合、58 分掛かりました。 なお、このときに実際にテープに書かれたデータ量は約 270 MB でした。
- 10. リカバリ機能は？
-
リカバリには、おもに下記のケースがあります。
トランザクション中にユーザの SQL 文に間違いがあった場合 PostgreSQL はそのトランザクションをロールバックします。 トランザクション中にフロントエンドプロセスが異常終了した場合 PostgreSQL はそのトランザクションをロールバックします。 トランザクション中に PostgreSQL サーバマシンが停電などで停止した場合 次に PostgreSQL を起動したときに PostgreSQL が自動的に異常状態検知して、しばらくの間リカバリモードとなった後に、サービスが開始されます。 異常終了したトランザクションはロールバックされます。 PostgreSQL の処理としては正常だが、業務的には誤ってデータを更新してしまった場合 PostgreSQL 8.0 以降では、ある時点に回復させるポイントインタイムリカバリ機能を使用してリカバリを行うことができます。 - 11. 商用データベースと比較してパフォーマンスは？
-
データベースベンダによっては、ベンチマークデータの公開を許していないため、比較したベンチマークのデータは公開していません。 実際には、PostgreSQL の性能が極端に劣るというケースは見付かっていません。 商用データベースをよりも勝るケースもままあります。
ケースにより異なりますので、個別にご相談いただくようお願いします。
- 12. SMP だとパフォーマンスは上がる？
-
SMP (複数の CPU で処理を分担させるマルチプロセッサ手法) を用いることにより即座に PostgreSQL のパフォーマンスが向上するとは限りません。 様々なケースで試してみると、更新系は 2 CPU の方が勝るが、参照系は 1 CPU の方が 2 CPU よりも勝るといったケースや、その逆のケース (Linux の場合) もあります。
同時接続ユーザ数などにより結果は異なりますので、TPC を用いた性能評価を実際に行ってみるといいです。
- 13. PostgreSQL にバグがあった場合は？
-
PostgreSQL の開発はボランティアベースで行われており、メジャーバージョンアップを行う前にしばらくの間の Release Candidate 期間を経て、正式リリースされます。 開発中のソースコードやドキュメントは CVS というバージョン管理ツールで管理されており、Release Candidate 期間より前の開発中のものも含めて最新の状態がインターネットを通じて常に公開されています。
PostgreSQL は規模が大きなシステム (8.0 の場合、C 言語で約 72 万ステップ) ですので、バグがゼロということはあり得ませんが、発見されたバグに対しては、ほとんどの場合すぐにパッチファイルという形でメーリングリスト上でアナウンスされます。 また、弊社 サポートプログラム の会員の方には、情報配布サービスで最新のバグ情報をお知らせしております。
- 14. PostgreSQL のお勧めのバージョンは？
-
大幅なパフォーマンス改善ならびに機能追加がなされた 8.0 が 2005 年 1 月にリリースされました。 最新バージョンは 8.0.3 です。 詳しくは PostgreSQL 8.0.3 に関する技術情報 をご覧ください。
7.4 系、7.3 系は、それぞれ 2003 年 12 月、2002 年 11 月にリリースされました。 7.4 系、7.3 系はリリース後しばらく経っているため運用実績が多くあります。
7.2 系やそれ以前のバージョンも使うこともできますが、性能や安定性の点で現在のバージョンに比べて劣る面があり、弊社ではお勧めしていません。
- 15. 古いバージョンの PostgreSQL をバージョンアップさせるときの注意点は？
-
PostgreSQL に限らず、実際のシステムでは、1 度システムを作ってしまうとなかなかバージョンアップができなくなります。 PostgreSQL の場合は、小数点以下 1 桁までがメジャーバージョン番号で、少数点以下 2 桁がマイナーバージョン番号です。 メジャー番号が同じでマイナーバージョンが 1 番大きく、さらに、リリースされたパッチをすべて適用しているバージョンが最も安定していると考えられます。
- メジャーバージョン番号が変わると
- 例えば、PostgreSQL 7.4.8 と PostgreSQL 8.0 では小数点以下 1 桁目までが異なるので、メジャーバージョンが違います。 メジャーバージョン番号が変わるとデータベースのフォーマットが変わります。 メジャーバージョンアップを行う場合、pg_dump や COPY コマンドでデータベースを再ロードする必要があります。 また、プロトコルが変更されますので、クライアントプログラムの再検証や変更する必要があります。
- マイナーバージョン番号が変ると
- PostgreSQL 8.0 と 8.0.3 はマイナーバージョン番号が異なります。 8.0 のように、小数点以下 2 桁目がないバージョンはマイナーバージョン番号は 0 と見なします。 マイナーバージョン番号はおもにバグ修正のために使われます。 つまり、マイナーバージョン番号が大きいものがより安定しているといえます。 また、リリース後に見付かったバグの修正はパッチファイルで提供されます。 そこで、メジャー番号が同じ PostgreSQL は、マイナーバージョンが 1 番大きく、さらに、リリースされたパッチをすべて適用しているバージョンが最も安定しています。
変更点の詳細はソースファイルの HISTORY というファイルにあります。 オフィシャルではありませんが、ftp://ftp.sra.co.jp/pub/cmd/postgres/ でパッチファイルをまとめています。
- 16. 更新削除が頻繁にある 24 時間 365 日連続稼働するシステムで PostgreSQL は使用可能 (VACUUM)？
-
7.2 より前のバージョンの PostgreSQL では VACUUM 中にテーブルが高いレベルでロックされます。 ロック中はクライアントプログラムが待たされます。 そこで、更新処理が頻繁に発生し、しかも、24 時間 365 日連続稼働するシステムに PostgreSQL を使う場合に問題がありました。
しかし、PostgreSQL 7.2 以降は VACUUM 中も更新が可能となりましたので、前のバージョンと比べて連続稼働が可能な時間がとても長くなりました。
PostgreSQL ではデータ更新・削除の際、データを追記します。 つまり、データを更新した場合、元のデータは残したままデータを追記し、削除は、実際に削除するのではなく、削除フラグを立てるという方式です。 したがって、頻繁に追加更新処理を繰り返すとデータベースファイルが増大していきます。 このことを解消するために、VACUUM という SQL コマンドを定期的に実行して不必要になった領域を再利用可能とする必要があります。 また、VACUUM を行うことにより、性能を向上させる (性能の低下を抑える) ことができます。 VACUUM は PostgreSQL 7.2 以降と 7.2 より前のバージョンで大きく異なります。
- 7.2 以降の VACUUM
- VACUUM 中もフロントエンドからデータの更新削除ができます。 つまり、データベースを停止させる必要はありません。 VACUUM を行ってもデータベースファイルのサイズは小さくはなりませんが、不要となった領域は再利用可能となります。 定期的に VACUUM を行うことにより、データベースファイルのサイズの増大を抑えることができます。 VACUUM コマンドに FULL というオプションを付けると、下記に示す 7.2 より前の VACUUM と同様となります。 ただし、VACUUM を行ってもインデックス領域はさほど小さくはなりません。
- 7.2 より前の VACUUM
- 不要な領域を削除し、データベースファイルのサイズを小さくします。 VACUUM を行っている間、そのテーブルはクライアントからの更新や参照はできなくなり、VACUUM が終わるまで実行を待たされます。
- 17. PostgreSQL を利用したシステムの開発中に、疑問や問題が発生した場合は？
-
下記の方法があります。
- 書籍や PostgreSQL 付属のマニュアルで調べる。
- PostgreSQL のコミュニティのメーリングリストから過去に該当する問題が話し合われていないかを調べる。
- PostgreSQL のコミュニティ (メーリングリストなど) で相談する。 ただしご存じのようにコミュニティはギブアンドテイクが原則ですので、ご自分からの情報発信も必要となります。
- ソースコードが公開されていますので、ご自分でソースコードを調べる。
- 弊社の有償サポートを利用していただく。
業務アプリケーションを開発している場合、現実的には弊社の 有償サポート をご利用していただき、弊社担当窓口にお聞きいただくことが最も効率がいい方法と考えております。
- 18. PostgreSQL のインストールや使い方、運用管理の習得方法は？
-
書籍から学ぶ方法と有償トレーニングコースを受講する方法があります。 PostgreSQL 付属マニュアルにチュートリアルもあります。
PostgreSQL のインストールや使い方、運用管理を効率よく習得するためには、弊社の PostgreSQL 導入トレーニング、PostgreSQL 運用管理トレーニング をお勧めいたします。
また、弊社では、PostgreSQL 技術者認定試験 を運営しております。 PostgreSQL 技術者認定を受けることにより、PostgreSQL のスキルをアピールすることもできます。
- 19. PostgreSQL を使用したシステムを運用中、万一トラブルが発生した場合は？
-
この場合は、やはり有償になりますが弊社 サポート&保守サービス をご利用していただくことが最も安心できる方法となります。 弊社サポート&保守サービスでは、障害原因を調査して修正パッチのご提供や問題回避策のご提案をいたします。
- 20. PostgreSQL にデータローダツールは？
-
はい、あります。テキスト形式や CSV 形式により可能で、psql コマンドや pg_dump コマンドを使います。
- 21. レプリケーションやクラスタリング機能は？
-
高可用性や高信頼性を確保するため、今日のデータベースでは複数マシンでクラスタを構成してサービスを提供する機能を持っているものがあります。 これを実現するためにはデータ共有をする仕組みが必要で、ストレージを共有しない場合は通常レプリケーション (データ複製) という方法が使われます。
PostgreSQL 自体にはレプリケーション機能はありません。 しかし、PostgreSQL にレプリケーション機能を追加してクラスタリングを実現する様々なソフトウェアが存在します。 その内いくつかは、PostgreSQL ソースコードの contrib に含まれています。
以下のような方法があります。
- PGCluster
-
三谷篤氏による PGCluster はオープンソースのマルチマスタ方式の同期レプリケーションシステムです。 負荷分散やフェイルオーバーを実現し、データベースのノードを動的に追加することもできます。
弊社では PGCluster をもとにした製品 PowerGres Cluster を販売しております。
- pgpool
-
pgpool は石井達夫氏によるオープンソースの PostgreSQL 用コネクションプールサーバです。 レプリケーション機能を持っていて、フェイルオーバー用途に使うことができます。 データベースサーバとクライアントとの仲立ちをして、同じ問い合わせを 2 台のサーバに送ることで同期レプリケーションを実現します。
弊社の PostgreSQL/PowerGres サポート&保守サービス のゴールド契約以上では pgpool をサポートしております。
- Slony-I
-
Slony-I は、PostgreSQL の主要開発者 Jan Weich 氏を中心に開発されたオープンソースのシングルマスタ、マルチスレーブ方式の非同期レプリケーションシステムです。 故障したマスタの代わりに別のマシンを使うなど、非常に高機能なノード切り替えが可能です。
- DBMirror
-
DBMirror はソースコードの contrib/dbmirror に収録されている、マスタースレーブ方式のレプリケーションツールです。 データの自動バックアップとして利用することができます。
レプリケーションについては技術評論社のムック「レベルアップ！PostgreSQL 必須テクニックス」に記事があり、たくさんの実装例が紹介されています。
- 22. トランザクション機能は？
-
複数のユーザが同時に 1 つのまとまりのある一連の作業を行うとき、矛盾なくデータベースへ結果を反映しなくてはいけません。 このようなことを行う場合、意味のある一連の作業をトランザクションとしてまとめる必要がありますが、PostgreSQL のトランザクションは商用データベースと同等、あるいはそれ以上の機能があります。 PostgreSQL では、MVCC (Multi-Version Concurrency Conrol) という手法により、例えば、更新トランザクションを実行中に参照トランザクションが待たされることなく実行されます。 矛盾なく更新を行うためにはロック機能が必要ですが、PostgreSQL はテーブル単位のロックではなく行単位でロックします。 その点で PostgreSQL は同時実行制御に優れているといえます。
- 23. Oracle のストアドプロシージャに相当する機能は？
-
はい、あります。 Oracle の PL/SQL に相当する手続き言語として、PostgreSQL には PL/pgSQL があります。 PostgreSQL のドキュメントに「Oracle PL/SQL からの移植」という章があります。
- ユーザ定義関数
- PostgreSQL は多くの組み込み関数 (ビルトイン関数) があり、SQL92/SQL99 規格に沿った関数も多くあります。 ビルトイン関数以外に、ユーザ自身でユーザ定義関数を作成し、PostgreSQL バックエンドに登録することも可能です。 一旦ユーザ定義関数をバックエンドに登録すると、フロントエンドプログラムからビルトイン関数を使うのと同様にユーザ定義関数も利用できます。 ユーザ定義関数を利用することにより、フロントエンドとのデータの通信量を減らせたり、データと手続きをまとめるられるので、フロントエンドプログラムのインタフェースの抽象度を高めるられるなどの効果が期待できます。 ユーザ定義関数の記述言語としては、PL/pgSQL の他に SQL、C 言語、Tcl、Perl があります。 また、サードパーティで Python、Ruby なども使えます。
- ユーザ定義関数を使うときの注意点
-
- ユーザ定義関数でテーブルの更新処理を行う場合、直感とは異なるデータが参照される場合がありますので注意する必要があります。 詳細は ユーザ定義関数に関するノート を参照してください。
- PL/pgSQL やトリガのような機能を備えている商用データベースが多くありますが、これらは SQL 標準ではありません。 したがって、これらを使うとデータベースの移植性は悪くなります。
- PL/pgSQL 関数の中では、トランザクションに関する BEGIN、COMMIT、ABORT を使うことができません。 PL/pgSQL 関数を呼び出す側で、これらトランザクションに関する SQL 文を実行する必要があります。
- PL/pgSQL で、仮にフロントエンドでも可能な、データベース処理とは関係のない複雑な計算処理などを行った場合、バックエンドサーバマシンの負荷が高くなります。 この場合、フロントエンド側で行った場合と比較すると全体のパフォーマンスは低下する可能性があります。
- PL/pgSQL 関数はバックエンド側で動くため、PL/pgSQL のプログラムに無限ループのようなバグがある場合、データベースサーバ自体が無限ループに入ってしまいますので注意が必要です。
- ユーザ定義データ型
- PostgreSQL は SQL92 と SQL99 で定義された多くのデータ型が扱えます。 さらに、ユーザ自身で型を定義することも可能です。 複素数型を定義して利用することなども可能です。 ユーザ定義データ型は C 言語で記述します。
- 24. トリガ機能は？
-
使えます。 INSERT、UPDATE、DELETE などデータベースへの更新が行なわれたときにあらかじめ定義した関数を呼ぶ機能がトリガです。 例えば、あるテーブルが更新されたとき、あらかじめ作成しておいたログ用テーブルに更新ログ情報を INSERT するなどが可能です。 トリガの関数定義には PL/pgSQL と C 言語が使えます。