PostgreSQL Conference Europe 2024 参加レポート

2024/10/22〜25 にかけて、ギリシャのアテネで開催された PostgreSQL Conference Europe 2024 に参加しましたので報告いたします。

はじめに

 

PGconfEU は、PostgreSQL Europe が主催する大規模なカンファレンスで、毎年ヨーロッパの都市で開催されます。このカンファレンスでは、世界中の開発者やユーザーが一堂に会し、PostgreSQL に関する最新の情報や技術を共有する貴重な機会となります。

筆者は今回はレポーターとしてこのイベントに参加しました。普段は PostgreSQL の技術サポートを業務としているので、今回のカンファレンスでは、多くの知識や経験を吸収し、自身のスキルを向上させることも参加目的の１つでした。

会場となった Divani Caravel Hotel は、アテネの中心に位置し、美しい景色を楽しむことができる場所でした。発表セッションが 4 つの部屋で並行して行われ、参加者はそれぞれ興味のあるトピックに応じてセッションを選ぶことができました。

本レポートではいくつかの印象的な発表をピックアップし、その要点や感想を紹介します。

削除されたデータの復元方法

CYBERTEC の Christoph Berg の講演 “UNDELETE data FROM table;” は、削除されたデータをどのようにして「復元」できるかというテーマでした。データを削除した場合、トランザクション内で削除されたデータならばロールバックによって元に戻すことができますし、
ベースバックアップから PITR（Point-In-Time Recovery）を使ってデータを復旧する方法もあります。
今回はその他の手段として、“pg_dirtyread” という拡張機能を使うことで削除された行を読み取る方法が紹介されていました。

pg_dirtyread を使うと、テーブル内の削除された行も SELECT 文を使って表示できるようになります。特に、出力された行の xmax システムカラムを調べることで、それが削除された行であるかをチェックすることができます。（PostgreSQL では xmax というシステムカラムに行を削除したトランザクションの ID が格納されます。）このように、pg_dirtyread を使用することで、失われた行を再びテーブルに挿入することが可能になりますが、削除された行の内容がその後の更新や VACUUM によってページから失われていた場合には復元することができません。

ページから失われたデータを復元するには、PostgreSQL に同梱されているツールである pg_waldump を使うことで削除されたデータがどのように WAL に記録されているかを確認することができます。PostgreSQL では通常 FPW（Full Page Write）が ON となっており、CHECKPOINT 以降の初回のページ変更時にテーブルのページイメージ全体が WAL に出力されています。そのため、行が削除される前のテーブルページの状態を WAL から確認することができます。PostgreSQL 16 以降では pg_waldump に –save-fullpage オプションが追加され、フルページの内容を保存できるようになりました。この方法を使用することで、削除されたデータが含まれているページを特定のディレクトリに抽出し、それを元にデータを復元することができます。

もちろん普段からバックアップを取るのが重要であり、データ復旧には PITR を利用するのが一般的なのですが、以上のように pg_dirtyread と pg_waldump を使って削除されたデータを復元する方法もあることを紹介する発表でした。

PostgreSQLのコネクションプーラーの比較

コネクションプーラーは、PostgreSQL データベースのパフォーマンスを最適化するための重要なミドルウェアであり、特に接続管理において大きな役割を果たします。この機能によって接続数が過剰になる問題が解決され、データベースの負荷が軽減されます。CYBERTEC の Julian Markwort の講演“Comparing Connection Poolers for PostgreSQL” では PostgreSQL におけるコネクションプーラーの役割や利点、課題、および代表的なプーラーの比較について学ぶことができました。SRA OSS が中心となって開発しているクラスタリングツールで、サポート業務で取り扱うことの多い “Pgpool-II” のコネクションプール機能についても紹介されていました。また、“Odyssey” や “pgagroal” 、“PgCat” といった 2019 年以降に登場した比較的新しいプーラーについても、今回初めて知ることができました。

紹介されていたコネクションプーラーには以下のものがありました：

