プラガブルストレージのテーブルへの展開！ ～テーブルアクセスメソッドインターフェイスへの取り組み～ －富士通の技術者に聞く！PostgreSQLの技術－
PostgreSQLインサイド

PostgreSQLは、他の多くのRDBMSと異なり、テーブル内のデータを格納する方法（テーブルストレージ機構）として1つの形式しかサポートしていません。この制約に対し、以前からPostgreSQL開発コミュニティーでは他のテーブルストレージへの対応について議論されてきました。PostgreSQL 12ではその基盤となる、自由にテーブルストレージ機構を追加できる仕組み（テーブルアクセスメソッド）として、「テーブルアクセスメソッドインターフェイス」機能がサポートされました。これにより、独自のテーブルアクセスメソッドを定義できるようになり、PostgreSQLの適用範囲を大きく広げていくことが可能になりました。
この機能は富士通グループの社員がPGCon 2017へ議題を提案し、コミュニティーでの議論に参加し、PostgreSQL 12でのコミット（注1）を実現しました。
本特集では、テーブルアクセスメソッドインターフェイス開発の取り組みについて、FUJITSU AUSTRALIA SOFTWARE TECHNOLOGY（以降、FAST）の「Pankaj Kapoor」が語ります。

• 注1
  ここでのコミットとは、PostgreSQLの正式機能として採用される、の意味です。

テーブルアクセスメソッドインターフェイスとは、どのようなことができる機能でしょうか。

Pankaj
これは、テーブル内のデータの格納を現状のheap以外の方法で実装することを可能とした機能です。
PostgreSQL 11までは、インデックスに対してはbtree、hashといった異なる格納方式を選択できるようにアクセスメソッドが用意されていますが、テーブルに対して同様の機構はありませんでした。
PostgreSQL 12では、インデックスと同様にテーブル用のアクセスメソッドを実装し、異なるテーブルストレージ機構の選択が可能になりました。これが、プラガブルテーブルアクセスメソッドです（注2）。プラガブルテーブルアクセスメソッドでは、ユーザーが独自に作成できるテーブルアクセスメソッドを実装するためのインターフェイスを公開しています。これにより、PostgreSQLの開発者や開発チームがテーブル用に独自のテーブルアクセスメソッドを作成することができます。PostgreSQL 12では、従来から利用してきたheap形式をテーブルアクセスメソッド上に移行し、デフォルトで利用できます。

• 注2
  プラガブルとは、自由に取り付け可能な、拡張可能な、の意味です。

PostgreSQL開発者向けにインターフェイスが設けられたのですね。では、ユーザーがテーブルアクセスメソッドを利用する方法を教えてください。

Pankaj
テーブルアクセスメソッドの定義は、CREATE ACCESS METHOD文のTYPE句にアクセスメソッドの型として「TABLE」を指定します。アクセスメソッドを変更したいテーブル単位に、CREATE TABLE文にUSING句を付けてテーブルアクセスメソッド名を指定します。CREATE TABLE AS SELECT文や、CREATE MATERIALIZED VIEW文でも指定できます。
また、postgresql.confファイルのパラメーター"default_table_access_method"でデフォルトのテーブルアクセスメソッドを指定する方法もあります。

どうしてこの機能が必要と思われたのか、開発の背景と経緯について教えてください。

Pankaj
開発コミュニティーでは、他の多くのRDBMSと同じようにUNDOログを利用できるようにするために、専用のテーブルアクセスメソッドを追加選択できるようにする必要があり、インデックスと同様にテーブルアクセスメソッドを自由に取り付け可能にすることが重要である、と議論されてきました。heapしか対応していないPostgreSQLのテーブルストレージは、コミュニティー内の他のオープンソースの活動（例えば、zHeapやZedstoreなど）にも影響を与えていましたし、そのニーズを満たすことが困難でした。
開発の発端は、2016年に現コミッターのAlvaro Herreraさんによって、カラムナストレージの機構に対応するパッチが作成されたことでした。また、富士通は、自社が持つカラム型ストレージ技術「Vertical Clustered Index（VCI）」をコミュニティーに寄贈したいと考えており、これを推進するために、FASTのHaribabu Kommiさんが開発に参加しました。その後、現コミッターのRobert Haasさんがストレージ層に重点を置いた、汎用的なテーブルアクセスメソッドへの取り組みを提案しました。コミュニティーメンバーは、現コミッターのAndres Freundさんの支援を受けながら、開発、レビュー、修正に多大な労力を費やして、2019年3月にPostgreSQL 12の機能としてコミットに至りました。

この機能のアピールポイントと、この機能が想定している使われ方について教えてください。

Pankaj
この機能のアピールポイントは4点あります。

• 簡潔で自由に取り付け可能なアーキテクチャー、つまり、使いやすくてPostgreSQL開発者に優しい
• ユーザーがテーブルごとに異なるテーブルアクセスメソッドを指定できる
• オープンソースと商用データベースの両方に道を開く
• 1つのデータベース内で異なるテーブルアクセスメソッドの同時共存ができる

