Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

サイボウズ・ラボ成果発表会

5,667 views

Published on

第5期ラボユース成果報告会のスライドです。

Published in: Technology
  • Be the first to comment

  • Be the first to like this

サイボウズ・ラボ成果発表会

  1. 1. ラボユース5期生 神谷孝明 並列WALによるPostgreSQLの トランザクション高速化の取り組み 1
  2. 2.  筑波大学大学院修士1年  研究テーマは高性能データベース  ラボユース開発テーマ:インフラソフトウェア開発  期間:2015年10月〜2016年3月  内容:PostgreSQLのWALを並列化して トランザクション処理性能を向上させる 自己紹介 2
  3. 3.  ログ先行書き込み(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
  4. 4.  以前は「ストレージ=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の書き込み性能評価(マシン:コア数8) トランザクション処理 トランザクション処理 (直列WAL) 並列書き込み性能 ベンチマーク better スレッド数 Bandwidth(MB/s) 4
  5. 5.  並列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
  6. 6.  並列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してよい
  7. 7.  PostgreSQLのWAL並列化で期待される効果  メモリ周り(WAL内部の競合緩和)  ログレコード挿入時の競合 →9.4で改善済み 「WALInsertLock( )」→ 「WALInsertLock( )」+ 「WALBufMappingLock( )」  ログバッファ書き込み時の競合 「WALWriteLock( )」  IO周り(並列IOの活用)  ログの書き込み先を 複数ファイルに分散 PostgreSQLのWAL並列化 7 主な貢献の範囲 PGECons 2014年度WG1活動報告より引用
  8. 8. ラボユースの活動  (2015年)10月〜(2016年)1月:ソースコードリーディング  1月〜2月:設計  2月〜 :実装&デバッグ 1月 2月 3月10月 11月 12月 ソースコード リーディング 設計 実装&デバッグ 進捗度 8
  9. 9.  使用したツール  emacs + gtags  タグジャンプが非常に便利  gdb  ソースコードで追いきれない箇所はGDBでプロセスにアタッチ  苦労したところ  巨大で複雑なソースコード  .cファイル数:696 行数:763290行  .hファイル数:591 行数: 83865行 全部は読み切れない・・・ どこまで読めば必要な機能を実装できるか見当をつけて読む  セマンティクスの理解  やっていることは分かるが、セマンティクスが分からないコード →PostgreSQLのドキュメントで該当箇所の調査 ソースコードリーディング 9
  10. 10.  リカバリはできるのか?  ログレコード毎にユニークなGSN(Global Sequence Number)を発行  トランザクションの性質(ACID)は守れるのか?  WAL  ログを書くまでデータベース上に上書き更新しない  S2PL (Strict 2-Phase Lock)  コミットで全てのログを書き込んだ後にまとめてロックを解放する →同じリソースに対して「A→B」の順で更新操作があって、 Aのログが無いのに、Bのログがあるという状況を防ぐ  並列WALの場合、さらに制約を加える  同じトランザクションのログは同じファイルに書く →コミットログが書かれている場合、それまでの全てのログが書かれている コミットされたトランザクションがリカバリできないケースを防ぐ 設計上の留意点 10 直 列 W A L と 並 列 W A L で 共 通
  11. 11.  ログを並列に書いた際のリカバリについて  各ファイルからログレコードを読んで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
  12. 12. 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
  13. 13.  書いて動かす→詰まる→書いて動かす→詰まる→書いて動かす→ 詰まる→書いて動かす→詰まる→...(繰り返し)  これを繰り返せばいつかきっと辿り着くはず。。  苦労している所  PostgreSQLはマルチプロセスモデルなのでデバッグが大変  gdbのfollow-fork-modeやdetach-on-forkを設定して各プロセスをデバッグ  直接修正した箇所とは異なる箇所でプログラムが落ちる  たまに動いたりたまに落ちたりする 実装&デバッグ 13
  14. 14.  リカバリやレプリケーションなどは置いといて まずはクエリが走るようにする  各パラメータを変えてベンチマークを取る  評価結果を研究成果として外部発表する  (余裕があれば)リカバリのコードにも手を入れて動くものにする 今後の予定&課題 14
  15. 15.  PostgreSQLに並列WALを実装しようとしていました  ラボユース期間中には終わりませんでしたが、続き頑張ります。。  ラボユースの感想  コードレビューが勉強になりました  自分がいかに質の低いコードを書いていたか...  深い議論ができる  トランザクションやWALの専門的な議論ができて楽しかった  自分の好きなものを開発できる  研究との両立が可能 まとめとラボユースの感想 15

×