postgresql 9.6 新機能紹介

Copyright©2016 NTT corp. All Rights Reserved.

祝リリース！PostgreSQL 9.6新機能紹介！~長年待ち望まれてきた機能から、NTTデータ、NTTOSSセンタがホンキで開発貢献した機能までトコトン解説~

日本電信電話株式会社NTTオープンソースソフトウェアセンタ澤田雅彦

@NTTデータオープンソースDAY 2016 (11/16)

2Copyright©2016 NTT corp. All Rights Reserved.

1. PostgreSQLについて簡単に紹介

2. PostgreSQL9.6新機能紹介

3. 今後のPostgreSQL

4. まとめ

目次


• PostgreSQL Global Development Groupが主体となり開発

• 1994年にSQLをサポートし、1996年にPostgreSQLに名前を変えた

• 今年20周年

•最新バージョンは9.6.1 (10/27リリース)

• 同時に9.1系がEOL

PostgreSQLとは？


• Uberの記事 (7月26日)

• “Why Uber Engineering Switched from Postgres to MySQL”

• 初PGConf.ASIA 2016開催予定 (12月1,2,3日@秋葉原)

• アジアを横断したPostgreSQLの国際カンファレンス

• 第二回PgDay Asia 2017開催予定(2017年3月@シンガポール)

• アジアを横断したPostgreSQLの国際カンファレンス

最近話題になっているPostgreSQL


PostgreSQL 9.6新機能紹介


2011

2012

2013

PostgreSQLは、年1回のメジャーバージョンアップをしています。

PostgreSQLのこれまで

9.1 (2011-09)

・同期レプリケーション

9.2 (2012-09)・大幅な性能向上

9.3 (2013-09)・マテリアライズドビューの実装・更新可能ビューの実装・フェイルオーバ時間の大幅な短縮・DDLトリガの実装

2014

9.4(2014-12)

・更新ログの書き出し性能向上・マテリアライズドビューの改善・遅延レプリケーションの実装・ロジカルデコーディングの実装

2015

9.6 (2016-9)

・パラレルクエリ・VACUUM性能向上・マルチ同期レプリケーション・FDW強化

本日ご紹介部分

2016

9.5 (2016-1)

・UPSERTの実装・BRINの実装・Row-Level Securityの実装・pg_rewindのコア機能化・同時実行性の改善


主要機能を解説します

性能向上

• パラレルクエリ

VACUUMの性能、運用性向上

• Freeze Map

• VACUUM進捗

レプリケーション

• マルチ同期レプリケーション

外部データ連携(FDW)

• FDW強化


パラレルクエリ

(Robert Haas, Amit Kapila, David Rowley, many others)

“Parallelism” by Maciej Meller


多くのユーザが待ち望んでいた機能の一つ

https://postgresql.uservoice.com/forums/21853-general


CPU

パラレルクエリってどんな機能？ -これまでのPG -

サーバプロセス

巨大なテーブル

SELECT * FROM tbl;

• 1つのSQLを1つのプロセスでしか処理できない

• 巨大なテーブルを扱うと、処理に時間がかかってしまう

• 特に集計、結合処理を行うと1プロセスにかかる負担は増大する

スキャン


CPU

CPU

CPU


パラレルクエリってどんな機能？

巨大なテーブル

SELECT * FROM tbl;



スキャン

スキャン

スキャン

連携

連携

• 1つのSQLを複数のプロセスで分担して処理できる

• 1つのSQL処理速度が向上する

• CPUリソースを効率的に使うことができる

• パラレルクエリはシーケンシャルスキャン、結合処理、集計処理で有効


パラレルクエリ実現には以下の機能が必要

① 実際に処理を行うプロセスを制御する機能

② プロセス間のコミュニケーション領域を作る機能

③ 並列処理中は一貫した情報を見えるようにする機能

④ 並列結果をまとめる機能

⑤ 並列処理を意識した実行計画を立てる

PostgreSQLコミュニティが長年準備してきた機能の一つ

PG9.3(2013)

PG9.4(2014)

① ワーカープロセスを動的に起動可能

② 共有メモリを動的に確保可能

③ ワーカープロセスで一貫した情報がみれる機能

④ 並列処理結果をまとめる機能

⑤ 並列処理を意識した実行計画を立てる

① 独自のワーカープロセスが定義、起動可能

完成

PG9.5(2015)

PG9.6(2016)


9.6でパラレル(並列)処理できるのは、

検索と集計と結合

何がパラレルになる？

Seq Scan Nested Loop JoinHash Join

avg()min()max()

count()など


これまでの集計処理

集計(Agg)

集計結果

テーブルスキャン(SeqScan)

テーブル

=# SELECT count(*) FROM test_table;

1プロセスでスキャン、集計を

実施


集計処理の並列化

部分集計(Partial Agg)



集める(Gather)

集計結果

集計結果集計結果

集計結果

テーブルスキャン(Partial SeqScan)



集計結果

集計結果

テーブル

集計結果

• テーブルスキャン、集計を並列で実行可能

• 各プロセスで部分的な集計を行い、最後に結果をまとめる

