jaws_n_20181212.pdf

Transcript

1. Aurora PostgreSQLをちょっとだけ （AWS-HUB@名古屋⽀部【2018年12⽉12⽇】 忘年会スペシャル ＆ re:Invent振り返LT⼤会） hmatsu47（松久 裕保）
2. re:Invent 2018 前 Aurora Serverless Database with the New Data API https://aws.amazon.com/jp/about-aws/whats- new/2018/11/aurora-serverless-data-api-beta/ Aurora PostgreSQL Serverless (Preview) https://aws.amazon.com/jp/about-aws/whats- new/2018/11/sign-up-for-the-preview-of-amazon-aurora- postgresql-serverless/ 今⽇はこれらのネタは関係ありません。
3. ちなみに DMS Version 3.1.2 登場︕ https://aws.amazon.com/jp/blogs/news/introducing-aws- dms-replication-engine-version-3-1-2/ やっと utf8mb4 がサポートされた（らしい）︕ 今⽇はこの話でもないです。
4. とある事情で PostgreSQL Advent Calendar 2018 になにか書くことに 犯⼈依頼⼈はこの⼈↓ 右⼿に持ってるのはしゃもじです
5. 原因はこれだった Advent Calendar を書いてるどころではなかったらしい
6. 仕⽅がないので書いた https://qiita.com/hmatsu47/items/16b8d3e1eaff9e5a6247 https://qiita.com/hmatsu47/items/7adbe764696b85c637a2
7. 内容 PostgreSQL では、共有バッファでデータのキャッシュとダー ティーページの管理などを⾏う MySQL ではバッファプール MySQL のバッファプールとは違い、PostgreSQL の共有バッ ファは⼤きくしすぎてはいけない（らしい） 全メモリ容量の 1/4 くらいまでにとどめておく 共有バッファから溢れた分について、OS のディスクキャ ッシュでフォローしてもらう思想（らしい） Aurora PostgreSQL 互換版では、フェイルオーバーしたときに 共有バッファと OS のディスクキャッシュは両⽅とも⽣きのこ るの︖ 実験︕
8. 結果 共有バッファはフェイルオーバーしても⽣きのこる そもそも OS のディスクキャッシュに相当する機構がない︖ 共有バッファを溢れた分はキャッシュされないのでスト レージノードへ取りに⾏く（ぽい）
9. ここで RDBMS の仕組みについて⼤雑把に補⾜ データの更新があった場合、 先⾏ログ（Write Ahead Log︓WAL）をシーケンシャル Write でディスクに記録 データページそのものはメモリ上のバッファ／キャッシ ュに記録するだけですぐにはディスクに書き出さない （ランダム Write の抑制） ある程度変更（ダーティーページ）が溜まったところで まとめて書き出す（チェックポイント処理） MySQL のバッファプールや PostgreSQL の共有バッファはこ の⽤途にも使われている
10. ところで Aurora の仕組みは︖ データの更新があった場合、 WAL（Redo Log）をストレージノードとクラスタの Reader（レプリカ）に送り出す メモリ上のバッファ／キャッシュには記録するだけ メモリ上のバッファ／キャッシュはただのキャッシュであっ て、ダーティーページ管理には利⽤していない 追記型のストレージ（SQL ノードとは別ノードで処理） キャッシュ外のデータはストレージノードへ取りに⾏く SQL ノードローカルのディスクは経由しない（ので OS の ディスクキャッシュが使われることはない） PostgreSQL 互換版も同じ（ぽい）
11. もしかして Aurora PostgreSQL 互換版は MySQL 互換版と⽐較して、本家 より遅くなるシーンが多い︖
12. と、ここで思い出した パラメータグループの shared_buffers の初期値 RDS {DBInstanceClassMemory/32768} Aurora {DBInstanceClassMemory/10922} 3 倍違った
13. 資料を漁ってみた あった https://www.slideshare.net/AmazonWebServices/deep- dive-on-the-amazon-aurora-postgresqlcompatible- edition-dat402-reinvent-2017 P.29 〜 30 「No Double Buffering」 Aurora PostgreSQL 互換版では全メモリ容量の 3/4 を共有 バッファに取る仕様（⼆重のバッファリングはしない）
14. めでたしめでたし まてよ︖ 「PostgreSQL の共有バッファは⼤きくしすぎてはいけない」 んじゃなかったの︖ 理由の 1 つはチェックポイント処理（ダーティーページ 書き出し︓Aurora では不要）の負荷だけど…
15. つづく 気が向いたら… その前に、明⽇⼤阪の re:Invent 2018 ダイジェストに⾏けたら 聞いて来よう 午前中の検査でストップがかからないことを祈る
16. ありがとうございました