Vacuumとzheap

Copyright©2018 NTT Corp. All Rights Reserved.
Vacuumとzheap
NTT OSSセンタ
澤田雅彦
2018/3/30 BDI勉強会

2Copyright©2018 NTT Corp. All Rights Reserved.
自己紹介
澤田雅彦
@sawada_masahiko
NTT OSSセンタ
NTTデータ入社(2012年)
PostgreSQLの技術サポート
PostgreSQLの本体開発
Replication, Vacuum, Distributed Transaction
PostgreSQLの周辺ツール開発
 pg_repack – オンラインメンテナンスツール
 pg_bigm – 2-gram全文検索モジュール

• PostgreSQLおさらい
• アーキテクチャ
• MVCC
• Vacuumの問題点と改善
• ストレージエンジンAPI
• zheap
目次
PostgreSQLの現状の話
まだ導入されていない機能の話

• プロセスモデル
• Postmasterプロセス：接続の受付、Backendプロセスのforkなどを行う
• Backendプロセス : SQLを処理するプロセス
• DBデータは共有バッファを使ってプロセス間で共有する
PostgreSQLのアーキテクチャ
DBデータ
（テーブル、インデックスなど）
共有バッファ WALバッファ
WAL
（トランザクションログ）
backendbackendbackend
(postgres)
postmaster wal writer
bg writer
auto
vacuum
stat
collector
logger
archiver
wal
receiver
wal
sender
wal
sender
wal
sender
wal
sender
wal
senderbg worker
その他
制御情報
startup

• トランザクションID（XID）
• トランザクション毎に割り当てられるID。単調増加。32bit。
• xmin : 追加したトランザクションID（INSERT/UPDATE)
• xmax : 削除したトランザクションID（DELETE/UPDATE)
• cmin : 追加したコマンドのID
• cmax : 削除したコマンドのID
コマンドIDはカーソルを利用した時等に利用される
追記型アーキテクチャ
xmin xmax cmin cmax Column
100 110 0 0 ‘A’
100 1 ‘B’
110 130 0 1 ‘A-1’
120 0 ‘C’
130 0 ‘D’
130 1 ‘A-2’
xid(100) : INSERT ‘A’;
xid(100) : INSERT ‘B’;
xid(110) : UPDATE ‘A’ -> ‘A-1’;
xid(120) : INSERT ‘C’;
xid(130) : INSERT ‘D’;
xid(130) : UPDATE ‘A-1’ -> ‘A-2’;

• 各トランザクションのステータスを管理するファイル
• 2bit/Txで表現
• 00 : in-progress
• 01 : committed
• 10 : aborted
• 11 : sub-transaction committed
• トランザクションIDから「どのclogファイルのどの部分
」を見るべきかがわかる
• 可視性判定の度に毎回clogを見るのは遅い
• clogの内容をタプルヘッダにキャッシュ（Hint Bitと呼ばれる）
して二回目以降はclogを見ない
clog（Commit Log)

• 削除済みタプルを回収して、再利用可能にする機能（
Garbage Collection）
• 実行中トランザクションの最小のxminより、タプルのxmaxが小
さい場合、回収可能
• VacuumはINSERT/DELETE/UPDATEとは競合しない
• 不要領域を再利用可能にするが、テーブルサイズは縮小
しない
• ただし、テーブルの末尾が空になった時は切り詰められる
• auto vacuum機能により、自動的にバックグラウンドで
実行される
• 頻度はテーブル毎に設定可能、”ゆっくり”vacuumする事も可能
• 「ゴミタプルがある可能性のあるブロック」を管理する
ことで効率的にVacuumする
• Visibility Mapと呼ばれる
Vacuum概要

Block 0 (8kB)
Block 1
：
Block 100
：
Block 198
Block 199
Vacuum概要（Visibility Mapの利用）
11 00 11 11 ..... 11 01
• Visibility Mapは2bit/blockで、1bit目で「ブロックにゴ
ミタプルがある可能性があるかどうか」を表す
• 「Xブロック目に対応するビットが１」＝「Xブロック目
はVacuumしなくてよい」
• どのくらいゴミがあるかどうかはわからない
「block 0は飛ばし、block 1はVacuumする」みた
いな感じで動作する。
けど、本当はOSのプリフェッチを活かすために
、32ブロック連続で1じゃないと飛ばさない

• テーブルの先頭から末尾まで(※)を読んで、ゴミタプルを探す
• (※)Visibility Mapを見て、ゴミがある所だけ読む
• ゴミタプルが一定量溜まったらテーブル、インデックスのゴミを
回収する、を繰り返す
Vacuum概要（処理の流れ）
テーブル
スキャン
テーブル
Vacuum
インデックス
Vacuum
インデックスなしインデックスあり
※インデックスが2つある場合