行数/3

行数/3

行数/3

最終集計(Final Agg)


これまでの結合処理

結合(Nested Loop Join)


インデックススキャン(IndexScan)

内部表

外部表

=# SELECT id FROM hoge h, bar b WHERE h.id = b.id;


結合処理の並列化







内部表内部表

結果をまとめる(Gather)

外部表

• 各プロセスで外部表のスキャン、内部表との結合を実施

• Hash Joinも並列実行可能

行数/2

行数/2


• クエリ実行の並列度を変えて全件スキャンを実施

• CPUコア数分(並列度４)までクエリが高速化した

どれくらい速くなる？

0

5

10

15

20

25

1 2 3 4 5

実行

時間

(秒)

並列度

13GBテーブルの全件スキャン

CPU：4コアメモリ：32GB

約1/4の実行時間


•並列度決定に物理CPU数は考慮されない

• テーブルサイズを元に並列度を算出

• CPUコア数以上の並列度が設定されないように

•ディスクI/Oに気を使おう！

使用上の注意点


• 1つのSQL処理を複数のCPUで並列に実行• 1つのSQL処理速度を上げる機能

• Seq Scan、Nested Loop Join、Hash Join、集計が対応• 更新、削除、ソート、Merge Join、Index Scanは未対応

•「並列に処理する実行計画」も含み、最適な実行計画が選択される• “パラレルクエリを使った方が遅い”と判断されることも

•並列度はテーブルサイズを元に設定される

絶賛機能、性能検証中！

詳しい情報は随時発信していきます！

パラレルクエリまとめ


PostgreSQLが管理するトランザクションIDのメンテナンスのために、定期的(デフォルトでは2億トランザクション毎)にデータベース全体のVACUUMが実行されます。

9.5までのPostgreSQL

いつも通りの処理♪急にDB全体が重くなった！

半年後のある日


=# SELECT pid, state,

now() – query_start as duration, query

FROM pg_stat_activity;

-[ RECORD 1 ]---------------------------------------

pid | 43556

query | autovacuum: VACUUM

| public.very_large_table (to prevent

| wraparound)

state | active

duration | 5 days 18:50:44.256561②

5日間以上VACUUM実行中

PostgreSQLで実行されているSQLの状況を見てみると・・・

①“to prevent wraparound”

が付いている


Freeze Map

(Masahiko Sawada, Robert Haas)

The Unsung Founders Memorial at UNC. It's an interesting table sculpture dedicated to the men and women of color who helped build the University. by Jed Record