• Pgpool-II: 様々な機能を持つクラスタリングツール。設定がやや複雑。
• PgBouncer: コネクションプールの機能に特化した軽量のプーラー。
• Odyssey: スケーラブルなマルチスレッド設計のプーラー。
• pgagroal: 高性能を目的に新たに設計されたプーラー。
• PgCat: シャーディング、ロードバランシング、フェイルオーバー機能を持つマルチスレッド設計のプーラー。
• Supavisor: クラウドネイティブなコネクションプーラー。

どのプーラーを選ぶべきかについては、発表者の直感に基づいた個人的意見であると断った上で、以下のような特徴をあげていました：

• PgBouncer は広く使われており、学習コストも低いのでおすすめ。
• PgCat も機能の追加も進んでおり最有力な候補。
• pgagroal は性能問題を時期尚早に解決しようとして行き詰まっているように見え、いくつかの機能も欠けている。
• Odyssey は他のプーラーにも影響を与えた新しい試みだったが、メモリリークなどの問題が残っている。

論理レプリケーションのセットアップを高速化する

EDB の Euler Taveira が発表した “Speeding Up Logical Replication Setup” では、
論理レプリケーションのセットアップを迅速化する方法として、PostgreSQL 17 の新機能「pg_createsubscriber」が紹介されました。

論理レプリケーションを構築したときには、最初にレプリケーションするテーブルデータの初期コピーが行われます。各テーブルごとに起動する tablesync ワーカプロセスの中で COPY … TO STDOUT を利用してデータを取得し、データが同期された後に、論理レプリケーションによる変更の適用が開始されます。しかし、この方法では各テーブルが個別に処理されるため、完了までに時間がかかる場合があります。一方で、pg_createsubscriber は物理ストリーミングレプリケーションのスタンバイサーバを元にして、論理レプリケーションのサブスクライバサーバを作るコマンドあり、テーブルの初期コピーを行わず、論理レプリケーションの構築を迅速に行うことが可能です。この講演では、サイズに応じたパフォーマンス改善の例も示され、例えば 20GB のデータで 13 倍の速度向上が見込まれるとされました。また、今後の pg_createsubscriber コマンドの機能改善のアイデアとして、ベースバックアップからのサブスクライバ構築、完了時のサーバー起動、指定されていないデータベースの削除、特定のテーブルの指定、サブスクライバ構築後に物理スタンバイを無効にしない、といったことを可能にするオプションの追加が挙げられていました。

AI と地理情報システム

Redgate Software の Grant Fritchey が発表した“Leveraging AI as a PostgreSQL DBA” の講演では、データベース管理者（DBA）が AI をどのように活用できるか、またその効果的な使用法について詳しく説明されました。現在、人工知能（AI）は非常に注目されているテーマです。AI は単に「新しい技術」として存在するだけでなく、DBA の仕事をより効率的に行うための強力なツールとなり得ます。具体的な実践例として、いくつかのタスクにおける AI の活用方法が示されました。例えば、データベース設計、データ生成、テストスクリプト作成、クエリ最適化、コード評価などが挙げられます。紹介されたツールには、ChatGPT、Microsoft CoPilot、Google Gemini、Perplexity、You.com、Brave.com などが含まれていました。筆者自身も普段、ChatGPT や Microsoft CoPilot を使用しており、その効果を実感しています。また、AI の結果を鵜呑みにせず、「trust, but verify（信頼するが、確認する）」という考え方を持つことが重要ということが主張されていました。

生成 AI を効果的に活用するためには、AI に与える命令や指示を記述した文であるプロンプトの質が非常に重要です。これに関してはは、以下のポイントが強調されていました。

• Clarity, clarity, clarity: 明確さが重要。
• Use appropriate terms: 適切な用語を使用する。
• More detail is better: より詳細な情報が結果を改善する。
• Context matters: 文脈を理解することが必要。
• Stop digging, start over: 回答の方向性がおかしい場合は、無理やり修正しようとしないで最初からやり直す。

