TOP>企業情報>コラム>技術情報>EDB Postgres 9.6 最新技術 ~EnterpriseDBが牽引するPostgresの今と未来~

EDB Postgres 9.6 最新技術 ~EnterpriseDBが牽引するPostgresの今と未来~


EDB Postgres

性能、信頼性、利用者やデータの増大といった高度化するシステム要件の実現と、コスト削減。これらを両立することは、皆さんが抱える課題の一つと言って間違いないでしょう。

システムの中核を担うデータベースにおいてもコスト削減が求められ、OSS製品が広く検討されるようになりましたが、今後は高度化するITシステムで“使える”製品が必要です。本稿では、PostgreSQLをベースとし、次世代のITシステムの中核を担うべく進化を続けるEDB Postgresを取り上げ、先進的な各種機能の開発を牽引するEnterpriseDB社の取り組みをはじめ、ついに実装された「パラレルクエリ」とそれによって見えてきた「大規模システムでの適用」をご紹介します。


世界最大のPostgresベンダー「EnterpriseDB」の取り組み


世界各国の有志の手で開発されているPostgreSQLには、ソースコードが二次的に利用できることからいくつかの企業が開発者を雇用する形でPostgreSQLの開発を支援し、独自のカスタマイズを加えた製品やソリューションとしてさらなる価値を提供しているという面があります。そのようにして生み出されたPostgreSQLベースの製品の中には、得意分野において商用製品と遜色のない十分な効果を発揮したり、製品ごとに得意分野が異なることで同じPostgreSQLをベースとした製品としながらも多様性が生まれているものがあります。

EnterpriseDB社はそのようなコミュニティでの開発を牽引する、世界最大のPostgresベンダーです。「EDB Postgres」は、そのEnterpriseDB社が開発している、より大規模な環境で、簡単に、安心して使いこなせるための便利な機能を追加し、Oracle Databaseとの高い互換性を備えた汎用RDBMSです(図1)。

図1:EDB Postgresの概要

図1:EDB Postgresの概要

EnterpriseDB社は、顧客企業のニーズを集約し、企業として開発に投資することで、本来のPostgreSQLが目指す姿を実現している会社と言えるでしょう。そしてEnterpriseDB社によって開発されたデータベース本体の改善はPostgreSQL開発コミュニティにもフィードバックされ、数年後にはその機能を誰でも利用できるようになるというエコシステムが完成しています。そのため、図2にあるようなエコシステムの中核を担うEnterpriseDB社は、データベース界を牽引する世界最大のPostgresベンダーと言えるのです。

図2:EnterpriseDB社によるエコシステム

図2:EnterpriseDB社によるエコシステム


EDB Postgresが目指すデータベースのあるべき姿


高度化するシステム要件に対して、EDB Postgresはどのように応えているのでしょうか。

高度な要件を実現するためには「スケールアップ」と「スケールアウト」が欠かせません。EDB PostgresはRDBMSとして、トランザクションを正しく維持しながらこれらを達成しています。現在のEDB Postgresは、図3にあるように内部処理で行われるメモリやCPUの排他制御を効率化し並列実行性を高め、結果として64コア程度までのメニーコア環境や、数十GBを超える中~大規模メモリ環境までのスケールアップに対応し、数千の同時実行ユーザー数を見込んだシステムでも採用が可能になっています。

また、スケールアウト構成を実現するレプリケーション機能も進化を続けています。システムの停止時間を抑える高可用クラスタとして、また、平常時はスタンバイ機を参照用途で使用できる負荷分散クラスタとして動作させることができ、レプリケーション機能の登場以来、多くのミッションクリティカルシステムで採用が進んでいます。EDB Postgresはデータベースとしての基本を重視しながら、現代のサーバスペックを活かし、求められるシステム要件を満たすよう進化を続けているのです。

こうしてデータベースとしての基本を十分に整備したEDB Postgresですが、5年ほど前は、「ビッグデータ」や「IoT」の基盤としての利用は困難でした。しかし、大規模データ対応や、多種多様なフォーマットのデータを格納し、そのデータに合った最適な検索を行うことを次世代のデータベースのあるべき姿として目指し続けていくことで、段々とビッグデータやIoTに対応し始めています。世の中で注目され、利用者から実現を期待される機能が取り込まれていくというやり方はPostgreSQLをベースとしたEDB Postgresならではの取り組みと言えるでしょう。

図3:EDB Postgresの主要機能

