TOP>企業情報>コラム>技術情報>EDB Postgres活用の勘所と最新9.5の注目機能

EDB Postgres活用の勘所と最新9.5の注目機能

EDB Postgres

オンプレミスに加え仮想インフラやクラウドでの採用が増えているEDB Postgres。本記事ではEDB Postgresの採用ポイントとそれを支える技術要素をご紹介します。また、最新バージョン 9.5の新機能とその活用シーンもあわせてご紹介します。

企業ニーズを満たすべくPostgreSQLが進化した「EDB Postgres」


EDB Postgresは、企業向けデータベースに求められる機能を実装してPostgreSQLを大きく進化させたデータベースであり、図1のような3つの主な特長があります。

まず、「性能」「拡張性」「運用管理」「セキュリティ」「可用性」などの非機能要件については企業で利用できるレベルに強化されています。特にパーティショニングやOLTP処理の性能向上、異種データベースとのデータ連携、統合運用管理、自動チューニング機能など、実際に企業内でEDB Postgresを運用することを前提とした機能が充実しています。

2つ目は提供元であるエンタープライズDB社による質の高いサポートです。エンタープライズDB社にはPostgreSQL開発コミュニティの主要コミッタが複数在籍しており、PostgreSQLと共に成長するというビジョンを掲げ、PostgreSQL本体の開発にも積極的に参画しています。そのため、企業向けデータベースとして利用する場合のサポート面でも不安はありません。

3つ目の特長はサブスクリプション・ライセンスと呼ばれる年単位のサポート付き使用権での提供形態です。サブスクリプション・ライセンスはソフトウェア資産ではなく経費として処理できること、さらに、永久ライセンスコストを支払うのではなく必要な期間の利用権を購入し、ビジネスに合わせて柔軟なライセンスを選択できます。さらに、物理環境、仮想環境問わず、データベースサーバに割り当てられたCPUコアのみをライセンス対象としているため仮想化環境やクラウド環境で利用しやすい点も大きな特長となっています。

図1:EDB Postgresの3つの特長

図1:EDB Postgresの3つの特長

主要エディションである「EDB Postgres Enterprise」は図2にあるようなOracle Databaseとの高い互換性やパフォーマンス・チューニングに便利な機能を備えた独自エンジンと周辺ツールにサポートが合わさってパッケージングされており、開発生産性と運用管理性を大きく向上させます。

図2:EDB Postgres Enterpriseの特長

図2:EDB Postgres Enterpriseの特長

次項では、EDB Postgresの活用例をご紹介します。

社会インフラ基盤を支えるEDB Postgresの信頼性と性能


2016年2月18日にエンタープライズDB社主催のイベント「EnterpriseDB Summit Tokyo 2016(EDB Summit)」が開催されました。事例セッションでは、大和総研ビジネス・イノベーションのEMS(エネルギー・マネジメント・システム)への導入事例が紹介されました。

電力の利用を可視化、最適化するEMSには、社会インフラのデータ管理にふさわしい高い信頼性と処理性能が必須だったことはもちろんですが、ビジネス自体が立ち上がり段階だったことからシステム開発費用の抑制という相反する要件が求められていました。これを同時に満たしたのが「EDB Postgres」だったのです。(※本事例の詳細はこちらのページ をご参照ください。)

数万のエンドポイントから送信される電力データをオンライン処理できる性能と信頼性をEDB Postgresが実現しています。

仮想インフラで最大52倍の性能向上を実現


アシストでも、2012年より利用しているオープンソースの勤怠管理システム「MosP(モスプ)」の利便性をさらに向上させるため、2015年4月に仮想インフラへの移設とあわせてバックエンドのデータベースをPostgreSQL 9.3からEDB Postgres 9.4へ変更し、システム環境を刷新しました。

EDB Postgresで提供されるエンタープライズ機能の1つである「Postgres Enterprise Manager」(PEM)は、図3のようにグラフィカルな統合コンソールからEDB Postgresのデータベースサーバを監視し、管理やチューニングに有用な情報を提供することでデータベースの運用管理を強力に支援します。

例えば「SQL Profiler」や「Index Advisor」などのコンポーネントにより、負荷が高いSQLを容易に特定できるだけでなく、その負荷を軽減するための索引作成のアドバイスも自動で提供します。

図3:PEMによる監視

図3:PEMによる監視

