TOP>企業情報>コラム>技術情報>PostgreSQL9.3 新機能を検証してみた Vol.2

PostgreSQL9.3 新機能を検証してみた Vol.2

前回は、PostgreSQL 最新バージョン 9.3の新機能の中からエンタープライズ領域の注目すべき機能について紹介しました。今回も引き続き、開発・運用面において、注目すべき機能をさらに詳しくお届けします。

(全2回連載)

Vol.2 PostgreSQL9.3 開発と運用を支える新機能

PostgreSQLデータベース間のスムーズなデータ連携を実現するpostgres_fdw


開発面で注目すべき機能としてpostgres_fdwをご紹介します。

PostgreSQL 下位バージョンではデータベース間のデータ連携機能としてdblinkモジュールが提供されていましたが、postgres_fdwはその後継機能にあたり、PostgreSQL 9.3ではcontrib配下に含まれる形式で提供されています。

postgres_fdwでリモートデータを連携するステップは以下の通りです。1度設定してしまえば、その後はローカル表と同じようにリモート表にアクセスできます。

  1.CREATE EXTENSIONコマンドでpostgres_fdwモジュールを読み込み
  2.CREATE SERVERコマンドで接続先のデータベース情報を定義
  3.CREATE USER MAPPINGコマンドで接続先のユーザ情報を定義
  4.CREATE FOREIGN TABLEコマンドでリモート表をローカル側に定義

※手順2および3がOracle DatabaseのCREATE DATABASE LINKコマンドに相当します。

図1:postgres_fdwの利用

図1:postgres_fdwの利用

postgres_fdwはdblinkと比べてどのような特徴をもっているのでしょうか。ここでは主な特徴を2つご紹介します。

1.SQLにローカル表と同じ形式でリモート表を記述できる


例えば、リモートにあるsup_log表に対してpostgres_fdwとdblinkそれぞれを利用してSELECT文を実行する例を見てみましょう。

図2:postgres_fdwとdblinkの利用

図2:postgres_fdwとdblinkの利用

dblinkを利用した場合、図8のようにSELECT文の中でdblink関数を呼び出す形で接続先のデータベース名などの情報を付加してリモートのsup_log表にアクセスする必要があります。

一方、postgres_fdwを利用した場合、SQLにローカル表と同じ形式でリモート表を記述します。postgres_fdwでは特殊な構文を習得する必要がないため、アプリケーション開発の難易度を低減することができます。

2.結合処理の際、データ転送量を抑制できる


これは、特にローカル表とリモート表を結合し、さらにローカル表の特定データを元にリモート表から行データを絞り込む場合に効果を発揮します。

dblinkでは、図3のようにリモートのsup_log表のデータをすべてローカルに転送してから結合処理やWHERE句による絞り込みを行う必要があり、表によっては大量のデータを転送することになります。

図3:dblinkによるリモート表からのデータ取得

図3:dblinkによるリモート表からのデータ取得

一方、postgres_fdwはローカルにある表の行データを条件にリモートにある表データを絞り込むことができます。図4のようにローカルにあるcust表の特定データを元にリモートにあるsup_log表の必要なデータを事前に絞り込みます。

図4:postgres_fdwによるリモート表からのデータ取得

図4:postgres_fdwによるリモート表からのデータ取得

postgres_fdwとdblinkそれぞれの実行計画を見てみましょう。

図5のようにdblinkではFunction Scan on dblinkという計画タイプが選択され、リモートにあるsup_log表の50万件すべてのデータを読み込んでいることが分かります。

一方、postgres_fdwではForeign Scanという計画タイプが選択され、sup_log表にアクセスしていますが実際に読み込んだ行数はわずか6件です。これにより所要時間に約4倍もの差が出ていることが分かります。このように、postgres_fdwを利用することで処理によってはリモートから転送するデータを必要最小限に抑えることができるため、ネットワークへの影響を軽減し、さらに処理速度を向上させることができます。

図5:postgres_fdwとdblinkにおける実行計画の違い

図5:postgres_fdwとdblinkにおける実行計画の違い

その他の特徴として、postgres_fdwではリモート表に対するANALYZE処理をローカル側で明示的に実行すると、その統計情報をローカル側に保有できます。そのため、ローカル側で行われる結合や集計処理の実行計画をローカルのプランナが最適化できるのも利点の1つです。

以上のように、Materialized Viewとpostgres_fdwを組み合わせることで今まで以上にリモートからのデータ連携がスムーズに行えることがわかります。

迅速な障害対応を可能にするデータページチェックサム


運用に関連する新機能としてデータページチェックサムをご紹介します。

