PostgreSQLのFAQ PostgreSQLについて良く聞かれることとその回答です。 回答には、弊社SRAのPostgreSQLサービスのご利用案内もあります。

目次 1. PostgreSQLとは? 2. PostgreSQLの読み方は? 3. PostgreSQLの稼働可能プラットフォームは? 4. PostgreSQLでアプリケーションを作る場合、どんな言語が使用可能? 5. PostgreSQLで日本語は使用可能? 6. 日本語で書かれた書籍や情報は? 7. 帳票出力は? 8. 1000万件の参照用サーバにPostgreSQLを適用することは可能?(PostgreSQLの最大値) 9. バックアップ機能は? 10. リカバリ機能は? 11. 商用データベースと比較してパフォーマンスは? 12. SMPだとパフォーマンスはあがる? 13. PostgreSQLにバグがあった場合は? 14. PostgreSQLのお勧めのバージョンは? 15. 古いバージョンのPostgreSQLをバージョンアップする時の注意点は? 16. 更新削除が頻繁にある、24時間365日連続稼働システムで、PostgreSQLは使用可能?(vacuum) 17. PostgreSQLを利用したシステムの開発中に、疑問や問題が発生した場合は? 18. PostgreSQLのインストールや使い方、運用管理の習得方法は? 19. PostgreSQLを使用したシステムを運用中、万一トラブルが発生した場合は? 20. PostgreSQLにデータローダーツールは? 21. レプリケーションやクラスタリング機能は? 22. トランザクション機能は? 23. Oracleのストアドプロシジャに相当する機能は? 24. トリガ機能は?

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