MICROSOFT の Varun Dhawan の講演 “Using Postgres to locate the best coffee near you!” では、PostgreSQL と地理情報を扱うための拡張モジュール “PostGIS”、さらにベクトルデータを組み合わせて、自然言語クエリを活用する方法について説明がありました。特に、「最寄りのコーヒーショップはどこですか？」という質問に対して正確な結果を得る手法が紹介され、PostgreSQL の多様な機能を組み合わせることで、シンプルなキーワードマッチングから強力な文脈認識検索ソリューションへの進化が強調されました。さらに、AI を活用した方法として、ベクトル化されたデータセットから関連情報を抽出し、OpenAI の大規模言語モデルに渡すことで、より正確な回答を生成するアプローチも紹介されました。この手法は RAG（Retrieval-Augmented Generation）という技術で、簡単に言うと、ユーザーの質問に対して、データベースから関連する情報を検索し、その情報を文脈として与えることで、生成 AI からより適切な回答を得る方法です。

RAG のプロセスでは、まずユーザーのクエリ（例えばコーヒーショップの検索クエリ）を受け取り、それをベクトル化します。次に、ベクトルデータベース（PostgreSQL）から関連するコンテキスト（例えば、コーヒーショップのレビュー）を検索し、取得したコンテキストを大規模言語モデル（OpenAI）に渡し、言語モデルが応答を生成する流れとなります。この統合により、AI と PostgreSQL を活用した効果的な情報検索が実現可能となります。

Deriv の Jimmy Angelakos が発表した“–Mom, can we have G**gle Maps? –We have G**gle Maps at home” は、PostgreSQL と PostGIS を使って “OpenStreetMap (OSM)” のデータを取り込み、GISの機能を実現する方法に焦点を当てています。この講演は「高価な API が本当に必要か？既存の無料で強力なオープンデータソースである OpenStreetMap と、PostgreSQL + PostGIS の組み合わせで十分では？」という問題提起から始まりました。OpenStreetMap (OSM) は無料で利用できる地理データベースであり、PostgreSQL と組み合わせることで、さまざまな空間データクエリやジオコーディング（情報に対して関連する地理座標を付加すること）を実現できます。OSM データは、PBF や XML 形式のダンプとしてエクスポート可能で、簡単に PostgreSQL に取り込めます。このプレゼンテーションでは、OSM データを PostgreSQL にインポートするツールとして “PgOSM Flex” の使用が紹介されました。

PostgreSQL セキュリティ

CYBERTEC の Taras Kloba の講演 “PostgreSQL Security:Defending Against External Attacks” では、データベースセキュリティの重要性を再認識させられました。特に、過去の PostgreSQL の脆弱性が悪用されることで LinkedIn や OpenTable などで実際に発生した具体的なデータ漏洩事例に基づいて解説されたことで、PostgreSQL の脆弱性がどれほど危険であるかを深く理解することができました。これにより、データベースのセキュリティ対策が単なるオプションではなく、企業や組織の持続可能性にも直結する必須事項であることを強く認識しました。

具体的な対策として、PostgreSQL の最新パッチを適用すること、アクセス制御を強化すること、SSL 接続を強制すること、そしてTDE（透過的データ暗号化）を導入するなどが紹介されており、日々の業務において重要な手段として非常に参考になりました。さらに、権限昇格による脆弱性を回避するため、ユーザ関数定義時の SECURITY DEFINER の使用を制限することや、COPY FROM PROGRAM の実行権限をスーパーユーザのみに付与するといった実務的なアドバイスも示されており、これらは実際のシステム運用において非常に役立つ内容であったと感じます。

ワイヤプロトコル

現在の PostgreSQL で使用している通信プロトコルは、2003 年にバージョン 7.4 で導入され、以来多くの新機能が追加されていますが、プロトコル自体は大きく変更されていません。このプロトコルは、PostgreSQL の効率的な操作を支え、様々なクライアントライブラリやミドルウェア、さらには他のDBMS実装でも広く利用されています。Neon,inc の Heikki Linnakangas の講演 “The Wire Protocol” はこの通信プロトコルを解説するもので、メッセージ構造、認証、クエリの実行やキャンセル、COPY、レプリケーション機能、将来に向けたプロトコルの拡張といったトピックが含まれていました。

