ラボユース５期生
神谷孝明
並列WALによるPostgreSQLの
トランザクション高速化の取り組み
1

 筑波大学大学院修士１年
 研究テーマは高性能データベース
 ラボユース開発テーマ：インフラソフトウェア開発
 期間：２０１５年１０月〜２０１６年３月
 内容：PostgreSQLのWALを並列化して
トランザクション処理性能を向上させる
自己紹介
2

 ログ先行書き込み(write-ahead logging)
 データを変更する前にログを書く
 障害がない世界では無駄な処理。。
→現実世界は障害が発生するので必要不可欠
 ログの書き込みでストレージI/Oが発生
 トランザクション処理のボトルネックの一つになりやすい
WALとは…
P1
P1
P1’
P1’ log record
(P1, P1’)1. read
2. update
4. write 3. WAL
DB LogMemory
3

 以前は「ストレージ＝HDD」
 読み書きはできるだけシーケンシャルに行う
 近年、SSDやioDriveなどのフラッシュデバイスが普及
 単純にHDDをフラッシュに変えるだけで速くなる
 並列にI/Oを発行しないとデバイスの帯域を使い切れない
ストレージとして
フラッシュデバイスが普及
0
100
200
300
400
500
600
700
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
ioDriveの書き込み性能評価（マシン：コア数８）
トランザクション処理
トランザクション処理
(直列WAL)
並列書き込み性能
ベンチマーク
better
スレッド数
Bandwidth(MB/s)
4

 並列WALで期待される効果
 メモリ周り（WAL内部の競合緩和）
 ログレコード挿入時のロックの競合緩和
 ログバッファ書き込み時のロックの競合緩和
 IO周り（並列IOによるストレージ帯域の活用）
 ログの書き込み先を複数ファイルに分散させる
並列WAL(1)
worker1
WAL
Buffer
WAL
Buffer
L
衝突が発生
worker2 workerN
L
L
L
L
worker1 worker2 workerN
L
LL
L
衝突が発生しない
5

 並列WALで期待される効果
 メモリ周り（WAL内部の競合緩和）
 ログレコード挿入時のロックの競合緩和
 ログバッファ書き込み時のロックの競合緩和
 IO周り（並列IOによるストレージ帯域の活用）
 ログの書き込み先を複数ファイルに分散させる
並列WAL(2)
worker1
WAL
Buffer
WAL
Buffer
worker2 workerN
L
L
L L
worker1 worker2 workerN
L
LL
L
write要求 write要求…
worker1による
write完了待ち
write write write6
write要求 write要求
各workerが独立に
writeしてよい

 PostgreSQLのWAL並列化で期待される効果
 メモリ周り(WAL内部の競合緩和)
 ログレコード挿入時の競合
→9.4で改善済み
「WALInsertLock（ ）」→
「WALInsertLock（ ）」＋
「WALBufMappingLock（ ）」
 ログバッファ書き込み時の競合
「WALWriteLock（ ）」
 IO周り(並列IOの活用)
 ログの書き込み先を
複数ファイルに分散
PostgreSQLのWAL並列化
7
主な貢献の範囲
PGECons 2014年度WG1活動報告より引用

ラボユースの活動
 (2015年)10月〜(2016年)1月：ソースコードリーディング
 1月〜2月：設計
 2月〜 ：実装＆デバッグ
１月 ２月 ３月１０月 １１月 １２月
ソースコード
リーディング
設計
実装＆デバッグ
進捗度
8

 使用したツール
 emacs + gtags
 タグジャンプが非常に便利
 gdb
 ソースコードで追いきれない箇所はGDBでプロセスにアタッチ
 苦労したところ
 巨大で複雑なソースコード
 .cファイル数：696 行数：763290行
 .hファイル数：591 行数： 83865行
全部は読み切れない・・・
どこまで読めば必要な機能を実装できるか見当をつけて読む
 セマンティクスの理解
 やっていることは分かるが、セマンティクスが分からないコード
→PostgreSQLのドキュメントで該当箇所の調査
ソースコードリーディング
9

 リカバリはできるのか？
 ログレコード毎にユニークなGSN(Global Sequence Number)を発行
 トランザクションの性質（ACID）は守れるのか？
 WAL
 ログを書くまでデータベース上に上書き更新しない
 S2PL (Strict 2-Phase Lock)
 コミットで全てのログを書き込んだ後にまとめてロックを解放する
→同じリソースに対して「A→B」の順で更新操作があって、
Aのログが無いのに、Bのログがあるという状況を防ぐ
 並列WALの場合、さらに制約を加える
 同じトランザクションのログは同じファイルに書く
→コミットログが書かれている場合、それまでの全てのログが書かれている
コミットされたトランザクションがリカバリできないケースを防ぐ
設計上の留意点
10
直
列
W
A
L
と
並
列
W
A
L
で
共
通

 ログを並列に書いた際のリカバリについて
 各ファイルからログレコードを読んでGSNの値を元にマージする
 その後は直列WALのリカバリ方式と同様。
並列WALのリカバリ
9
5
1
7
6
2
8
4
3
1 2 3 4 5 6 7 8 9
Log1 Log2 LogN
11

T
1
T
2
T1をコミット(ロック解放）
並列WALで問題がないことを示すモデル
1 4 5 6
72 3 8
システム障害
障害で消失
T1, T2 1 4 5 6 72 3 8
障害で消失
システム障害
T1をコミット(ロック解放)
分散
WALバッファ
モデル
単一
WALバッファ
モデル
問題（?）：
GSN: 2,3がとぶ
T2はコミットされないので
2,3のログはredoする必要がない。
→分散バッファモデルの2,3のログも
不要なログと言える
ログレコード
T1: 1,4,5,6,
T2: 2,3,7,8
順序依存: 5→7
（5と7は同じリソース
に対する更新）
12

 書いて動かす→詰まる→書いて動かす→詰まる→書いて動かす→
詰まる→書いて動かす→詰まる→．．．（繰り返し）
 これを繰り返せばいつかきっと辿り着くはず。。
 苦労している所
 PostgreSQLはマルチプロセスモデルなのでデバッグが大変
 gdbのfollow-fork-modeやdetach-on-forkを設定して各プロセスをデバッグ
 直接修正した箇所とは異なる箇所でプログラムが落ちる
 たまに動いたりたまに落ちたりする
実装＆デバッグ
13

 リカバリやレプリケーションなどは置いといて
まずはクエリが走るようにする
 各パラメータを変えてベンチマークを取る
 評価結果を研究成果として外部発表する
 (余裕があれば)リカバリのコードにも手を入れて動くものにする
今後の予定＆課題
14

 PostgreSQLに並列WALを実装しようとしていました
 ラボユース期間中には終わりませんでしたが、続き頑張ります。。
 ラボユースの感想
 コードレビューが勉強になりました
 自分がいかに質の低いコードを書いていたか．．．
 深い議論ができる
 トランザクションやWALの専門的な議論ができて楽しかった
 自分の好きなものを開発できる
 研究との両立が可能
まとめとラボユースの感想
15