富士通PostgreSQLチームのシニアディレクター Amit Kapilaの目に映るPostgreSQLの未来：技術者Blog
PostgreSQLインサイド

PostgreSQLは、「ACID特性（Atomicity（原子性）、Consistency（一貫性）、Isolation（独立性）、Durability（耐久性））」を備えた強力なリレーショナルデータベースで、活発なオープンソースコミュニティーによって開発とサポートが提供されています。1つの組織が開発の方向性に影響を与えることのない開放的な風土が、継続的なイノベーションのための協働環境を育んできました。
金融、銀行、小売、医療などの業界では、独自の商用データベースシステムからオープンソースへの移行に関心が集まっています。これに対応するため、PostgreSQLコミュニティーでは、より広範な実装に対応できるように改良された機能を開発しています。
この記事では、富士通PostgreSQLチームのシニアディレクター Amit KapilaがPostgreSQLで何が起こっているのかについて、個人的な見解を共有します。

Amit
PostgreSQLは1つの組織によって運営されているわけではないので、これから述べるコメントや見解はすべて私個人の意見です。私が数年先に向けて考えているのは、高可用性、水平スケールまたはシャーディングによる書き込みスケールアウト、並列処理、およびロジカルレプリケーションの改善です。この話題については、私の前回のブログでも議論しています。
PostgreSQLコミュニティーには、具体的なロードマップはありません。しかし、現在の傾向とコミュニティーで提案されている内容を確認すると、高可用性、スケールアウト、新しいストレージエンジン、パフォーマンス、スケーラビリティーの改善が見られます。
ここで強調したい3つの分野は、ロジカルレプリケーション、並列処理、スケールアウトです。

ロジカルレプリケーション

我々は、ロジカルレプリケーションのフレームワークにおいて、実行中のトランザクションおよびプリペアド状態のトランザクションのデコードを可能にすることに取り組んでいます。
これは、2つの別々の機能で構成されています。実行中のトランザクションをデコードすることにより、サブスクライバーへの適用遅延を減らし、パブリッシャー側でI/Oを実行する大量で大規模なトランザクションを回避します。これにより、大量のトランザクションを扱うロジカルレプリケーションの全体的なパフォーマンスが向上します。このインフラストラクチャーを使用することで、以前は処理に時間がかかり、CPU使用率が非常に高くなっていた、多くのDDLを持つトランザクションの問題を解決しました。1,000パーティションを持つテーブルの消去を含むトランザクションのデコードが、以前は4分から5分かかっていましたが1秒で完了することが報告されています。
プリペアド状態のトランザクションをデコードすることにより、ロジカルレプリケーションの設定に、2フェーズの分散コミットを許可するオプションをユーザーに提供します。これは、コンフリクトのないロジカルレプリケーションの基礎となります。
これら両方の機能をロジカルレプリケーションで使用することにより、ロジカルレプリケーションの適用範囲が格段に広がります。

並列処理

PostgreSQLでは並列処理の改善を毎年行っていますが、今年はさらなる改善を試みています。特に、PostgreSQL 13で基盤作りに取り組んだ並列書き込みの改善です。これは、書き込みを分割して並列に実行することでパフォーマンスを改善できるケースが確認されています。私たちは、並列処理の技術でPostgreSQLデータベースに大量データをロードする分野を改善しようとしています。
また、UpdateやDeleteなど他のDML操作を並列化することにも非常に興味を持っています。

スケールアウト

コミュニティーでは、並列外部スキャン、2フェーズコミット、外部テーブルのバルクロードの改善のための活発な作業が進行中です。
postgres_fdwを使用して外部のPostgreSQLサーバーに格納されたデータにアクセスする場合、パフォーマンスが向上する可能性があります。これにより、大規模システムへのPostgreSQL適用促進が期待できます。

Amit
強調した3つの分野以外にも強化したいと思っている分野はいくつかありますが、代表的なものに以下があります。

データ暗号化

現時点で言えることは、この機能に興味を持っている組織は多く、コミュニティーでも積極的に取り組んでいるということです。これは非常に大規模な機能であり、完成までに複数のリリースが必要になることが想定されます。そのため、完成時期を見積もるのは難しいのですが、PostgreSQLコミュニティーはこの機能に取り組んでいますし、現在PostgreSQLが適用されていない分野にも適用領域や利用を拡大できるので、PostgreSQLにぜひこの機能を搭載したいと思っています。

信頼性と拡張性

コミュニティーでは、特にフェイルオーバーや業務停止が発生した場合の信頼性向上に不可欠な、高可用性に取り組んでいます。これはPostgreSQLが改善しようとしている重要な分野の1つです。また、スケーラビリティーに関しては、シングルノードとマルチノードシステムの両方で、大規模なデータベースシステムでの普及を拡大するための改良を進めています。

AIと自律機能

私たちには具体的なロードマップがないので、例え優先度の高い方向性があったとしても、コミュニティーがこの方向に向かっていると断言できません。しかし、特にクラウドプロバイダーがデータベースサービスを提供し始めてから、セルフチューニング、セルフプロビジョニング、セルフスケーリングなどの自律機能が業界でより顕著になってきているので、PostgreSQLに取り組んでいるさまざまな企業がこの分野への開発を計画する可能性があります。結果的に、これはコミュニティーへの提案につながる可能性があり、私はこのような業界動向を歓迎します。
PostgreSQLではすでにセルフチューニングといった機能の開発が行われています。例えば、リリースごとに自動バキューム機能を継続的に改善しており、特に最新リリースでは、この分野での大幅な改善がセルフチューニングに役立っています。

ツール群

明確な計画はわかりませんが、PostgreSQLの監視と統計を改善するための取り組みが行われており、これらはPostgreSQL内部で何が起こっているのかを診断するのに役立ちます。なぜ遅いのか?なぜ止まってしまったのか?パフォーマンスはどうか?、などを解明するためのツール、ユーティリティー、機能はリリースごとに開発されています。私が明確に言及できるツールはありませんが、ユーティリティーでは、データベース統計の可視性を改善するための作業が行われています。

Amit
PostgreSQLの特長の1つは、多くの組織が簡単に改変したり拡張したりできるようにするライセンスと著作権条件です。これはPostgreSQLの適用範囲を広げ、真に唯一無二なOSSデータベースにするという点で非常に有効です。
データベースエンジンのランキングや、PostgreSQLに関わる企業の数を前年比で見てみると、PostgreSQLの人気が着実に上昇していることがわかります。これは、PostgreSQLが非常に優れたオープンソース・モデルであることを表していると確信しています。
また、PostgreSQLコミュニティーがPostgreSQLに加える変更の管理方法にも私は感銘を受けました。それぞれの変更は徹底的にレビューされています。このレビューは、少なくとも1人、特にパッチの場合は複数の人によって行われます。最終的なコードがリポジトリーに入るのは、PostgreSQLのコミッター、レビュー担当者およびコードの原作者が納得した場合のみです。そのため、加工・レビューなどの多くのフィルタリングを経て、優れた機能とコードだけが新しいリリースに組み込まれます。
このモデルは、PostgreSQLを採用したり、差別化されたソリューションで市場参入できるよう迅速に機能を構築したいと考えている一部の企業によって採用され、より強化されています。繰り返しになりますが、私はこれはPostgreSQLにとって良いことだと思っています。

今後も定期的にブログ発信していくことを楽しみにしています。

2020年11月20日公開