アシストではEDB Postgresへの移行後にPEMを利用してシステムの稼働状況を確認し、CPU負荷が高いSQLを特定しました。そしてPEMのアドバイスに従って適切な箇所に索引を作成した結果、システムのレスポンスを以下のとおり大幅に向上させることに成功しています。

  • 向上例1 管理者が勤怠データを一括表示する速度を最大52倍高速化
  • 向上例2 承認者が勤怠データを一括承認する時間を最大7倍高速化

このように、弊社システムにおいてもEDB Postgresを仮想インフラで動作させ、標準実装されたチューニング機能によって性能改善を実現しています。また、その他にもEDIやECサイトなど様々なシステムで、同じようにEDB Postgresを仮想インフラへ導入し、成果を上げている事例が多数あります。

昨今、物理サーバやストレージ、VMWareに代表される仮想化管理ソフトウェアの目覚ましい技術進歩により、仮想インフラでデータベースを動作させることは一般的になりつつあります。

技術的にはクリアできる一方で、データベース・ソフトウェアのライセンスが採用のハードルになるケースがあるのも実状です。データベースサーバに割り当てられたCPUコアのみがライセンス対象となるEDB Postgresであれば、規模や用途に応じてライセンスコストを最小限に抑えることができます。(※本事例の詳細はこちらのページ をご参照ください。)

新バージョン 9.5の注目機能


今後EDB Postgresはどのように進化していくのでしょうか。2016年1月26日に待望の新バージョン 9.5がリリースされました。1月7日にリリースされたPostgreSQL 9.5に追従する形で、図4にある「信頼性」「性能」「開発」「DWH」「連携」「セキュリティ」などデータベースに求められる非機能要件を満たす様々な機能が組み込まれています。今回はそれら注目機能の中から「WAL圧縮」「外部テーブル継承」「BRINインデックス」について詳しくご紹介します。

図4:EDB Postgres 9.5の主な新機能

図4:EDB Postgres 9.5の主な新機能

WAL生成量を大きく抑制する「WAL圧縮」


WAL圧縮は、図5にあるように更新履歴を保存するWALと呼ばれるファイルにページの完全イメージを書き込む際に圧縮する機能で、wal_compressionパラメータで制御します。

図5:WAL圧縮の仕組み

図5:WAL圧縮の仕組み

チェックポイント完了後にはじめて参照または更新されたページが完全イメージとして書き込まれますが、この内部動作によって、万が一チェックポイント中に何らかの障害でデータベースが停止した場合でもWALを使ってページ全体のリカバリが可能になります。

一方でWALへの書き込み量が増加してしまうことがデメリットでしたが、WAL圧縮の機能によりWALサイズの縮小化が期待できます。pgbenchを利用した検証では、図6にあるようにWAL圧縮を有効にした場合、無効と比べて約4分の1の生成量に抑制できることを確認しました。

商用システムではバックアップ・リカバリの観点からアーカイブ運用とするケースが多いと思います。WAL圧縮の有効化によってディスク領域の大幅な節約ができますので、ぜひご検討ください。

図6:WAL圧縮有無によるWAL生成量の比較

図6:WAL圧縮有無によるWAL生成量の比較

「外部テーブル継承」による複数サーバへのデータ分散配置


外部テーブル継承は、図7にあるようにリモートサーバのテーブルをパーティションテーブル(子テーブル)として活用できる機能で、外部データラッパ(FDW)と呼ばれる外部のデータベースやファイルとEDB Postgresとをつなぐ独自の機能で実現しています。

「継承」という仕組みそのものは、従来から同一サーバ上で大規模テーブルのデータを複数の子テーブルへ分割するために利用されてきましたが、その仕組みを複数サーバをまたぐ構成でも利用できるようになります。メリットとして、複数サーバで処理を分散できること、バックアップやデータ挿入など管理性の向上、障害やメンテナンス時の影響を最小化できることなどがあります。

図7:外部テーブル継承の構成イメージ

図7:外部テーブル継承の構成イメージ

EDB Postgresでは「継承」に加えて「制約」「トリガ」を組み合わせることでパーティショニング機能を実現しており、外部テーブル継承でも同じ仕組みを利用します。CHECK制約によって必要なデータが格納されたテーブルを絞り込むことができ、それにより検索処理を高速化することができるのです。

今回の検証ではAmazon EC2を利用し、1つのテーブルに全てのデータを格納した環境(※図8のグラフでは「外部テーブル利用無」と表現しています)と親テーブルのインスタンスおよび外部テーブル継承を利用した3インスタンスの各テーブルにデータを水平分散した環境をそれぞれ用意し、同一SQLを実行した際の処理時間とアクセスブロック数の差を確認しました。外部テーブル継承を利用した場合、対象データが配置されたサーバにのみアクセスされ処理時間が短縮されることが確認できています。