図3:EDB Postgresの主要機能


ついに実装された期待の新機能、パラレルクエリ


EnterpriseDB社のメンバーを中心に開発が進み、ここ数年間で一番注目された機能「パラレルクエリ」がついにEDB Postgres 9.6に実装されました。

パラレルクエリは、大量データの複雑な集計処理において高い効果を発揮する大規模環境向けの取り組みの一つです。これまでは一つのSQL処理を一つのバックエンドプロセスが担当していたため、ディスクからデータを読み取るためのI/O時間や、膨大なデータをメモリ上に展開し集計結果を得るための時間はすべて直列に加算されていました。しかし、パラレルクエリは、一つのSQL処理に対して内部的に複数のワーカープロセスを起動し分担して担当することで、I/Oの並列実行を実現したり、ワーカープロセス単位で小規模に集計まで行い、得られた中間結果を統合して最終結果を得ることで高速化を実現しています。

図4は、約2,800万行、4GB程度のデータに対して集計を行った際の実行計画です。一番下のParallel Seq Scanの結果を見ると親であるバックエンドプロセスとワーカープロセスの合計7プロセスで(loops=7)各410万行(rows=4123429)のスキャンを行っていることが読みとれます。次のPartial Aggregate(部分集計)の結果を見ると、ここも7プロセス(loops=7)で、各プロセスが取得したデータを集計した中間結果1行(rows=1)を得ています。各ワーカープロセスから中間結果を集めるGatherでは、各ワーカーの中間結果を計7行(rows=7)集めています。最後にFinalize Aggregateを行い、7行を集計した結果の1行を得て、これがcount(*)演算結果としてユーザーに返されます。

図4:パラレルクエリの実行計画

図4:パラレルクエリの実行計画

今回のSQLでパラレルクエリを利用しない場合、結果が返されるまで約10秒を要します。一方、パラレルクエリを利用した場合の処理時間に注目すると、各ワーカープロセスが中間結果を得るまで1,055ミリ秒を要しますが、ここまで並列実行されているため、その後のGatherやFinalize Aggregateが完了するまで1,061ミリ秒と、中間結果以降ではほとんど時間を要していません。このように、SQL処理中で最も時間を要していたディスクI/Oを並列に行うこと、そして結果の集約を各ワーカープロセスで小規模に行うことで大幅な高速化を実現しています。

パラレルクエリが有効に機能しない処理


パラレルクエリ機能を有効化するだけでは効果が得られない処理も存在します。また、パラレル処理の細部はEDB Postgresの内部動作で決定されるため、チューニングすべき部分の特定が難しいのが実情です。

図5は、約10GB、1.1億行のlineorder表と約3GB、1.6万行のpart表をJOINした際の実行計画です。大規模なlineorder表は1プロセスでSeq Scanしています。比較的小さいpart表は4並列でParallel Seq Scanしていますが、その所要時間はたかだか59ミリ秒です。クエリ実行時間の57秒のうちHash Joinがそのほとんどの時間を占め、特にlineorder表のスキャンに要した時間が約27秒と、非常に長い時間を占有しています。このようにJOINやサブクエリを使ったSQLでは並列度が適切に選択されないケースがあるのです。

図5:パラレルクエリが有効に機能しないSQLの実行計画

図5:パラレルクエリが有効に機能しないSQLの実行計画


EDB Postgresの人気機能、オプティマイザ・ヒントもパラレルクエリに対応


大規模データ環境で本当に実用可能なデータベースとは、チューニングされたSQLが期待する性能を満たすことに加え、チューニングのしやすさもポイントであると言えます。EDB Postgresには、Oracle Databaseの互換機能として実装され、多くの利用者に支持されている「オプティマイザ・ヒント」があります。オプティマイザ・ヒントは、開発者なら誰しも直面する「このSQLだけ実行計画を変えたい」という個別最適を実現するSQLチューニング手法で、EDB Postgres 9.6では、パラレルクエリの並列度をテーブルごとに指定できる「パラレル・ヒント」が使用可能です。