データページチェックサムは商用RDBMSでは従来から実装されている機能で、表や索引のデータ破損を検知する仕組みです。

PostgreSQL 9.2までは、図6のように表や索引のデータが格納されたページのヘッダ部分が破損した場合のみ検知できるというものでした。そのため、ページ内の行データの破損に気づかない状態のまま運用を継続してしまうリスクがありました。

図6:9.2までのページ破損の検出

図6:9.2までのページ破損の検出

PostgreSQL 9.3のデータページチェックサム機能はオプションとして実装されており、データベースクラスタ作成時に「-k」オプションをつけることで有効になります。

チェックサムの値は、図7のように共有バッファ上のバッファをディスクへ書き出す際にページの内容をもとに算出され、ページヘッダに格納されます。ページを読み込む際は、そのチェックサムの値を再計算しヘッダに格納されている値と一致しているかどうかを比較することで障害や破損が発生していないかを判断しています。

破損を検知すると表の物理ファイル番号、対象ブロック番号、チェックサムの値が警告(WARNING)のエラーレベルで表示されます。

図7:チェックサムによるページ破損の検知

図7:チェックサムによるページ破損の検知

尚、破損からの復旧は図8のように「zero_damaged_pages」パラメータを一時的に有効にして、破損データが含まれるページをスキップします。このパラメータは下位バージョンから提供されており、破損データが含まれるページを読み飛ばすためデータが一部欠損する可能性がありますが、それ以外の正常なページに格納されたデータを救出することができます。

図8:ページ破損からの復旧

図8:ページ破損からの復旧

弊社が行った検証では、コールセンターを想定した弊社独自のアプリケーションを利用してOLTP系処理を実行し、データページチェックサムの設定有無によって性能へどの程度影響が及ぶかを確認しました。処理内容は、一意検索によるSELECTおよびUPDATE、DELETE、INSERTなど一連のSQLを含むトランザクションです。

本アプリケーションで同時接続数1,250という高負荷な状況下で処理を実行したところ、図9のようにデータページチェックサム機能の設定有無による性能差異はありませんでした。更新処理の多寡にもよりますが、データページチェックサム機能を有効にした場合のオーバヘッドは軽微なものと言えます。

図9:データページチェックサム有効時の性能影響

図9:データページチェックサム有効時の性能影響

障害発生時に迅速に対応できるという運用面を考慮すると、データベースクラスタを作成する際はデータページチェックサム機能を有効にすることをお勧めします。

PostgreSQLの可用性を支えるストリーミング・レプリケーション


PostgreSQL 9.0で実装されたストリーミング・レプリケーションは、変更履歴が格納されたWALを操作単位でマスタ・サーバからスタンバイ・サーバへ転送することで可用性と負荷分散を実現する仕組みです。PostgreSQL 9.2からは図10のように2台目のスタンバイ・サーバが1台目のスタンバイ・サーバにぶら下がるカスケード・レプリケーションと呼ばれる構成を組むことでマスタ・サーバの負荷を抑制することもできるようになりました。

図10:カスケード・レプリケーション

図10:カスケード・レプリケーション

以降では、運用の観点からPostgreSQL 9.3でのストリーミング・レプリケーションの新機能をご紹介します。

PostgreSQL 9.3ではタイムラインIDの追従と呼ばれる機能が実装されました。この機能により、マスタ・サーバに障害が発生した後のレプリケーション再構成の作業を簡略化できるようになりました。

本来、タイムラインIDはPoint In Time Recovery(PITR)を実現するために実装された仕組みで、PITRが実行されるたびに値が1ずつ大きくなります。例えば、図11のようにタイムラインID「1」で取得したベースバックアップをもとにリカバリした場合、リカバリ後はタイムラインID「2」上で処理が継続します。

図11:PITRとタイムラインIDの関係

図11:PITRとタイムラインIDの関係

ストリーミング・レプリケーションを利用した可用性構成ではスタンバイ・サーバはリカバリモードで待機しているため、マスタ・サーバに障害が発生してフェイルオーバし、スタンバイ・サーバがマスタ・サーバに昇格する際、PITRの場合と同様にスタンバイ・サーバのタイムラインIDの値は1つ大きくなります。

例えば、サーバ3台によるカスケード・レプリケーション構成の場合、マスタに障害が発生してスタンバイ・サーバ1が新マスタ・サーバに昇格した後、従来のスタンバイ・サーバ2と新マスタ・サーバ間でレプリケーション構成を再構築する必要がありますが、スタンバイ・サーバ2のタイムラインIDを新マスタ・サーバと同じ値に揃えない限り再構成ができません。PostgreSQL 9.2までは、ここで図12のように新マスタ・サーバのベースバックアップをスタンバイ・サーバ2へ適用する必要がありましたが、PostgreSQL 9.3からはタイムラインIDの追従によりその作業が不要になりました。

