んにちは。開発エンジニアのd_shr(id:d_shr)です。

前回はNode.jsのことを書いていましたが、今回はPostgreSQLのことを書きます。

前回投稿した記事

• はじめに
• PostgreSQL10 変更点
• ロジカルレプリケーション
• • PostgreSQL9.6までのレプリケーション
  • PostgreSQL10 ロジカルレプリケーション
  • 所感
• パーティショニング
• • これまでのパーティショニング
  • 宣言的テーブルパーティショニング
  • 所感
• パラレルクエリの強化
• • PostgreSQL9.6で対応していたもの
  • PostgreSQL10で追加されたもの
  • 所感
• その他
• まとめ
• 参考

はじめに

最近、PostgreSQLについて調査する機会がありました。
主にPostgreSQL9系やPostgreSQL10の変更点を調査しましたが、その中でも最新のPostgreSQL10について書きます。
PostgreSQL10はリリースから半年以上経っており今更ですが、新機能や変更点で気になったものをピックアップしてまとめようと思います。

PostgreSQL10 変更点

• ロジカルレプリケーション
• 宣言的テーブルパーティショニング
• 改善された並列問い合わせ
• その他

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

PostgreSQL10でPublish/Subscribeによる論理レプリケーションが実装されました。

PostgreSQL9.6までのレプリケーション

マスタからスタンバイにトランザクションログを転送し適用することでデータの複製を実現していました。
対象はデータベース全体。完全な複製でスタンバイには物理的な変更はできないものでした。

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

レプリケーション先に対して変更したレプリケーション情報を送付できるようになります。
トランザクションログを「テーブルに〇〇を挿入しました」のように論理的な変更内容として転送することができます。
データベース全体をレプリケーションするのではなく、特定のテーブルの情報やinsertだけをレプリケーションすることが可能です。
レプリケーション情報のやりとりにPublish/Subscribe(出版/購読型)モデルのメッセージ送信を用いています。
複製元でPUBLICATIONを作成し、複製先でSUBSCRIPTIONを作成することでテーブルの同期とレプリケーションが行われます。
INSERT, DELETE, UPDATEには対応していますが、CREATE TABLEなどには対応してません。

所感

柔軟にレプリケーションできるようになったという印象を受けました。
学生の頃にPub/Subモデルのメッセージングを用いた開発をしていたので興味深い内容でした。

パーティショニング

パーティショニングとは、巨大な親テーブルを複数の子テーブルに分割することです。
今までパーティショニングの手順がめんどうだったのですが、CREATE TABLE文でパーティショニングが構築可能になりました。

これまでのパーティショニング

1. 親テーブルを作成
2. 親テーブルを継承する子テーブルを作成
3. CHECK制約を作成
4. 親テーブルにINSERTトリガを作成 ......

宣言的テーブルパーティショニング

CREATE TABLE文で構築可能 1. 親テーブル作成 PARTITION BY構文 2. 子テーブル作成 PARTITION OF構文

所感

PostgreSQL9.5でもUPSERTが追加されていましたが便利な構文が増えたということで使ってみようかなと思いました。

パラレルクエリの強化

パラレルクエリとは、PostgreSQL9.6で追加された大きなテーブルに対するクエリを並列問合せで実行することです。
パフォーマンスの向上が期待できます。
PostgreSQL9.6で追加されたパラレルクエリ(並列問い合せ)がPostgreSQL10で強化されています。

PostgreSQL9.6で対応していたもの

• シーケンシャルスキャン
• 結合(nested loop, hash join)
• 集約

PostgreSQL10で追加されたもの

• インデックススキャン(B-tree, index only scan, bitmap heap scan)
• 結合（merge)
• 非相関副問合せ

所感

パラレルクエリ自体、バージョンアップで既存のシステムに取り入れるのは難しいのかなという印象を持っています。
これからも並列化はどんどん強化されそうな流れなので、パフォーマンス向上に繋がるなら考慮するべきなのかなと思います。
正しく理解しておきたい機能だと思いました。

その他

PostgreSQL10.3の修正で
他ユーザからの search_path を使った「トロイの木馬」攻撃を防御する PostgreSQL とアプリケーションの設定方法がドキュメントに記載されました。
pg_dump や他のクライアントプログラムで安全でない search_path 設定の使用が回避されました。 *1

PostgreSQLのpublicスキーマの仕様によるもので、悪意あるユーザがpublicスキーマに不正な挙動を行うユーザー関数を仕込んでおくことができます。
他のユーザがその不正なユーザ関数を一般のユーザ関数として実行させることで攻撃（漏えい、改ざんなど）ができてしまう問題がありました。
「pg_dump」「pg_upgrade」「vacuumdb」などの管理者ユーザで実行されるアプリケーション関してはsearch_pathからpublicスキーマが取り除かれました。

PostgreSQLの仕様が原因になっていることなのでpublicスキーマの設定を見直す必要もあり 既存のシステムで問題に直面しそうな場合は、運用面のことを考えるのなかなか辛いなという印象を受けました。

まとめ

PostgreSQL10についてまとめました。
個人的に興味深い技術が使われていたものや、構文が追加され便利になったものなどありました。
また、パフォーマンスの向上に繋がることや脆弱性に関連した修正もあり、正しく理解しておかないといけないこともあるなと思いました。