図6は、図5と同じSQLの実行計画で、lineorder表をパラレルスキャンし、part表は意図的に1プロセスでスキャンするようにパラレル・ヒントを指定しています。lineorder表はParallel Seq Scanになり、5並列(loops=5)でスキャンしています。そして、各ワーカーがpart表とlineorder表(の一部)で部分的なHash Joinを行っている点に着目してください。Hash Joinは5並列で行われ、約17秒を要していますが、Hash Join後の中間結果を集めるGatherの時点で128万行まで絞り込みが完了しており、元の1.1億行と比べると1/100程度まで処理の対象となるデータ量を減らしています。part表は各ワーカーがSeq Scanするため5回スキャン(loops=5、こちらはパラレル実行されていないため「5並列」ではありません)されていますが、その所要時間は200ミリ秒程度であるため、全体に占める割合でいえば軽微な影響でしょう。

図6:パラレル・ヒントによる最適化

図6:パラレル・ヒントによる最適化

図7にあるように、パラレルクエリが有効に機能しなかった場合に約60秒要していた時間が、オプティマイザ・ヒントによって適切にパラレル化されたことで約17秒まで短縮される結果になりました。

図7:パラレルクエリ利用による所要時間の短縮

図7:パラレルクエリ利用による所要時間の短縮


大規模データ環境のもう一つの課題


大量のデータを格納するテーブルで、仮にSQL実行時間を目標値まで短縮できたとしても、そのデータベースが保持するデータサイズはやはり膨大です。これは、バックアップ・リカバリ計画に直接的に影響を及ぼします。

EDB Postgresでは、データベースに対する変更履歴(WAL:どのファイルのどのブロックがどう変更されたか)を常に記録しています。図8にあるように日次でバックアップを取得しておけば、障害時は1日前のバックアップに当日分のWALを適用することで直近までの任意の時点にデータを復旧できる「ポイント・イン・タイム・リカバリ」に対応しています。これは障害から正しく復旧するための策という意味では有意なものですが、増え続ける大量のデータを扱わなければならない昨今のシステムにおいては、最低限の機能でしかありません。データ量の増加でバックアップの取得に1日以上を要していては、運用が立ち行かなくなることは明白です。バックアップの高速化手法で有用とされるストレージ機能によるスナップショットを取得する方法も、理由は割愛しますが、EDB Postgresにおける完全な対策とは言えず、取得したバックアップが正しくリストアできるかどうか、都度検証する必要があります。

図8:EDB PostgresとOracle Databaseのバックアップ機能比較

図8:EDB PostgresとOracle Databaseのバックアップ機能比較

EDB Postgresにはさまざまな運用管理ツールが実装されており、中でも2017年6月に最新2.0がリリースされたバックアップ・リカバリ統合管理ツール「EDB Backup and Recovery Tool(BART)」は、ブロックレベルの増分バックアップに対応し、これまで大規模環境での課題とされていたバックアップの所要時間を大幅に削減できるようになりました。

BARTは図9にあるようにバックアップの取得に加え、バックアップファイルやアーカイブファイルの世代管理、リストアをコマンドで簡単に実行することができます。BART 2.0の新機能では、前回のバックアップ以降に更新されたブロックのみを抽出してバックアップを取得することができます。バックアップファイルのサイズはデータベース全体のサイズに依存しないことから、大規模データ環境でのバックアップ容量の削減、バックアップ所要時間の短縮が期待できます。BARTのバックアップコマンドは、エンジンであるPostgreSQL標準のpg_basebackupコマンドやファイルアクセス関数を内部的に用いるため、先述したストレージ機能やファイルシステムとの親和性の問題に対しても安全です。

図9:BARTの主要機能

図9:BARTの主要機能


EDB Postgresが実現する更なる大規模データ対応


EDB Postgres 9.6は、クエリ実行時間の短縮にとどまらず、大量データを扱う上で必要なチューニングや運用管理まで見据えられた機能を提供しています。さらにまもなくリリースされる次期バージョン10では、パラレルクエリやテーブル・パーティショニング等の大規模データ向けの機能が一段と進化することが明らかになっており、EDB Postgresがハッシュ表作成、ビットマップ生成、インデックス走査のパラレル処理などいよいよ本格的な分析用途にも利用できる、データベース界のオールラウンダーになる日も近いと期待しています。


執筆者紹介

喜田 紘介

喜田 紘介(Kosuke Kida)

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

アシスト入社後、Oracle Databaseのフィールドエンジニアを経て、EDB Postgresの技術支援、プリセールス、新機能検証を担当。日本PostgreSQLユーザ会の理事としても活動し、全国各地での勉強会やイベントを企画、講師としてデータベース技術の普及・促進に邁進中。

関連製品/サービス


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

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



ページの先頭へ戻る