TOP>企業情報>コラム>技術情報>利用範囲がさらに広がる!Postgres Plus 9.4新機能の全容 Vol.1

利用範囲がさらに広がる!Postgres Plus 9.4新機能の全容 Vol.1

EDB Postgres

商用RDBMSと遜色ない機能を持ち、エンタープライズ用途での採用が拡がるPostgres Plusの最新バージョン9.4が、今秋のPostgreSQL 9.4リリースに追随する形で2014年11月にリリースされます。本連載では3回にわたり、エンジンであるPostgreSQLとともにPostgres Plus 9.4に実装される新機能の全容に迫ります。

Vol.1 エンジンPostgreSQLに組み込まれた注目機能解説

Postgres Plusへの高まる期待


Postgres PlusはPostgreSQLに未実装のエンタープライズ向け機能を強力に補完したRDBMSで、サブスクリプション・ライセンス形式で提供されています。開発元であるEnterpriseDB社にはPostgreSQL開発コミュニティの主要コミッタが複数名在籍しており、Postgres Plusに加えてPostgreSQL本体の開発にも積極的に参画しています。

EnterpriseDB社の特徴

図1:EnterpriseDB社の特徴

2014年7月17日に開催された国内初となるEnterpriseDB社主催「EnterpriseDB Summit Tokyo 2014」は、定員数を大きく超える250名以上の参加があり、Postgres Plusへの国内ユーザ企業の関心の高さが伺えるイベントとなりました。

イベントでは、Postgres Plus導入成功事例セッションとしてOracle Databaseが稼働するミッション・クリティカルなシステムをPostgres Plusに移行を進める韓国最大手の通信系企業Korean Telecom(以下、kt)社の事例が紹介されました。kt社は、Postgres Plusへの移行を決めた理由として、Postgres Plusが高い性能要件を問題なくクリアできたこと、EnterpriseDB社によって製品の品質が保証されていること、アプリケーション改修コストを含む全体コストが最も抑えられたことを挙げており、オープンソースであるPostgreSQLのメリットを享受しつつ、メーカーの存在という安心感とエンタープライズの要求レベルに応える機能の実装という3つがPostgres Plusの大きな魅力であると言えます。

Postgres Plus Advanced Server 9.4の進化


Postgres Plusのエディションの1つ「Postgres Plus Enterprise Edition(以下、PPEE)」のデータベースとして動作するPostgres Plus Advanced Server(以下、PPAS)は、コミュニティ版のPostgreSQLにセキュリティやパフォーマンスを向上させたRDBMSで、このPPASにデータベース管理・監視ツールや周辺データベースとのデータ連携機能、クラスタリング機能などのソフトウェア群を加えて構成されたものがPPEEです。そのため、PPAS 9.4にはエンジンであるPostgreSQL 9.4の新機能が含まれるのはもちろんですが、独自機能も数多く実装されています。

図2ではPPAS 9.4の主な新機能をカテゴリ別に紹介しています。エンジンであるPostgreSQL 9.4には性能、運用、可用性、DWH、開発などのカテゴリで新機能が実装されており、全体で120を超える機能拡張や追加、改善が行われています。またPPAS 9.4には、パーティション機能やリソース管理、データ連携機能など、さらに柔軟な使いやすさを目指したエンタープライズ向けの機能が追加される予定です。PostgreSQL、Postgres PlusともにOLTP系システムを中心に利用が拡大してきましたが、データウェアハウスやNoSQLの領域といったより汎用的なシステムでの利用を目指しています。

PPAS 9.4の主な新機能

図2:PPAS 9.4の主な新機能

今回は、PPASのエンジンであるPostgreSQL 9.4の新機能の中からエンタープライズでの利用を想定した注目すべき以下の機能をピックアップしてご紹介します。

  • 性能 - HugePage対応
  • 運用系 - ALTER SYSTEMコマンド
  • 可用性 - レプリケーション・スロット
  • DWH - マテリアライズド・ビューの拡張
  • 開発 - バイナリJSON

大容量メモリ環境向けのHugePage対応


PostgreSQL 9.4では大容量メモリ環境向けの機能として、待望のHugePage対応が組み込まれました。