筆者はプロトコルについての知識にあまり馴染みがなかったため、PostgreSQL のプロトコルの特に認証やクエリの実行方法、COPY プロトコルの使用など理解するのが難しい部分もありました。しかし、プロトコルを学ぶことで、データベースがどのように動作しているか、また、より効率的にクエリを実行したりエラーハンドリングを行ったりするための手助けになると感じられ、今後、この講演を機に少しずつでもプロトコルに関する知識を深めていきたいと思うようになりました。

 

マテリアライズドビューの増分更新

弊社の長田の講演 “pg_ivm: Extensions for Rapid Materialized View Update” では、マテリアライズドビューを迅速に更新するための機能を PostgreSQL に提供するの拡張モジュール “pg_ivm” が紹介されました。マテリアライズドビューは、クエリの結果を保存するデータベースオブジェクトであり、クエリ応答を迅速にするために使用されますが、基になるテーブルが変更されると、その状態を最新に保つためにはビューの更新が必要です。pg_ivm は、Incremental View Maintenance（IVM）という手法を使用し、ビューの全ての行を更新するのではなく、「増分」のみを計算して、マテリアライズドビューを迅速に更新できる拡張モジュールです。

この拡張モジュールは、PostgreSQL 13 から 17 のバージョンで使用可能で、通常の REFRESH コマンドで 20 秒かかるビューをわずか 15 ミリ秒で更新できる例が紹介されていました。従来のマテリアライズドビューと比較して、更新が 500 倍以上速くなる場合もあり、大きなパフォーマンス向上が期待できます。また、今後の計画や機能要望として、外部結合や論理レプリケーションのサポートや、GROUPING SET や ROLLUP を含む高度な集計機能の対応があげられていました。

以前、pg_ivm について深く学ぶ機会はありませんでしたが、今回の講演を通じて、学習者としてだけでなく開発者の視点からも、その仕組みなどの難しさを実感することができました。

ライトニングトーク

最後に、最終日に行われたライトニングトークの様子についてご紹介します。

ライトニングトーク（Lighting talks）とは、通常、非常に短いプレゼンテーション形式のことを指します。一般的に、各プレゼンテーションは 5 分から 10 分程度の短時間で行われ、参加者が素早く情報を共有したり、新しいアイデアを紹介したりする場です。

今回のライトニングトークは 13 トピックがあり、その中で私に印象に残ったのは、motherduckdb の Jelte Fennema が発表した “pg_duckdb: Challenges and Benefits of Elephants with Eaks” でした。

“pg_duckdb” は、“DuckDB” を PostgreSQL の内部で利用可能にする拡張モジュールです。DuckDB は「分析用の SQLite」とも呼ばれ、複雑な分析クエリをサポートするインメモリ型の分析データベースです。“SQLite” と同じく組み込み用途のデータベースですが、分析作業に特化しており、非常に効率的に動作します。

pg_duckdb の特徴として、DuckDB の強力な分析エンジンを PostgreSQL に統合することで、ユーザーは従来の SQL エンジンに比べて圧倒的に高速な分析処理を実現できます。この拡張機能は 2024 年 10 月に最初のリリース（v.0.1.0）が公開され、parquet や CSV 形式のデータを BLOB（バイナリデータストレージ）から読み書きする機能を提供します。また、PostgreSQL テーブル上で DuckDB エンジンを使用したり、DuckDB のカラム型フォーマットを利用して一時テーブルを作成したりすることができます。さらに、MotherDuck というサーバーレスのクラウド分析プラットフォームへの分析処理のオフロード機能もあり、より効率的なデータ処理を実現します。この技術は、まるで象がダックに乗っているようなイメージです。象は飛べたり歩けたり泳いだりすることができ、いろんなものを食べて生きていくことができます。同じように、pg_duckdb は環境の変化にも強く、高速な分析を可能にします。