PostgreSQL 12ではインターフェイスが設けられただけで、対応するテーブルアクセスメソッドはheapのみですが、PostgreSQLの次バージョン以降では、カラムナテーブルやインメモリーテーブルなどの新しいテーブルアクセスメソッドの提供が期待されています。将来的に、ユーザーはOLTP業務にはheap、OLAP業務にはカラムナテーブル、超高速なデータ検索処理にはインメモリーテーブルと、業務用途に応じて適切なテーブルアクセスメソッドを選択できます。ユーザーが適したテーブルアクセスメソッドを選択できるようにすることで、今後のさまざまな業務処理のニーズに対応できます。

PGCon 2019の発表の中に｢Why not FDW｣のご説明がありましたが、PostgreSQLのForeign Data Wrapper（FDW）とどのような違いがあるのでしょうか。

Pankaj
FDWは外部データにアクセスすることを目的としており、ローカルにデータを格納することを目的としていません。例えば、PostgreSQLからカラム型データベースサーバー内にあるカラムナテーブル型のデータを利用する要件があるとします。FDWの場合は、カラム型DBに対応したFDW（cstore_fdw）を使ってリモートの別サーバーへアクセスする必要があり、その分処理性能が落ちます。テーブルアクセスメソッドの場合は、ローカルにカラムナテーブル型（注3）のテーブルを格納することができ、処理が速くなります。
要するに、FDWとテーブルアクセスメソッドは異なるニーズをターゲットにしています。FDWが異なるサーバー上のデータにアクセスすることを目的としているのに対し、テーブルアクセスメソッドはローカルにデータを格納することを目的としています。

• 注3
  PostgreSQL 12では、カラムナテーブルのテーブルアクセスメソッドには対応していません。

新しいインターフェイスの実現は大変だったと思いますが、苦労した点や工夫した点を教えてください。

Pankaj
この機能に関わったすべてのメンバーが、大量のインフラストラクチャーのコードの改変に苦労しました。FASTのHaribabu Kommiさんによって提供された最初のパッチセットでさえ、100以上のファイルに2500行以上の変更が発生しました。PostgreSQLのストレージ周りは他のコンポーネントと密接に連携しているため、調査や調整が大変でした。このようなレベルの機能を実現するのは、サイズだけではなく、複雑さも考慮しなければならず、非常に労力を要する作業でした。
困難な状況において、富士通グループからの継続的な推進とサポートにより、この機能を開発コミュニティーでコミットすることができました。

本機能はPGCon 2017アンカンファレンスで提案したと聞きましたが、周りの反応はどうでしたか？

Pankaj
アンカンファレンスでは議論する検討テーマを投票で決定するのですが、これはコミュニティーで最も多く投票されたテーマの1つでした。個人の関心だけでなく、さまざまな組織でより多くの必要性が認識され、アンカンファレンスで人気のトピックになりました。

PostgreSQL 12でのコミット後のPGCon 2019では"Pluggable storage"が2つ発表されていましたね。注目のテーマだったのですね。

Pankaj
はい。これはプレゼンテーションルームだけでなく、コーヒーや軽食を摂りながらの議論も活発に行われ、非常に興味深いテーマでした。プレゼンテーションの1つはコミッターの発表で、アーキテクチャーと開発者の見解に焦点を当てていました。もう1つの私の発表はテーブルアクセスメソッドの使用法に触れ、ユーザー視点で説明しました。
詳しくは、PGCon 2019のオフィシャルサイトを参照してください。

• PGCon 2019

PostgreSQL 12リリース後のカンファレンスで、Zedstoreやテーブルアクセスメソッドインターフェイス関連のテーマが議論されているようですが、このような動向についてどうお考えでしょうか？また、注目している議論などがあれば教えてください。

Pankaj
PostgreSQL 14以降で、テーブルアクセスメソッドの可能な実装をいくつかご紹介します。

• heapの改良版（例えば、zHeapなどの行指向の格納、UNDOログ、VACUUMレスを持つもの）
• カラムナテーブル（例えば、Zedstoreなどの列指向の格納、OLAP向き、圧縮機能を持つもの）
• インメモリーテーブル（データをメモリー上に配置して、DBアクセスを高速化するもの）
• インデックス構成テーブル（主キーでソートされた方法でデータが格納されたもの）、など

zHeapとZedstoreはテーブルアクセスメソッドの開発中の実装で、どちらも機能的にとても優れています。私はZedstoreの議論をフォローしており、可能であれば彼らの開発を支援していきたいと考えています。

拡張性の高い機能ですが、さらに追加したい点など、この機能の今後の取り組みについて教えてください。

Pankaj
PostgreSQL 12では、テーブルアクセスメソッドはタプル（行）ベースだけですが、PostgreSQLの今後の可能性を広げる機能の基盤を築くことができました。将来的には、実行エンジンとテーブルアクセスメソッドインターフェイスを組み合わせた最適な実装をサポートしたいと考えています。

PostgreSQL 12で導入されたテーブルアクセスメソッドインターフェイスにより、PostgreSQLユーザーは要件に合わせたテーブルアクセスメソッドのテーブルを作成できるようになったということですね。将来的には、業務の特性に合ったテーブルアクセスメソッドを複数選択することができ、ますますPostgreSQLの活躍の場が広がりそうで楽しみです。今日はありがとうございました。

2020年10月9日公開