非常に重要な機能(でも内部の細かい話になるので、その重要さが伝わりづらい。。）

Freeze Mapとは？


内部構造に興味がある方は

http://www.slideshare.net/pgdayasia/introduction-to-vacuum-freezing-and-xid


このVACUUM(通称XID周回防止VACUUM)では全テーブルを問答無用でフルスキャン• ディスクI/OやCPUを消費

• DBサイズに比例してより大きい影響を受けやすくなる

XID周回防止VACUUMがいつ発生するかはPostgreSQL次第• 繁忙期、閑散期関係なく実行される

• ただし、事前に意識的にメンテナンスしておくことで、ある程度制御することは可能

キャンセルできるが、実行しないままでいると、PostgreSQLがある日突然停止する

Q. なぜ今になって解決されたのか？(これまで問題にならなかったのか？)

A. 近年DBに格納するデータが大きくなってきたことにより、問題が顕在化してきたため。

甘く見ていると危険


•これらの悩みを解消

•デフォルトで有効• オーバーヘッドを極力少なくなるように実装しているため、新

機能導入によるデメリットはほぼない

• OFFにできない

• DBMSの重要な部分を改変したため、万が一のときの対処策も一緒に追加

• pg_visibilityモジュール

• pg_truncate_visibility_map

• pg_check_visible, pg_check_frozen

• VACUUM (DISABLE_PAGE_SKIPPING)

Freeze Map


=# SELECT pid, state,

now() – query_start as duration, query

FROM pg_stat_activity;

-[ RECORD 1 ]---------------------------------------

pid | 43556

query | autovacuum: VACUUM

| public.very_large_table (to prevent

| wraparound)

state | active

duration | 5 days 18:50:44.256561②

5日間以上VACUUM実行中

PostgreSQLで実行されているSQLの状況を見てみると・・・

①“to prevent wraparound”

が付いている


Vacuum Progress Checker

(Amit Langote, Robert Haas, Vinayak Pokale, Rahila Syed)


=# SELECT pid, datname, relname,

((heap_blks_scanned / heap_blks_total::numeric(10,2)) * 100)::numeric(10,2) as percentage,

p.phase,

index_vacuum_count

FROM pg_stat_progress_vacuum as p, pg_class as c

WHERE p.relid = c.oid;

-[ RECORD 1 ]------+-----------------

pid | 100026

datname | postgres

relname | pgbench_accounts

percentage | 19.72

phase | scanning heap

index_vacuum_count | 10

-[ RECORD 2 ]------+-----------------

pid | 100027

datname | postgres

relname | very_large_table

percentage | 95.12

phase | scanning heap

index_vacuum_count | 300

進捗状況の確認やチューニングにも使える

他ビューと組み合わせることで、・VACUUM対象のテーブル・進捗状況(パーセンテージ)・今何をしているか・VACUUMの効率など算出可能


主要機能を解説します

性能向上

• パラレルクエリ

VACUUMの性能、運用性向上

• Freeze Map

• VACUUM進捗


• マルチ同期レプリケーション

外部データ連携(FDW)

• FDW強化


レプリケーション機能の歴史

9.0(2010)

9.4(2014)

9.5(2015)

9.6(2016)

9.2(2012)

9.3(2013)

9.1(2011)

・同期レプリケーション

・カスケードレプリケーション

・スタンバイサーバへの高速切り替え

・レプリケーションスロット・ロジカルデコーディング

・高速フェイルオーバー

M S S

M S

S

レプリケーション機能の拡充、使いやすさの向上

・非同期レプリケーション


マルチ同期レプリケーション

(Masahiko Sawada, Beena Emerson, Michael Paquier,

Fujii Masao, Kyotaro Horiguchi)

Polska > Kraków by antifluor


同期レプリケーション

http://www.slideshare.net/hadoopxnttdata/postgresql-39739357


PG9.5 までのレプリケーション

マスタ

スタンバイA

スタンバイB

スタンバイC


非同期レプリケーション


• マスタサーバは複数のスタンバイサーバを持つことができるが、同期レプリケーションを使用

できるのは最大1台まで

同期レプリケーションを使えるのはスタンバイAの1台のみ


マルチ同期レプリケーション

マスタ

スタンバイA

スタンバイB

スタンバイC




• 複数のスタンバイサーバに対して同期レプリケーションを使用可能• より高可用な構成を組むことが可能に

スタンバイAとスタンバイBに同期レプリケーションを使用


構成例

マスタ

● 同期レプリケーションを使用したWAL二重書き込み(pg_receivexlog使用)

WALWAL

のみ

スタンバイ同期



● 同一DC内に同期スタンバイを複数配置

マスタ

スタンバイ

スタンバイ




Foreign Data Wrapper(FDW)強化

(Etsuro Fujita, Shigeru Hanada, Ashutosh Bapat)

pot shards by psyberartist


新機能紹介の前に - Foreign Data Wrapper(FDW)とは？

ID, COL100, 北海道200, 青森県

id col

100 北海道

200 青森県

id col

100 北海道

200 青森県

PostgreSQL

Oracle

CSVファイル

oracle_fdw

file_fdwSELECT id, col FROM tbl

外部データをあたかもPostgreSQLのデータとして扱える機能


• postgres_fdwを使った分散処理構成は、「どれだけ外部サーバで処理させるか」が重要• 親サーバが全てのデータを取得して計算、では外部サーバを使うメリットを生かせな

い

• 演算子、条件句も一緒に送る(Push Downする)ことが大切

分散処理基盤を続々と強化中

SELECT price FROM 3月分WHERE genre = …

1,2月分

postgres_fdw

子サーバ

3,4月分 5,6月分

SELECT … WHERE …

親サーバ


•参照

• スキャンやWHERE句により絞込み外部サーバで実行される

• New!! 結合、ソート処理も外部サーバのリソースが使える

•更新

• New!! 更新、削除を外部サーバに依頼可能

挿入、集計、他の結合等は現在開発中！

分散処理基盤を続々と強化中


今後のPostgreSQL

Future Energy by Floris Oosterveld


• PostgreSQL開発に注力している会社が、PostgreSQL開発のロードマップを公開

• パラレルクエリ導入が、PostgreSQLの様々な処理のパラレル化を加速

• ロジカルレプリケーションを含め、様々なレプリケーション機能が追加されていく

• 外部データ連携機能(FDW)がさらに強化されていく

• パーティショニング専用の構文が導入され、簡単に使えるようになる

https://wiki.postgresql.org/wiki/PostgreSQL10_Roadmap

• PostgreSQLのバージョニングが変わる

今後のPostgreSQL


バージョニングが変わります！

～PG9.6 PG10~

9.6.0

9.5.0メジャーマイナー

9.5.1 11.0

10.0メジャーマイナー

10.1


•本日はPG9.6の目玉機能を紹介しました

• PostgreSQL 9.6でパラレルクエリを初めとした200以上の機能が追加されました

• NTTデータ、NTT OSSセンタが開発貢献した機能も多数

•大規模データの管理、処理がH/Wリソースを効率的に使いながら可能になった

•今後のPostgreSQLはパラレル化、レプリケーション強化にも期待

まとめ


ご清聴ありがとうございました


• Too old snapshot

• Idle_in_transaction_session_timeout

• CREATE ACCESS METHOD

• Generic WAL Interface

• Bloomインデックス

•類似度検索の強化(Word Similarity Search)

•待機イベント

• postgres_fdwで演算子をPush Down可能に

•部分インデックスを使用した、Index Only Scan

(参考) その他の改善

postgresql 9.6 新機能紹介

Software