図12:レプリケーション再構成時のタイムラインID

図12:レプリケーション再構成時のタイムラインID

タイムラインIDの追従に関する内部動作について、もう少し見ておきましょう。

図13のように、PostgreSQL 9.2まではスタンバイ・サーバ1が新マスタ・サーバに昇格すると従来のスタンバイ・サーバ間でWAL転送を受け持っていたwal senderプロセスとwal receiverプロセスが消失してしまい、スタンバイ・サーバ2でタイムラインIDが不適合というエラーが発生し自動的な再構成ができませんでした。

PostgreSQL 9.3では、タイムラインIDの追従によりwal senderプロセスとwal receiverプロセスが消失することなく両プロセス間でタイムラインIDの情報が格納された.historyファイルをフェッチしスタンバイ・サーバ2へ転送するため、自動的にタイムラインIDの値を上げることができます。

図13:タイムラインID追従に関する内部動作

図13:タイムラインID追従に関する内部動作

タイムラインIDの追従のもう1つの効果として、フェイルオーバに加えて図20のようにメンテナンス作業などで計画的にマスタ・サーバとスタンバイ・サーバを切り替えるスイッチオーバやスイッチバックも簡単に行えるようになりました。

このように、タイムラインIDの追従により、障害復旧後のレプリケーション再構成やメンテナンスのオペレーション負荷を大きく抑え、運用性の向上を実現しています。

図14:メンテナンスオペレーションの負荷抑制

図14:メンテナンスオペレーションの負荷抑制

ストリーミング・レプリケーションのもう1つの新しい機能として、高速フェイルオーバ機能をご紹介します。

図15のように、PostgreSQL 9.2まではスタンバイ・サーバがマスタ・サーバとして起動する際、リカバリ後にチェックポイント処理を実施してからマスタ・サーバとして起動するという仕組みをとっていたため、チェックポイント処理によってはマスタ・サーバとして起動するまでの時間が長くなってしまう可能性がありました。

そこで、PostgreSQL 9.3ではリカバリが完了した時点でマスタ・サーバとして起動する仕組みに変更されました。省略されたチェックポイント処理は通常のチェックポイント処理としてバックグラウンドで実施されるためデータ不整合などの心配はありません。

図15:フェイルオーバ時の内部動作

図15:フェイルオーバ時の内部動作

弊社検証環境で、PostgreSQL 9.2と9.3の環境下で処理を実行中にフェールオーバさせ、スタンバイ・サーバがマスタ・サーバとして起動するまでの時間を計測したところ、図16のようにチェックポイント処理にかかる時間分だけPostgreSQL 9.3のほうが速く起動することを確認しました。PostgreSQL 9.3の可用性構成では、万が一障害が発生した場合でもスピーディなサービス切り替えが可能となっています。

図16:フェイルオーバ時間の比較(9.2 vs 9.3)

図16:フェイルオーバ時間の比較(9.2 vs 9.3)

PostgreSQL 9.4リリースにむけて


さて、2回にわたり、ご紹介したPostgreSQL 9.3の新機能の印象はいかがでしたか。「エンタープライズ領域でPostgreSQL使えるかも!」という印象を持っていただけたら幸いです。

近年、PostgreSQLのメジャーバージョンは年1回のペースでリリースされており、PostgreSQL 9.4は2014年9月ごろのリリースを予定しています。

PostgreSQL 9.4では、大規模なデータウェアハウス系システムで商用RDBMSのオプション機能として広く利用されているパラレルクエリや論理レプリケーションなどPostgreSQLの利用拡大につながる多くの機能実装が計画されています。また、Materialized Viewの高速リフレッシュも早期の実装が待たれる機能ではないでしょうか。今後も進化し続けるPostgreSQLにぜひご期待ください。

  • Postgres Plus は、EDB Postgres の旧製品名です。


高瀬 洋子(Youko Takase)

株式会社アシスト データベース技術本部

アシスト入社後、Oracle Databaseのサポート業務を経て、2009年よりPostgreSQL、EDB Postgresのサービス立ち上げに参画。「PostgreSQLなら高瀬に聞こう」と社内外から言ってもらえる存在となることを目標に日々活動。2014年4月よりイギリスに拠点を移し、PostgreSQL、EDB Postgresの啓蒙活動と顧客対応の後方支援を担当。

高瀬の紹介記事はこちら

連載記事一覧

関連製品/サービス


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る