メモリを安価に調達できる昨今、データベースサーバの搭載メモリは大容量化しており、数十GBを超えるケースも珍しくありません。これに伴いデータベースに割り当てるメモリ領域も10GB以上のサイズを指定するようになりました。しかし、以前から、Linux OS上でデータベースに割り当てるメモリ領域を数十GBとした環境下で、データベース処理中にシステムCPUが高騰し、OSハングするという問題が報告されていました。

データベース・プロセスが物理メモリ領域にアクセスする際、仮想メモリ機構の「ページ・テーブル」を経由してやりとりを行います。図3にあるように、1ページのデフォルトサイズは4KBであるため、例えば32GBの物理メモリの場合は800万ページもの膨大なページを管理しなければなりません。そのため、多数のデータベース・プロセスから同時にメモリにアクセスする処理を実施し、ページのメンテナンスが必要になるとページ管理を担当するOSプロセスがメモリマッピング処理遅延を引き起こし、結果としてシステムCPUが高騰し、OSがハングしてしまうのです。

システムCPU高騰による処理遅延問題

図3:システムCPU高騰による処理遅延問題

この問題を回避するためにHugePageと呼ばれる機能がLinuxカーネル2.6で登場しました。HugePageを使用するとカーネル・バージョンやハードウェア・アーキテクチャに応じてページ・サイズを2MBから254MBまで大きくすることができるため、ページ・テーブルの肥大を防ぐことができます。

Oracle Databaseでは、データベースに割り当てるメモリ領域を10GB以上とする場合にはHugePageの設定が強く推奨されています。

PostgreSQLではこれまでHugePageに対応しておらず、この問題を回避する術がありませんでしたが、PostgreSQL 9.4ではhuge_pagesパラメータによりHugePageが利用できるようになります。パラメータの値は「on」「off」「try」の3種類で、デフォルト値「try」はプラットフォームがHugePageに対応しているかどうかを検知し、サポートされている場合は使用します。

パラメータの値


データベース・パラメータの値を柔軟に変更可能なALTER SYSTEMコマンド


PostgreSQLには商用RDBMSと同様にデータベース・パラメータ群が提供されています。サーバログやアーカイブファイルの位置といったデータベース構成の設定や共有バッファ、WALバッファサイズといったメモリ設定などいくつものパラメータが「postgresql.conf」と呼ばれるパラメータファイルに記録されており、通常、図4のようにデータベースクラスタが起動されるタイミングでpostgresql.confのパラメータが読み込まれ、値が有効になります。

データベース・パラメータの適用

図4:データベース・パラメータの適用

PostgreSQL 9.3までは、データベース単位で変更を有効にする「ALTER DATABASE」コマンド、特定ユーザの接続のみ影響する「ALTER USER」コマンド、特定セッションやトランザクション単位で変更を有効にする「SET」コマンドのいずれかを使用してデータベース稼働中に値を変更することができましたが、データベースクラスタ全体で値を有効にしたい場合は、postgresql.confファイルを直接編集して、データベースクラスタを再起動する必要がありました。

PostgreSQL 9.4ではデータベースクラスタ全体で値を有効にするためのコマンドとして「ALTER SYSTEM」が追加されました。このコマンドを利用することでSQLレベルでパラメータの値を変更することが可能になったため、データベースの運用・管理が容易になります。

ALTER SYSTEM


ALTER SYSTEMの利用方法を見ていきましょう。

1. ALTER SYSTEMコマンドでチェックポイントの実行間隔とワークメモリを変更します。


チェックポイントの実行間隔とワークメモリの変更


PostgreSQL 9.4では、postgresql.confに加えてpostgresql.auto.confファイルが提供されており、ALTER SYSTEMコマンドを実行すると変更対象のパラメータと値がpostgresql.auto.confファイルに書き込まれます。

2. pg_reload_confファンクションで値を有効にします。


pg_reload_confファンクション


尚、ALTER SYSTEMコマンドで共有バッファやWALバッファの値も変更することはできますが、PostgreSQL 9.4ではデータベースクラスタの再起動が必要です。

また、データベースクラスタ再起動時はpostgresql.auto.confファイルが最初に読み込まれます。そのため、ALTER SYSTEMコマンドで有効にした値をpostgresql.auto.confファイルから削除するには「DEFAULT」を指定してALTER SYSTEMコマンドを実行します。