図8:外部テーブル利用有無によるSQL処理時間とアクセスブロック数の比較

図8:外部テーブル利用有無によるSQL処理時間とアクセスブロック数の比較

今後、FDWの機能が拡張され集計や集約処理がリモートサーバで行えるようになったり複数プロセスで処理を分担できるパラレルクエリの提供が本格的になれば、外部テーブル継承は利用が大きく広がることが期待できます。

また、AWSに代表されるパブリッククラウドサービスでは、一般的に高スペックサーバ1台分のCPUコア数やメモリサイズ、費用が低スペックサーバ20台分に相当するような設定となっており、クラウドはシステム規模に応じて費用を抑えたスケールアウトが行いやすい環境です。

例えば店舗ごとにパーティション分割するようなシステムの場合、低スペックサーバ数台で外部テーブル継承によりデータを分散配置する形でスモールスタートさせ、店舗数の増加に応じてインスタンスを追加することが容易にできます。その際、EDB PostgresであればCPUコア単位でライセンスを追加購入できる点もメリットとして大きいと言えます。

大規模データの検索処理で効果を発揮「BRINインデックス」


BRINインデックスは、図9にあるようにテーブルのページを複数グループに分けそのグループ内の最小値と最大値が格納されたインデックスです。そのため、インデックスサイズを極力小さく抑えることができます。BRINインデックスと同様の仕組みはDWHに特化した商用データベースでも実装されており、大規模データの検索処理で効果を発揮します。

図9:BRINインデックスの仕組み

図9:BRINインデックスの仕組み

今回BRINインデックスの効果測定として、5GB、50GB、100GBのデータを持つ同一構造のテーブルを用意し、特定の列にB*TreeとBRINインデックスを作成した際の所要時間とインデックスサイズを比較しました。データサイズに伴い、いずれのインデックスも作成時間は長く、サイズも大きくなるのですが、BRINインデックスをB*Treeと比較すると図10にあるように100GBのデータでは、作成時間は10分の1に、またサイズはB*Treeが16GBになったのに対してBRINインデックスはわずか4MBに抑えることができました。数百GBからTB級のデータを想定した場合、その差はさらに大きくなります。

図10:インデックスの作成時間とサイズの比較

図10:インデックスの作成時間とサイズの比較

また、検索処理でBRINインデックスを利用した場合の効果を確認するため、100GBのテーブルでインデックスが設定された列を範囲指定で検索する処理を実行したところ、図11にあるようにB*Treeインデックスが存在していればインデックススキャンが選択されて最も性能が良い結果となりました。

BRINインデックスはB*Treeインデックスと比べて処理時間が20秒ほど長くなるものの、全データを走査するシーケンシャルスキャンと比べると約6分の1で抑えられることが確認できています。大規模システムでどのインデックスを採用するかは性能要件とインデックスの作成時間、サイズとのトレードオフでご検討ください。

図11:検索処理時間の比較

図11:検索処理時間の比較

BRINインデックスが効果を発揮するには、対象列で物理的にソートされたデータであることがポイントです。そのため、業務システムからデータを切り出して分析用データベースへ配置する場合、図12にあるようにETLツールなどであらかじめデータをソートした上で格納するなどの工夫が必要です。

図12:事前ソートによるデータ格納

図12:事前ソートによるデータ格納

9.6以降の機能実装に向けた動き


9.6以降では、図13にあるような双方向レプリケーションやロジカルレプリケーションなどの可用性機能をはじめ、性能面ではインメモリ対応としてInfinite Cacheと呼ばれる機能の強化が計画されています。

また、BIやDWH向け機能の開発は継続で進められており、9.6ではいよいよ待望のパラレル・クエリが実装される予定です。さらに連携の観点ではxDB Replication Serverで商用データベースとの地理情報の連携も可能になります。これはユーザから高い評価を受けているPostGISを活かした機能拡張です。

図13:9.6以降で実装予定の機能

図13:9.6以降で実装予定の機能

システムで重要視される観点は様々ですが、EDB Postgresはユーザの要望を満たす多くの特長を持っています。インフラ基盤を簡単に構築できる仮想インフラやクラウドとEDB Postgresを組み合わせた利用がビジネス変化のスピードに合わせたシステム開発を可能にします。ぜひご検討ください。


執筆者紹介

高瀬洋子

高瀬 洋子(Youko Takase)

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

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

高瀬の紹介記事はこちら

関連製品/サービス


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

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



ページの先頭へ戻る