1. テーブルを常に先頭から読もうとする
2. シングルプロセスでしかできない
3. インデックスを常に全て読む
4. DBの稼働状況を考慮しない
Vacuumの問題

• ゴミがある可能性があるブロックを管理するマップ（
Visibility Map）である程度効率化できるが、どれくらい
ゴミがあるかの情報はない
• 「テーブル内のゴミはある程度局所化されているのでは
？」という前提の元、”最もI/Oコスパの良い範囲”に集
中してVacuumをする
• 特定のIDへの更新の集中
• 特定の期間に関連するタプルへの更新の集中
テーブルを常に先頭から読もうとする

• TPC-C(order_line)
テーブルを常に先頭から読もうとする

• TPC-C(order_line)
テーブルを常に全て読もうとする

Vacuumの並列化
W1 W2 W3
並列化

1. テーブルを常に先頭から読もうとする
• “最もゴミタプルがありそうな場所”のみをVacuumする
2. シングルプロセスでしかできない
• 並列化する
3. インデックスを常に全て読む
• ゴミタプル数に応じて、インデックスツリーを辿りながら回
収対象を探す
4. DBの稼働状況を考慮しない
• リソースマネージャー？
Vacuumの問題

• 富士通オーストラリアの開発者が提案
• PostgreSQLのストレージ周りは、他のコンポーネントと
密に連携しているので調整が大変そう
• FDW（SQL/MEDの実装系）との比較
• FDWはDDLに対応していない
Pluggable Storage Engine

• 同じトランザクションモデルを使う、もしくはトランザ
クションに対応しない
• 同じWALストリームを利用する
• タプルはTID（TupleID:ブロック番号とオフセット）によ
って識別される
• ストレージによって異なるMVCCを実装できるようにす
る
• など
ストレージエンジンAPIで合意していること

PostgreSQLのストレージAPI

（参考）MySQLのストレージAPI
https://dev.mysql.com/doc/internals/en/api-reference.html

• EnterpriseDB社が開発中の新しいストレージフォーマット
• heap = PostgreSQLの追記型テーブルの呼称
• UNDOログを使ってin-place updateを可能にする
• 今月始めにgithubで公開＆コミュニティに提案
• https://github.com/EnterpriseDB/zheap
zheap

• ストレージAPI対応としているが、リポジトリ上のコー
ドではストレージAPIを使っていない
• UNDOログの実装自体は一般的なもの
• 古いタプルをUNDOログに退避して、ROLLBACK時に戻す
• heapと比べて、
• ゴミタプルがたまりにくい（テーブルの肥大化を避けれる）
• タプルヘッダが小さい(xmin/xmaxはない)
• ページ毎にUNDOログへのポインタを持つ
• Vacuumが必要ない。XID周回もない。
特徴
※2018/3/30現在の情報です。将来変更されるかもし
れませんし、私がコードを見ただけなので間違っている
かもしれません。

• ロングトランザクションがいる限りUNDOログ領域が大
きくなる
• ロングトランザクションが終わると、undo workerが必要無くな
ったUNDOログを消す
• ページ毎にあるUNDOログへのポインタは最大4個
• ページ内の4タプル以上が同時に更新されると、ポインタの空き
ができるまで止まる
• undo workerが非同期的に必要なくなったUNDOログ領
域を削除する
• タプル削除後、領域を再利用するコードが見つけられな
かった
特徴（２）
※2018/3/30現在の情報です。将来変更されるかもし
れませんし、私がコードを見ただけなので間違っている
かもしれません。

イメージ
backendbackendbackend
UPDATE
INSERT
UPDATE
INSERT
UPDATE
lp
tuple
UPDATE
UNDOログ・ファイル (１ファイル = 4MB)
ページ
• １つのbackendにつき、１つのUNDOログファイルが割り当てられる
• 各UNDOログファイルは、4MBのUNDOログセグメントに分けられている
• 削除される単位も4MBのファイル
• 各UNDOログファイルの状況は、DSMで共有
• DSMは必要になった分だけ確保されるようになっている
• $PGDATA/base/undoにUNDOログを保存。$PGDATA/pg_undoに永続化用のデ
ータを保存。
lp
tuple

テーブルサイズ比較
http://amitkapila16.blogspot.jp/2018/03/zheap-storage-engine-to-provide-better.html

• Vacuumの効率化
• 並列化
• 局所化
• zheap
• UNDOログベースのテーブル
• Vacuumが必要なくなる
• Pluggable Storage Engineが導入されるとPostgreSQL本体でも使
えるようになるかも
まとめ

Vacuumとzheap

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Vacuumとzheap

Similar to Vacuumとzheap (20)

More from Masahiko Sawada

More from Masahiko Sawada (20)

Recently uploaded

Recently uploaded (10)

Vacuumとzheap