ALTER文


スケールアウト機能の強化を実現するレプリケーション・スロット


PostgreSQL 9.0で標準機能として実装されたストリーミング・レプリケーションは、変更履歴が格納されたWALを操作単位でマスタ・サーバからスタンバイ・サーバへ転送することで可用性を実現する仕組みです。

PostgreSQL 9.3までの環境では、バッチ処理のように1つのトランザクションで大量データが更新されると、チェックポイントなどによってスタンバイ・サーバへ転送する前にWALが削除されてしまい、ストリーミング・レプリケーションでのデータ同期が保持できないケースがありました。その状態を回避するには、図5のようにホット・スタンバイ機能と組み合わせてアーカイブファイルの転送で代替したり、必要なWALファイルが削除されないようにwal_keep_segmentsパラメータで指定した個数分のWALファイルを保存するといった調整が必要でした。

これまでの回避策

図5:これまでの回避策

PostgreSQL 9.4ではスタンバイ・サーバへ転送するWALを管理する仕組みとして、新たにレプリケーション・スロットと呼ばれる機構が実装されました。図6のようにスタンバイ・サーバに転送が必要なWALの情報をレプリケーション・スロットで管理し、未転送のWALを保持し続けるように制御することができます。

レプリケーション・スロットによるWALの管理

図6:レプリケーション・スロットによるWALの管理

レプリケーション・スロットの設定はPostgreSQL 9.3までと同様にストリーミング・レプリケーション環境を構築した上で行いますが、手順はとてもシンプルです。

1. マスタ・サーバのpostgresql.confにmax_replication_slotsパラメータを設定します。

パラメータの設定


マスタ・サーバとスタンバイ・サーバが1対Nの構成では、マスタ・サーバ側でのレプリケーション・スロットの最大数を設定するmax_replication_slotsパラメータにスタンバイ・サーバ台数と同じ値を設定し、各スタンバイ・サーバへ転送するWALの情報を個々のスロットで管理します。

2.マスタ・サーバにレプリケーション・スロットを作成します。

レプリケーション・スロット


レプリケーション・スロットの作成にはpg_create_physical_replication_slotファンクションを使用します。レプリケーション・スロットの状態はpg_replication_slotsビューのactive列で判断します。

3. スタンバイ・サーバのrecovery.confにprimary_slot_nameパラメータを設定します。

パラメータの設定


スタンバイ・サーバで参照するレプリケーション・スロットを指定した後、スタンバイ・サーバを起動します。

4. レプリケーション・スロットの状態を確認します。

レプリケーション・スロット


restart_lsn列にスタンバイ・サーバで必要なWALの位置情報が格納されており、その値よりも新しいWALはスタンバイ・サーバへの転送が完了するまでマスタ・サーバで保持されます。

WALファイルの保存先であるpg_xlogディレクトリのディスク領域を常に監視する必要がある点や、WALファイルの管理方法が変更になったことによる転送時のオーバーヘッドが気になるところですが、複数のスタンバイ・サーバで構成される環境においてもPostgreSQLがWALファイルを適切に管理するレプリケーション・スロットの仕組みが実装されたことで、今後計画されているロジカルレプリケーションや双方向レプリケーションといったスケールアウト機能の強化がより現実味を帯びたと言えます。

SELECT処理を妨げることなくデータをリフレッシュするマテリアライズド・ビュー


通常の表と同様に実体を持つビューであるマテリアライズド・ビューは商用RDBMSのシステムでは図7のように結合や集計処理で性能を確保したい場合やリモート表からのデータ取得で以前から幅広く利用されている機能で、PostgreSQLでは9.3から利用できるようになりました。

マテリアライズド・ビューの利用

図7:マテリアライズド・ビューの利用

データの入れ替えはREFRESHコマンドによる完全リフレッシュで行いますが、マテリアライズド・ビューとして保持しているデータを切り捨て(TRUNCATE)た後、挿入(COPY)するため、PostgreSQL 9.3ではリフレッシュ実行中に強いロック(ACCESS EXCLUSIVE)が発生し、SELECT処理が待ち状態となってしまう点が課題でした。

