SRA OSS, Inc. 日本支社
マーケティング部 PostgreSQL 技術グループ
長田 悠吾
PGCon は年に一度、初夏の季節にカナダで開催される世界最大のPostgreSQLカンファレンスです。
毎年、世界中から数多くの PostgreSQL のユーザと開発者が参加します。
第11回目となる今年のPGCon 2017も、例年通りカナダの首都オタワにあるオタワ大学にて開催されました。
オタワ大学入り口：チューリップで有名な季節ですが、
街中にはライラックもたくさん咲いていました。
今年も SRA OSS はシルバースポンサーとして、このカンファレンスの支援をさせていただきました。
弊社の石井はプログラム委員の一人として、プログラム選考に協力しております。
また、本レポートの著者である長田は今回はセッションの発表者として参加して参りました。
今回の PGCon は 5 月 23 日(火)から 26 日(金)の 4 日間の日程で、1日目と2日目にはチュートリアルセッションが、3日目と4日目にはメインの講演が行われました。
また、今年はアンカンファレンスが2日目に開催されました。
なお、これらとは別に、PostgreSQL 開発コミュニティの運営など、主に技術以外の内容が議論される開発者会議が1日目に開催されました。
この会議は招待制で一般には非公開ですが、議事録はwikiで公開されているので誰でも読むことができます。
本レポートではメインの講演とアンカンファレンスの中からいくつかのトピックを紹介いたします。
毎年PGConでは、その年リリースされる予定の最新のPostgreSQLの新機能を紹介するセッションがあります。
PostgreSQL のバージョン番号は、ここ最近 9.x の形式が続いていましたが、次期メジャーバージョンではバージョン体系が変更され、次のメジャーバージョンは PostgreSQL 10となります。
PostgreSQL 10 は今年の秋ごろにリリース予定で、現在は beta 1 版がリリースされているところです。
その PostgreSQL 10 の目玉機能の 1 つがロジカルレプリケーションです。
従来の PostgreSQL のストリーミングレプリケーションでは、複製元であるプライマリサーバに加えられた変更は、「あるファイルに対する物理的な変更」の形で複 製先であるスタンバイサーバに転送されます。
その結果、2 つのサーバのデータは、データベースを構成するファイルがビット単位で複製されたものとなっていました。
その意味でストリーミングレプリケーションは「物理的」なレプリケーションであると言います。
これに対し、ロジカルレプリケーションでは、複製元に加えられた変更は「どのテーブルのどの行がどう変更されたか」という論理的な形式で複製先に転送されます。
変更の内容が言葉で説明可能な形で表現されている、と考えてもよいかもしれません。
その意味で「論理的な（ロジカルな）」レプリケーションと呼ばれます。
この新機能のロジカルレプリケーションを紹介する発表（Logical Replica tion in PostgreSQL 10）が2ndQuadrant社のPeter Eisentraut氏により行われました。
PostgreSQL でロジカルレプリケーションを実現する手段として、従来はBDRやpglogicalという拡張モジュールが2ndQuadrant社によって開発されていましたが、PostgreSQL 10では正式にこの機能が本体に取り込まれました。
このセッションでは、この新機能の概要と使い方、設定方法などの実践的な内容、および現状の制限事項や課題について解説されました。
会場の Desmarais Building：大学の入り口すぐ近くに建ってます。
ロジカルレプリケーションを使うと、ストリーミングレプリケーションではできなかったテーブル単位のレプリケーションや、複製先のデータベースへの変更が可能になります。
例えば、特定のテーブルのみを複製し、複製先で解析用のインデックスを追加したり、途中結果を格納するための一時テーブルを作成したりすることができます。
一方で、複製可能な変更内容はテーブルに対する INSERT, DELETE, UPDATE のみで、TRUNCATE や CREATE TABLE などの DDL の内容は複製できないという制約事項があります。
また、拡張モジュールの BDR で提供されているような、複数サーバから同じテーブルを更新できる「マルチマスタレプリケーション」については PostgreSQL 10 の ロジカルレプリケーションでは実現することはできません。
これは将来の機能に期待するところです。
もう1つのPostgreSQL 10の目玉機能は、宣言的パーティショニングです。
ここで言うパーティショニングは、親テーブル内のレコードを複数の子テーブルに分割して格納する水平パーティショニングを指しています。
従来の PostgreSQLでも、継承テーブル、CHECK 制約、INSERT トリガーといった複数の機能を組み合わせることでパーティショニングは可能でしたが、それぞれの機能に関する操作を別々に行う必要があるため、その設定は煩雑で面倒なものでした。
PostgreSQL 10 ではこのテーブルのパーティニングが CREATE TABLE 文の構文を使って簡単に構築できるようなりました。
このパーティショニングに関する発表（Partition and conquer large data with PostgreSQL 10 – Declarative partitioning comes to PostgreSQL）が、NTTのAmit Langote氏とEnterpriseDB社のAshutosh Bapat氏によって行われました。
まず、宣言的パーティショニングの開発者である Amit Langote 氏により、その機能がコマンドの実行例とともに紹介されました。
PostgreSQL 10 の CREATE TABLE 文の構文には新しく PARTITION BY と PARTITION OF 句が追加され、これによりパーティションの親テーブル、子テーブルを定義できるようになりました。
また、ALTER TABLE 文の構文も拡張されており、ATTACH PARTITION 句、および DETATH PARTITION 句により、パーティションの追加や削除ができます。
パーティションの子 テーブルをさらに分割する、多段のパーティショニングも実現可能です。
パーティショニングはレコードを子テーブルに振り分けるルールによって分類ことができますが、PostgreSQL 10 ではパーティションキー値の範囲を指定するレンジパーティショニングと、パーティションキー値のリストを指定するリストパーティショニングの2 種類がサポートされています。
これ以外にハッシュ関数を利用した ハッシュパーティショニングもよく知られる振り分けるルールですが、これについてはPostgreSQL 10ではサポートされておらず、現在開発が進められているところです。
パーラメント・ヒル：時計台のある建物が国会議事堂。
右側のゴシック様式の建物は議会図書館
PostgerSQL 10 で宣言的パーティショニングにより構文が新しく整備されたことで、今まで煩雑だったテーブルパーティショニングの構築が簡単に行えるようになりました。
しかし、この機能の意味はそれだけではありません。
パーティショニングが正式な機能として実装されたことで、従来の「あり合わせの機能の組み合わせ」で実現されていた時に比べて、パーティショニングに関するより多くの情報をシステムに提供することが可能になりました。
そして、この基盤を利用することで、プランニングやロック処理などにおいて、パーティショニングテーブルの処理をより効率的に行えるようになったのです。
そのようなパーティショニングテーブルに対する効率的なプランニングの実例がAshutosh Bapat氏より紹介されました。
その1つが partition-wise join（パーティション毎の結合）で、同氏が開発中の機能です。
巨大なテーブル同士を直接 JOIN するのではなく、パーティショニングによりこれを複数の子テーブルに分割し、子テーブル同士を JOIN してから最終的にその結果を連結する、というのが基本的なアイデアです。
大きな JOIN を小さな複数の JOIN に分割することで効率の良い JOIN が可能になります。
また、全ての子テーブルではなく検索条件に適合した子テーブルのみで JOIN を行えばよいというのも、この方法の利点です。
報告によると、実際に開発中のコードでこの機能の性能を実験したところ、JOIN 処理が 5 倍速くなったという結果を得たとのことでした。
この他にも、パーティション毎の集約やソートといった機能が開発、検討されているようです。
パラレルクエリは PostgreSQL 9.6 で登場した機能で、検索クエリの処理を複数プロセスで並行に実行可能にするものです。
PostgreSQL 10 ではその機能が強化され 、並列化できる処理の対象が大きく拡張されました。
その内容が EnterpriseDB の Rafia Sabih 氏と Robert Haas 氏の発表（Parallel Query v2 – The herd of elephants we unleashed claims new territory）で紹介されました。
PostgreSQL 9.6 でサポートされたパラレルクエリは、シーケンシャルスキャン（順次検索）、ネステッドループ結合、ハッシュ結合、そして一部の集約計算だけと、かなり限定されたものでした。
PostgreSQL 10 ではこれに加えて、インデックススキャン、インデックスオンリースキャン、ビットマップヒープスキャン、マージ結合が並列実行可能となりました。
その他にも、複数プロセスが並列にソート処理を行った結果を全体のソート結果にまとまる機能（Gather Marge）や、一部のサブクエリを並列実行可能にする、手続き言語内でのパラレルクエリの実行を改善するといった改良がされています。
今回のノベリティのドリンクホルダ：
クラマトシーザーの缶を入れてみました
PostgreSQL 10 で拡張されたパラレルクエリの効果は、TCP-H ベンチマークの結果で検証されました。
PostgreSQL 9.6 の結果と比較すると、いくつかのクエリでインデックススキャンの並列化の効果が大きいことがわかりました。
データサイズの規模を大きくしたケースでは、ビットマップヒープスキャンとマージジョインの効果も確かめられました。
一方、Gather Marge は実行計画の中で多く使われたにも関わらず、あまり効果を上げることはできなかったとのことでした。
発表の後半では「アムダールの法則」の公式を引用して現状のパラレルクエリの課題が紹介されました。
アムダールの法則は一言で言えば「並列処理全体の性能は、並列化されない部分からの制限を強く受ける」というものです。
例えば、パラレルクエリではハッシュ結合の並列実行が可能ですが、実は内表からハッシュテーブルを作成する処理は並列化されておらず、それぞれのプロセスにおいて内表の全ての行を処理しています。
この部分がボトルネックとなり性能がでない問題を解決するため、複数のプロアセスで 1 つのハッシュ表を並列的に構築・共有する Parallel Shared Hash という機能が開発コミュニティで提案されていることが紹介されました。
この他にも、ビットマップインデックススキャンの並列化や、よりパラレルクエリを考慮したプランナの改善などの必要性についても説明されており、まだまだパラレルクエリには改善の余地があるようです。
他にもPostgreSQL 10の新機能として、SCRAM 認証とハッシュインデックスに関する発表がありましたので、ここで紹介しておきます。
PostgreSQL 10 からサポートされる md5 よりもセキュアなパスワード認証方法であるSCRAM認証については、開発者の1人であるPivotal社の Heikki Linnakangas 氏の発表（SCRAM authentication in PostgreSQL）で紹介されています。
例えば、md5 認証では、パスワードの推定が比較的容易であったり、データベース内に保存されたハッシュ済みパスワードが盗まれた場合、（それが元のパスワードそのものではないにも関わらず）成りすましのログインが可能でしたが、SCRAM 認証ではそのような問題はありません。
ハッシュインデックス自体は古くから PostgreSQL でサポートされていましたが、従来の PostgreSQL ではインデックス作成時のトランザクションログが生成されないために永続的ではなく、またストリーミングレプリケーションにも対応していませんでした。
これが、PostgreSQL 10 ではトランザクションログが出力されるようになり、永続化とストリーミングレプリケーションに対応しました。
その他にも、ロック競合やインデックスサイズの面で改善がされています。
PostgreSQL 10 のハ ッシュインデックスについては、この改良を行った EnterpriseDB 社の Amit Kapila 氏の発表（Faster And Reliable Hash Indexes）で紹介されています。
PGCon で発表される内容は PostgreSQL の新機能に関するものだけではありません。
バックアップ、テスト、HA構成といった運用管理に関するセッションも毎回用意されています。
ここではそれらのセッションの中から NTT の Masanori Oyama 氏によるセキュリティに関する発表（PostgreSQL Security – How Do We Think?）を紹介します。
この発表の前半では、クレジットカード業界におけるセキュリティ基準である PCI DSS に基づいて、データベース全般に対しどのようなセキュリティ要件が求められているかについて説明されました。
他の商用データベースから PostgreSQL に移行する際には、このセキュリティ基準をどの程度満たしているかどうかが 1 つの判断基準となり得ます。
セキュリティ要件は大きく4つに分類して説明されました。
1つ目は「データベースをセキュアに保つこと」です。
これは例えば、デフォルトのユーザアカウントや パスワードを用いない、不必要な機能やモジュールは使わない、ソフトウェアは最新バージョンに保つ、といったことです。
残りの2つ目は「暗号化と鍵の管理」、3つ目はユーザの「識別、認証、認可、アイデンティティ管理」、そして4つ目はアクセスの情報をログに残す「監査」です。
発表の後半では、これらの要件をどのように PostgreSQL に適用できるかが議論されました。
1つ目の「データベースをセキュアに保つこと」は、基本的な設定とセキュリティ実践により対応可能です。
次に2つ目の「暗号化と鍵の管理」については、暗号化は拡張モジュールのpgcryptoを使うことで対応可能ですが、透過的暗号化や鍵管理については現状の PostgreSQL では対応できていません。
この機能の実現については、コミュニティで議論する必要があるかもしれないと主張されました。
3つ目の「識別、認証、認可、アイデンティティ管理」に関しては、「PostgreSQL のスーパユーザは全ての操作が可能である」ことが問題点として挙げられていました。
この観点からは、理想的にはスーパユーザを使用しないのが望ましいのですが、現実にはそうもいきません。
そのため、スーパユーザによる操作は全て監査ログを残すという対策が必要になります。
また、PCI DSS で定めるパスワードポリシーやユーザ管理に合致するためには、LDAP などのディレクトリサービスを利用する 必要もあるだろうとのことでした。
毎回配れられるTシャツ：
全ての講演タイトルと講演者の名前がプリントされています。
そして4つ目の「監査」です。
PostgreSQL のログには様々な情報を残すことができるのですが、例えば「どのオブジェクト（テーブルなど）がアクセスされたか」といった情報はSQL文字列に含まれているとは限らないため、正確に残すことができません。
この点で PostgreSQL は PCI DSS の要件を満たすことができていません。
そこで、この機能を持つ監査ツールとして、2ndquadrant 社とCrunchy Data社によって開発されたPGAuditが紹介されました。
しかしながら、PGAudit を使用しても、今度は「スーパユーザは PGAudit の設定を簡単に変更可能である」、「サーバログと監査ログを分離することができない」といった問題が残り、やはり要件を満たすことができません。
これに対し、NTT ではこれらの問題の対 策を行ったNTT版PGAuditを開発、公開、保守しているとのことです。
このセッションにより、pgcrypt, ディレクトリサービス、PGAudit などを利用することで、PostgreSQL で PCI DSS セキュリティ基準の多くを満たせることが示されましたが、依然として透過的暗号化と鍵の管理、スーパユーザ権限に依存しない監査方法の必要性といった課題が残っていることもわかりました。
PGCon では将来の PostgreSQL の機能拡張の話題や、より先進的で実験的な話題を提供するセッションも用意されています。
以降では、そのような発表の中からいくつか紹介します。
NTT の Amit Langote 氏、Etsuro Fujita 氏、Kyotaro Horiguchi 氏、Masahiko Sawada 氏からは、PostgreSQL で組み込みのシャーディング機能を実現する試みについて（Towards Built-in Sharding in Community PostgreSQL）発表がありました。
テーブルのデータを複数のサーバに分散配置することで検索と更新をスケールアウトさせるシャーディングを、テーブルパーティショニングと外部データラッパ(FDW)を組み合わせることで実現しよう、という試みが以前から行われてきました。
テーブルパーティショニングを利用してで巨大テーブルのデータを複数の子テーブルに分割し、その子テーブル自体は外部データラッパを利用して他のノードで動く PostgreSQL サーバに格納する、というのが基本的なアイデアです。
宣言的パーティ ショニングや、JOIN やソート、データ更新、集約計算を外部の PostgreSQL で実行させる機能など、この方法でシャーディングを行うのに必要な基盤は揃ってきています。
さらに、現在開発中の partition-wise join（パーティション毎の結合）や partition-wise aggregation（パーティション毎の集約）、外部サーバでのクエリ実行を非同期的に並列実行させる枠組み、および、外部の複数サーバで実行されたトランザクションを 2 相コミットの枠組みを使って管理する機能を用いることで、シャ ーディングの機能を高めていく議論が展開されました。
これらの機能は既にパッチが提案されており、実現は間近かもしれません。
もう少し実験的な提案として、PGCon 2017 ではプランナの改良に関する発表が2件ありました。
1つはモスクワ大学のOleg Ivanov氏による、機械学習を用いた適応的なクエリプランナの提案です（Adaptive query optimization in PostgreSQL）。
PostgreSQL のプランナは実行計画を作成する過程で処理する行数の推定を行い、その推定値に基づいて最適な計画を作成しようとします。
しかし、この行数の推定の際はテーブルのカラム間に相関が無いことが前提の計算となっています。現実的にカラム間に相関がある場合は多く、その場合には適切な行数の推定ができず、最適な計画の生成に失敗してしまうという問題があります。
この問題に対し、機械学習を用いて行数を推定することで解決するアプローチが紹介されました。
繰り返しクエリを実行することで、正しい行数を推定できるようなるというものです。
実際に PostgeSQL に実装したものを TPC-DS ベンチマークを用いて実験した結果、あるクエリでは元の PostgreSQL に比べて 95 倍の性能が出たとのことでした。
この手法が有効なのは、データの分布が安定していて、実行されるクエリや条件句にあまり変化がない場合である、など決して万能ではありませんが、プランナに機械学習の仕組みを取り入れる試み自体が刺激的です。
もう1つのプランナの発表は、EnterpriseDB 社の Rafia Sabih による、実行時間だけを目的としない「多目的」最適化を行うクエリプランナの提案です（Multi-objective Query Optimization in PostgreSQL – Tradeoff between execution-time and resource-requirements!）。
今の PostgreSQL のプランナは実行時間を最小にすることだけを目的として実行計画を生成しますが、この提案では、実行時間とメモリ使用量のトレードオフを考慮して、両者の間の調度よい実行計画を生成することを目指します。
発表者とは別にオリジナル論文の著者がいるらしく、発表の最後には会場にいない論文著者とSkype経由で質疑応答を行う場面が見られました。
これら2つの提案のいずれも、今までにない新しいプランナの方向性を感じさせる面白い発表でした。
長田による発表：新理論によるビュー更新可能性の拡張
とPostgreSQLによるプロトタイプ実装について
講演の紹介の最後となりますが、本レポートの著者である長田の発表（Extending View Updatability by a Novel Theory – Prototype Implementation on PostgreSQL）をご報告いたします。
内容は、SQLのビューの更新可能性を拡張する新しい理論の紹介と、PostgreSQL 上におけるその理論のプロトタイプ実装についてです。
これは、お茶の水女子大学名誉教授の増永良文先生との共同研究で、紹介する理論は増永先生によって提案されたものです。
PostgreSQL では自動更新可能性ビューがサポートされており、簡単なビューであれば更新クエリを受け付けることが可能です。
しかし JOIN を含んでいる場合など複雑なビューは自動更新することができません。INSTEAD OF トリガーを作成することで更新可能にする方法はありますが、その場合には個々のビューに応じたトリガーを個別に定義する必要があります。
このような複雑なビューの更新可能性については古くから研究されていますが、完全には解決されていません。
この発表では、このビュー更新問題を「ユーザの意図を推定する」というアプローチで解決する新しい理論を紹介し、その理論の実現可能性を評価するために PostgreSQL 上で実装したプロトタイプについて説明しました。
また、プロトタイプ実装時に PostgreSQL 10 の新機能である Transition Table （遷移表：AFTER TRIGGER の中で「クエリに影響を受けた全ての行」にアクセスできる機能）を利用したので、これについても発表の中で紹介しました。
この研究はまだ進行中であり、今後もプロトタイプ開発で得られた知見を理論にフィードバックしながら研究に貢献していく予定です。
次にアンカンファレンスの様子をご報告します。昨年までは 2 日間に分けて開催されていたアンカンファレンスですが、今年は 1 日での開催となりました。
アンカンファレンス：パーティショニングのセッション。
黒板を使って議論が行われました。
アンカンファレンスとは、講演者や話す内容があらかじめ決まっているのではなく、参加者がその当日にその場で話題を提案して議論する形式のイベントです。
最終的に議論されるテーマは会場にいる参加者の多数決により選ばれ、3つのトラックに振り分けられます。
今年は、プラガブル（Pluggable）なストレージ、パーティショニング、PGAudit、トランザクションIDの64bit化、プランナなど、全部で 9 つのテーマが選ばれました。
この中で、プラガブル（Pluggable）なストレージは、PostgreSQL で様々な種類のストレージ実装を利用可能にする試みです。
PostgreSQL の特徴の 1 つに高い拡張性があります。
例えば、PostgreSQL にはユーザ定義のデータ型や演算子、インデックスを追加することができますし、外部データラッパ（FDW)の機能を使うと様々な外部のデータと連携させることが可能です。
ただし、ストレージに関しては拡張性がなく、現在の PostgreSQL の実装では追記型の MVCC しかサポートしていません。
このことが更新性能の問題となることもありました。
PostgreSQL でデータの特性次第でストレージの実装を選択できるようになれば、このような問題も解決できるかもしれません。
アンカンファレンスではこの機能の実現に向けて、追記を行わない “in-place” な更新、書き込みが一回限りで読み取りは何度もされる WORM (Write Once Read Many) ストレージ、カラム指向ストレージなど様々な方式について議論されていました。
また、講演の紹介の中で述べたとおり、PostgreSQL 10 では宣言的パーティショニングがサポートされました。
しかしながら、まだ必要とされながらも実現されていない機能がたくさんあります。
アンカンファレンスでは今後パーティショニングで実装すべき機能について議論されていました。
講演の紹介の中で紹介したハッシュパーティショニングもその 1 つですが、その他にも、振り分け先の子テーブルが見つからなかった場合にレコードが格納されるデ フォルトパーティションや、パーティションキーの値が変更された場合にパーティション間で自動的にレコードを移動する機能、親テーブルに対してインデックスを作成されたときに子テーブルにそれを伝搬させる機能などは、既にパッチが提案され開発が進んでいます。
その他にも、パーティションテーブルの検索性能の向上や 、ロジカルレプリケーションとの連携や、パーティションの分割や統合の機能など、様々な機能の提案と議論がされていました。
今年の PGCon も様々なテーマの発表がありましたが、やはり、ロジカルレプリケーション、宣言的パーティショニング、パラレルクエリの強化と PostgreSQL 10 の 機能に関するセッションの印象が大きいように感じます。
今回のTシャツには著者の名前（Yugo Nagata）も載りました。
ロジカルレプリケーションはまだ登場したばかりの機能で、これからどのような運用や応用が現れるかとても楽しみです。
パーティショニングは巨大テーブルを効率 的に扱うための仕組みですが、本文でも述べたように他の機能と連携することでその可能性は大きく広がります。
そして、パラレルクエリにより並列化が可能になる領域はますます拡大いくでしょう。
このように PostgreSQL の今後の可能性を象徴するような機能がそろった今度のリリースは、バージョン番号が一新された「PostgreSQL 10」にとって確かにふさわしいものかもしれません。
また、今回の講演ではセッションは全部で 33 個ありましたが、その内5つのセッションは日本からの参加した発表者によるものでした。
この事は日本における PostgreSQL に対する盛り上がりと貢献の意識の高さの現れと言えるでしょう。
今後もこの勢いで、日本から PostgreSQL コミュニティへの参加がますます盛んになっていくと素晴らしいですね。
 |
 |
03-5979-2701 |