Weitere ähnliche Inhalte Ähnlich wie PostgreSQL10徹底解説 (20) Mehr von Masahiko Sawada (20) Kürzlich hochgeladen (10) PostgreSQL10徹底解説5. 約7年ぶりの大型アップデート!
• 約 200 個の改善点
• 大きい機能を多く導入
• バージョン番号が2桁に変更 (9.6.0 → 10.0)
• わかりやすさ・使いやすさ向上のために、一部後方互換性をなくして
改善
9.09.0 9.19.1 9.29.2 9.39.3 9.49.4 9.59.5 9.69.6 10.010.0
2010 年リリース 2017 年リリース
9. ネイティブ・パーティショニング
• ” ネイティブ”・パーティショニング
• これまでもパーティショニング機能はあった
• しかし、複数機能 (CHECK 制約、テーブル継承、トリガ ) を組み合わせ
た「なんちゃってパーティショニング」
• 性能面、運用面で多くの課題があった
• なにが良くなった?
• パーティショニング専用の DDL が追加
• 性能向上
• プランナがパーティショニング情報を考慮して
• 動くようになった
親
子 子子
10. パーティショニングの DDL
-- 親テーブルの作成
=# CREATE TABLE parent (c1 int, c2 int) PARTITION BY RANGE;
-- 子テーブルの作成
=# CREATE TABLE child1 PARTITION OF parent FOR VALUES FROM (0) TO (100);
=# CREATE TABLE child2 PARTITION OF parent FOR VALUES FROM (100) TO (200);
-- 子テーブルの取り外し
=# ALTER TABLE parent DETACH PARTITION child2;
-- 子テーブルの取り付け
=# ALTER TABLE parent ATTACH PARTITION child2 FOR VALUES (100) TO (500);
14. パラレルクエリとは?
• 1つの SQL を複数の CPU を活用して並列に処理する機能
• 特に大きなデータを処理するような分析系クエリで大活躍
• PostgreSQL 9.6 から導入された機能
テーブルテーブルプロセスプロセス
プロセスプロセス
プロセスプロセス
テーブルテーブル
1プロセスでの処理 複数プロセスでのパラレル処理
15. パラレルクエリが更に強化
• Scan
• Sequential Scan
• Bitmap Heap Scan
• Index Scan
• Index Only Scan
• Join
• Nested Loop Join
• Hash Join
• Merge Join
• PostgreSQL 10 でさらにパラレルクエリが使える場面が増えた
• ただし、 UPDATE/DELETE, DDL は未対応
QUERY PLAN
----------------------------------------------------------------
Finalize Aggregate
-> Gather
Workers Planned: 2
-> Partial Aggregate
-> Parallel Index Only Scan using a_idx on a
Index Cond: ((c >= 100) AND (c <= 300000))
(6 rows)
QUERY PLAN
----------------------------------------------------------------
Finalize Aggregate
-> Gather
Workers Planned: 2
-> Partial Aggregate
-> Parallel Index Only Scan using a_idx on a
Index Cond: ((c >= 100) AND (c <= 300000))
(6 rows)
20. Foreign Data Wrapper(FDW) とは?
OracleOracle
PostgreSQLPostgreSQL
CSV ファイルCSV ファイル
SELECT * FROM
oracle_tbl WHERE
amount < 100;
PostgreSQL を”ハブ”のようにして、外部データ ( 他の DBMS 、 NoSQL 、ファイ
ル、 Web サービス等 ) と連携できる機能
oracle_tbl
pg_tbl
file_tbl
oracle_fdw
postgres_fdwpostgres_fdw
fle_fdw
fle_fdw
21. FDW 、 postgres_fdw の機能が強化された
• Join 、 Sort に加え Aggregation (集約)が push down 対応した
• より外部サーバのリソースを使って処理できるようになった
QUERY PLAN
------------------------------------------------------------
Aggregate
Output: sum(col)
-> Foreign Scan on public.s1
Output: col
Remote SQL: SELECT col FROM public.s1
QUERY PLAN
------------------------------------------------------------
Aggregate
Output: sum(col)
-> Foreign Scan on public.s1
Output: col
Remote SQL: SELECT col FROM public.s1
QUERY PLAN
----------------------------------------------------------------
Foreign Scan
Output: (sum(col))
Relations: Aggregate on (public.s1)
Remote SQL: SELECT sum(col) FROM public.s1
QUERY PLAN
----------------------------------------------------------------
Foreign Scan
Output: (sum(col))
Relations: Aggregate on (public.s1)
Remote SQL: SELECT sum(col) FROM public.s1
■ 9.6 以前 ■ 10 以降
② ローカルでスキャン結果を
集計
① リモートのデータをスキャン
① リモートでスキャン・集計
を両方実行
SELECT sum(col)
FROM s1; ?
22. FDW を使って並列分散処理
• “PostgreSQL と PostgreSQL と連携させる”というアイディア
• さらに、パーティショニングを組み合わせて分散処理させる
User ID
100 ~ 200
User ID
200 ~ 300
User ID
300 ~ 400
postgres_fdw
postgres_fdw
postgres_fdwpostgres_fdw
postgres_fdw
postgres_fdw
user_tbl
child_1
child_2
child_3
SELECT count(*) FROM
user_tbl WHERE
user_id = 300;
23. ここまでのまとめ
• パーティショニング
→専用 DDL が用意されたことにより運用が楽になった
→INSERT 性能が大幅に向上
• パラレルクエリ強化
→IndexScan 、 IndexOnlyScan 、 BitmapHeapScan 、 Parallel Merge に
対応した
→UPDATE/DELETE, DDL の対応はまだ
• FDW を使った並列分散 DB 化
→集約関数が PushDown されたことにより、並列分散 DB 化がより現実的に
→ただし注意点はまだまだあるので、使うときは気をつける
25. レプリケーション
• フィジカル ( 物理 ) レプリケーション
• バイナリ情報 ( トランザクションログなど ) をスタンバイへ送信する
• DB まるごと複製 ( バックアップなど ) するときに良く利用される
• PostgreSQL では 9.0(2008 年 ) から導入された
• ロジカル ( 論理 ) レプリケーション
• 論理的な変更情報 (SQL など ) をスタンバイへ送信する
• テーブル単位、 DB 単位等の細かい粒度が指定可能
• PostgreSQL では 10.0(2017 年 ) から導入
26. PostgreSQL のロジカルレプリケーションは Pub/Sub モデル
• Publication( 上流 ) と Subscription( 下流 ) を設定
• Publication は複数テーブルを指定可能
• Subscription は複数 Publication を指定可能
• UPDATE/DELETE を複製するためにはプライマリキーまたは、 NOT NULL UNIQUE
キーが必要
TABLE
A
TABLE
B
TABLE
C
TABLE
D
sub_hoge
sub_bar
TABLE
A
TABLE
B
TABLE
C
TABLE
D
TABLE
C
TABLE
D
Publisher 側 Subscriber 側
27. 設定例( Publication の作成)
-- Publication 作成
=# CREATE PUBLICATION test_pub FOR TABLE t1, t2 WITH (publish = ‘insert, delete’);
-- Publication 確認
=# dRp+
Publication hoge_pub
All tables | Inserts | Updates | Deletes
-------------+----------+-------------+---------
f | t | f | t
Tables:
"public.t1“
"public.t2"
• 複数テーブル、または DB 全体を複製対象として設定可能
• Subscription 毎に複製する操作を指定可能
•
28. 設定例( Subscription の作成)
-- Subscription 作成
=# CREATE SUBSCRIPTION hoge_sub CONNECTION ‘port= ... ‘ PUBLICATION hoge_pub;
-- Subscription 確認
=# dRs+
List of subscriptions
Name | Owner | Enabled | Publication | Synchronous commit | Conninfo
---------- --+--------------+------------+----------------+----------------------------+---------------------------------------
hoge_sub | masahiko | t | {hoge_pub} | off | dbname=postgres port=5550
(1 row)
• Subscription を作成した時点からレプリケーションが開始される
• レプリケーション開始時に初期データのコピーを実行される
29. モニタリング
-- Publisher 側
=# SELECT application_name, state,
write_lag, flush_lag, replay_lag, sync_state
FROM pg_stat_replication ;
-[ RECORD 1 ]-----+----------------
application_name | hoge_sub
state | streaming
write_lag | 00:00:00.003926
flush_lag | 00:00:00.003926
replay_lag | 00:00:00.003926
sync_state | sync
-- Subscriber 側
=# SELECT * FROM pg_stat_subscription ;
-[ RECORD 1 ]------------+------------------------------
subid | 16388
subname | hoge_sub
pid | 15796
relid |
received_lsn | 0/1693EC8
last_msg_send_time | 2017-07-10 12:30:17.383905-07
last_msg_receipt_time | 2017-07-10 12:30:17.383994-07
latest_end_lsn | 0/1693EC8
latest_end_time | 2017-07-10 12:30:17.383905-07
-- Subscriber 側
=# SELECT * FROM pg_stat_subscription ;
-[ RECORD 1 ]------------+------------------------------
subid | 16388
subname | hoge_sub
pid | 15796
relid |
received_lsn | 0/1693EC8
last_msg_send_time | 2017-07-10 12:30:17.383905-07
last_msg_receipt_time | 2017-07-10 12:30:17.383994-07
latest_end_lsn | 0/1693EC8
latest_end_time | 2017-07-10 12:30:17.383905-07
30. 仕組み
• PostgreSQL のロジカルレプリケーションで送信しているのは
SQL” ではない”
• MySQL の Row-based Replication 相当
TABLE
WAL
wal
sender
wal
sender
apply
worker
apply
worker
TABLE
WAL
backendbackend
①
Write
②
Read
③
Decode ④
Send
⑤
Write
⑤
Write
①
Write
31. ロジカルレプリケーション
できること
• テーブル、 DB 単位でのレプリケ
ーション
• 初期データの転送
• コンフリクトの解消(手動)
できないこと
• DDL レプリケーション
• テーブル、
• Publication 、 Subscription 単
位での同期レプリケーション
• 双方向レプリケーション(マルチマ
スター)
• テーブル以外のレプリケーション
(シーケンスなど)
33. Quorum ベース同期レプリケーション
• Quorum( 定足数 ) ベースとは ?
• “quorum とは分散システムにおいて、分散トランザクションが処理を実行するため
に必要な最低限の票の数である。” (Wikipedia より )
• 5 台の内、 3 台から応答が返ってきたら COMMIT とする、と言った感じ
• 9.6 までは応答を待つスタンバイは”固定”だった
マスタ
スタンバイ A
スタンバイ B
スタンバイ C
マスタ
スタンバイ A
スタンバイ B
スタンバイ C
スタンバイ A,B から応答
が返ってくるまで待つよ
3 台の内どれか 2 台
から応答が返ってくれ
ばいいよ
応答
停止中・・・
9.6 までの方式 Quorum ベース
34. 設定方法
• FIRST 、 ANY で同期方法を選択
• N で台数を指定
• 例
• FIRST 2 (node1, node2, node3)
• node1, node2 の 2 台からの返答を待つ
• ANY 2 (node1, node2, node3)
• node1, node2, node3 の内 2 台からの返答を待つ
synchronous_standby_names = [ ANY | FIRST ] N (node1, node2, ... )synchronous_standby_names = [ ANY | FIRST ] N (node1, node2, ... )
35. 使い所・注意点
• N 台の中から K 台に同期的にデータを複製するという所は
同じ
• 選び方の違いがあるだけ
• 性能面では ANY の方が優位
• 遅いスタンバイに性能が引っ張られないため
• ANY では今どれが同期スタンバイかは状況によって異なる
• レプリケーション状況は pg_stat_replication で確認
37. 全 22 個の非互換箇所
• Hash インデックスは再作成する必要がある (pg_upgrade を使用し
た場合 )
• “xlog” が” wal” に変更
• pg_xlog ディレクトリ、 XXX_xlog() 関数など、全ての xlog が wal に名称変
更
• pg_clog ディレクトリが pg_xact ディレクトリに名称変更
• “lsn” が” location” に変更
• 主に XXX_location() 関数が XXX_lsn() に称変更
• デフォルトで localhost からのレプリケーション接続が有効になった
• pg_ctl がデフォルトで”待つ”動作になった
:
38. ここまでのまとめ
• PostgreSQL 10 では非互換箇所が多い!
• 運用ツールに影響があるもの、セキュリティ的に影響があるものなの
で、バージョンアップの際は必ず確認することを推奨します
• 一覧はリリースノートでチェック
39. まとめ
• PostgreSQL 10 は現在 Beta2
日本人開発者も多く参画している
• リリースは 9 月頃を予定
• 正式リリースを待ってもよし
• リリース前に使ってみるのもよし
• 不具合を見つけたらバグレポください!
• 英語が・・・というかたは日本 PostgreSQL ユーザ会の slack でも OK
• もしくは、 @sawada_masahiko に連絡ください
43. 参考資料
• Next-Generation Parallel Query
• https://www.pgcon.org/2017/schedule/attachments/445_Next-
Generation%20Parallel%20Query%20-%20PGCon.pdf
• 次期バージョン PostgreSQL 10 の新機能とその後の方向性
• https://www.sraoss.co.jp/event_seminar/2017/db_tech_show_cas
e_oss_2017.pdf
• PostgreSQL 10 がやってくる!
• https://www.slideshare.net/toshiharada/jpug-studypostgre-
sql10pub