PostgreSQL 9.4では、ロック競合を緩和するためにREFRESHコマンドにCONCURRENTLYオプションが追加され、リフレッシュ処理を実行している間もマテリアライズド・ビューに対するSELECT処理が可能になりました。

マテリアライズド・ビュー


CONCURRENTLYオプションの設定有無によるSELECT処理の動作の違いを見てみましょう。

1. CONCURRENTLYオプションを指定しない場合、リフレッシュ処理の実行中に発行されたSELECT処理は待ち状態になります。

SELECT処理


このときのロック状態を確認すると、リフレッシュを実行しているプロセス32648は元テーブル(tb1)に参照のためのAccessShareLockを、またマテリアライズド・ビュー(mv1)と索引(ind_mv1)にAccessExclusiveLockを保持しています。それにより、SELECT処理を実行するプロセス32202ではgranted列の値がロック待ちを意味する「f」となり、処理が待ち状態になってしまいます。

2. CONCURRENTLYオプションを指定した場合、リフレッシュと並行でSELECT処理が実行されます。

SELECT処理


ロック状態を確認すると、CONCURRENTLYオプションの指定によりマテリアライズド・ビューに対してAccessExclusiveLockを保持しないため、SELECT処理が並行で実行できるのです。内部的には、実ファイルと同じデイレクトリにT2_xxxxという名前を持つ一時ファイルが作成されます。一時ファイル作成時にマテリアライズド・ビューの元データと新しい行データのマッチングが行われ、一時ファイルには元データのTIDと新しい行データを保持します。そしてその情報を元にマテリアライズド・ビューへのDELETEとINSERT処理が行われます。一時ファイルはREFESHの完了と同時に破棄されます。

CONCURRENTLYオプションを有効にするにはマテリアライズド・ビューへの一意インデックスの設定が必須条件であることや、CONCURRENTLYオプションを指定しない場合に比べて処理に時間を要するという懸念がありますが、リフレッシュとSELECT処理を同時に実行できるようになることでデータウェアハウス用途でのPostgreSQL採用拡大が期待できます。

RDBMSに実装されたNoSQLソリューション


昨今のビジネスシーンでは、市場に対してより柔軟かつ迅速に対応するために常に既存システムの変革が求められており、それに伴いRDBMSでデータを管理するという従来のやり方を変える必要性も出てきました。キーバリューストアに代表されるドキュメント指向型のNoSQLデータベースは、アジャイル開発のサイクルに沿ってアプリケーションが作られる中で確立されたデータモデルに対応するソリューションで、ER図や概念上の論理的なフレームワークを用いたRDBMSのデータ・モデルとは対照的と言えます。

PostgreSQLではスキーマレスにデータを管理するNoSQLの仕組みとして、ドキュメント型のJSONやキーバリュー型のHSTOREをRDBMSの基本概念であるACIDと完全に統合した形で提供しています。特にWebアプリケーションで広く利用されるデータ表現フォーマットであるJSONは、主要なNoSQLデータベースであるMongoDBでもネイティブフォーマットとして組み込まれており、PostgreSQLでは9.2でデータ型として組み込まれた後、9.3で多くのファンクションや演算子が実装され、JSONフォーマットのままでデータの参照、更新を行えるようになるなどの機能強化が行われてきました。

PostgreSQL 9.4では、更なる機能拡張としてJSONB型が追加されました。JSONB型はJSONデータをバイナリデータとして保存し、効率良く格納、取得できるように以下の特徴を持っています。

1. 重複データや不要な空白を保持しない(データは正規化される)ため、データを効率よく格納できる

データを効率よく格納


上記は、従来のJSON型とJSONB型の列を持つテーブルを作成し、同一データを挿入した例です。1つ目に挿入した『'{"ename" : "SCOTT" , "empno" : 1000}'』という値は、JSON型ではそのままテキストとして格納されますが、JSONB型ではキー値の順序を並び替え、また不要な空白は削除された形で格納されていることが分かります。また、2つ目に挿入した『'{"ename":"SMITH","ename":"KING"}'』という値は、JSON型ではやはりそのままテキストとして格納されますが、JSONB型では重複キーを省略し、最後の値のみが格納されていることが分かります。

2. データ格納時にのみ構文解析を行い、取得時は再解析しないため高速に処理できる

構文解析


上記は、JSON型とJSONB型の列を持つテーブルを作成し、100,000件の同一データを格納した状態でJSON型、JSONB型それぞれの列値をキーとした検索処理の所要時間を比較した結果です。JSONB型の場合、構文解析の省略に伴ってJSON型と比べて約2分の1の時間で検索結果が返ることが確認できています。

3. GINインデックスが利用できるため、さらに処理を高速化できる

GINインデックス


PostgreSQL 9.3まではJSON型のオペレータや関数を利用することでJSON型データ内のフィールドにインデックスを作成していましたが、JSONB型ではGINインデックス(汎用転置インデックス:generalized inverted index)がサポートされたため、より高速な検索処理が可能になります。上記は、GINインデックス有無による検索処理の所要時間を比較した結果です。本テストではGINインデックスを設定することで約34分の1の時間で検索結果が返ることが確認できています。

コラム:GINインデックスとは

(汎用転置インデックス:generalized inverted index)

GINインデックスは、全文検索など1つの値の中に複数の要素を持つデータに対して要素を条件としてクエリを実行する場合に利用されるインデックスで、PostgreSQLでは8.2から実装されています。

GINインデックスの構造

図8:GINインデックスの構造


また、MongoDBとの性能比較においても、図9のグラフのとおりデータロードにかかる時間は2分の1以下、検索時間は約3分の1に短縮されることが確認できており、今後、トランザクション制御やSQLの利用といったRDBMSの特徴とNoSQLの処理高速化という両方のメリットを活かした利用の拡大が期待できます。

PostgreSQL 9.4 vs MongoDB性能比較

図9:PostgreSQL 9.4 vs MongoDB性能比較

Mixed Workloadの実現を見据えた対応


今回はPostgres PlusのエンジンであるPostgreSQL 9.4の主要な新機能をいくつかピックアップして紹介しましたが、本稿で紹介した機能以外にも性能面の機能としてWAL書き込みの改善やGINインデックスの強化が行われています。

WALとはデータの変更履歴が書き込まれるファイルで、更新処理では必ずWALへの書き込みが発生しますが、PostgreSQL 9.4では、圧縮技術によってこれまでのバージョンと比べて書き込まれるデータサイズが小さく抑えられています。また、データの変更履歴が一時的に格納されるメモリ領域であるWALバッファへの書き込みについてロック制御が改善されたことで複数セッションからの同時処理で効率よく書き込めるようになっており、OLTP系処理の性能向上に大きく貢献する機能と言えます。

また、GINインデックスは全文検索を高速化する際に主に利用されてきたインデックスですが、これまでのバージョンと比べてインデックスサイズを5分の1程度に抑えることができ、さらに性能も向上しています。GINインデックスの機能改善効果は検証中ですが、PostgreSQL 9.4では本稿で紹介したJSONB型と組み合わせて利用できる点が大きなポイントです。NoSQL分野の強力なソリューションとなることは間違いありません。

PostgreSQLは中小規模のシステムやOLTP系用途に特化したデータベースという印象を持つユーザが少なくありませんが、近年のPostgreSQLの開発では、商用RDBMSと同じくOLTP処理にもデータウェアハウス処理にも対応できる「Mixed Workload」の実現に向けた機能強化が着々と進められており、PostgreSQL 9.4には、9.5以降での新たな機能実現に向けた機構がいくつも組み込まれています。たとえば、複雑なSQL処理を複数のプロセスで分担する「パラレル・クエリ」実装に向けて、バックグラウンドプロセスを動的に生成したり、共有バッファを動的に確保できる機構が入りました。また、大規模データに対応する機能として、WALファイルへ行レベルの変更内容を書き込む技術が組み込まれ、オブジェクト単位や双方向でデータ更新が可能なマルチマスターレプリケーションといった柔軟なスケールアウト実現に向けた一歩です。

次回はPostgres Plus独自のエンタープライズ向け新機能についてご紹介します。

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


高瀬 洋子(Youko Takase)

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

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

高瀬の紹介記事はこちら

連載記事一覧

関連製品/サービス


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

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



ページの先頭へ戻る