TOPへ

基本情報

発表者

• メインセッション：fujii_masao さん

参加者

Connpassページを参照のこと。

司会（管理者）

• こば

アジェンダ

当日出た質問と回答（サマリ）

（議論）SIReadLocksとは何か、どこで使われるのか。
　- postgresではSSI（Seriarizable Snapshot Isolation）で使うもの。
　- 分離レベルごとで使われるロックが違うのか。
　- SSIで使うもの。述語ロックなので範囲でロックしていたと記憶。Repeatable Read(=SI)では使われてないはず。
　- SIReadLocksとPredicated Locksは一つのもの？防ぐアノマリーから考えると別のもののように見える。
  - その辺りは次回の内容で改めて触れるはず。

（議論）キャッシュの容量ってどれぐらいあると良いのか？物理メモリの何%とか基準があるか。
　- DBMSごとに違いがある。postgresはカーネルキャッシュも必要なので25%などとドキュメントに記載がある。
　- HugePagesなどとも関連がありそう。
　- 過去のLinuxカーネルでは共有メモリの上限に到達しまって、物理メモリをいくら積んでもpostgresの共有バッファが増やせないケースがあった。

（議論）postgresには何故O_DIRECTのサポートがないのか。
　- 端的にいうと、だれもそうしたパッチを書いてないから。
　- 考え方として、postgresのストレージエンジンが物理まで理解しなくても良いようにしている。
　- ただ、最近はコミッタがO_DIRECTや非同期IOを積極的に使う話をしている。
　- 現状あがっているのはio_uring。

（議論）O_DIRECTなどを使った場合、Windowsへのポーティングってどうするのか。
　- Noバッファリングという指定があるので、地道にやってる。

（議論）関連するすべてのWALをディスクに書き込むというのはどう判断してるのか。
　- 10番までみたいにLSNの位置だけを記録していて、そこまで書ければpostgresではOK。

（議論）WALの書込みが直列化されてるのは性能ネックにならないのか。
　- postgresではロックでやってるので遅い部分はある。ロックの最適化はやってる。
　- WALの書込みが詰まる場合、どうチューニングしたら良いのか。
　- グループコミットなんかもある。ログバッファが小さいということもあるので、その場合は大きくする。
　- ログの量を変に増やさない、HOTなどを有効活用する。
　- WALコンプレッションというのもある。IOネックをCPUネックに変換する。fujiiさんが作っている。

（議論）WALの圧縮はなんのアルゴリズムを使っているのか。
　- pglz。TOASTなどでも使われている。
　- 他の圧縮アルゴリズムを入れるという案もあった。

（議論）WALでIOが高速なNVDIMMを使うという案もあるのか。
　- NTT研でパッチを作っていた。
　- WALにNVRAMを使うとレイテンシが減る。その他にそもそものフォーマットをWrite Behind Logなどに変えてしまうという方法もある。
　- ストレージにflushする必要がないはず。PostgreSQL Unconferenceで堀川さんが発表してた。

（議論）不揮発メモリでも電源断-再投入後に、どこにデータがあるかを理解できるのか。
　- それはもちろん出来る。
　- Intel OptaneだとNamespaceを割り当てて、そこにデータが永続化されているのが識別できる。

当日のチャットログ

- シングルマスターだと何でこんな当たり前のことやるんだろうと、思ってました。そして分散DBでなく、ACIDの世界。
- postgresだと4種類のロックを使い分けている。
- SIReadLocksって何だろう。
- SSIを実現するために使うやつです＞SIReadLocks
- 低い分離レベルでは使われない、ってことです？
- ストレージキャッシュもある図、好みです。
- Postgreの実際の例があるからわかりやすいなー
- はい、そうだったと思います＞低い分離レベル
- Oracleだとバッファが3層ぐらいにわけて使えましたね。名前忘れたけど。
- 参照されているページとピン留めされているページはどう違うのでしょうか？参照するページをビン留めする
- という理解
- Keepプールとかですね。
- そうだ、Keepがピン止めですね。マルチバッファプールという機能でした。
- アクセスの可能性が高いページを恣意的に留めておくわけか
- カーソルのFETCHがさしている行のバッファは、ピンされっぱなしです。
- バッファマネジメントはHDD時代に特に重要だったと思うのですが、今はどうなんでしょうか。みなさん、再起動後のprewarmとかはします？
- ベンチマークするときは必須！？
- SSD時代になってからやらなくなりましたね。
- パッチ適用後に、インスタンス停止前の状態にバッファを戻して、アプリのレスポンスへの影響を小さくしたいというお客さんはいます。
- メモリのサイズ＜ストレージのサイズなので、やはり必要な気がしますがいかがでしょうか？
- 学生ですが、実務として触ったことがないのですごく興味あります＞prewarn
- そうするとOracleのKeepがOSSでも欲しいですよね。
- ないので、昔は定時バッチで重要テーブルをSELECTしてキャッシュに乗せてたり
- 永続メモリで、そういうこと考えなくてもよくなったらよいなぁ。Intel Optane Persistent Memoryは今は最大512 GBなので、OLTPはいけるか？
- CLOCKもまたこの循環バッファの管理がオーバヘッドになるので，シンプルなvectorとアトミック変数２つで実装する手法をMSが提案して評価していましたね
- たしかにCLOCKも中々見つからないことがありそう。
- 今のPostgresで、バッファ管理を改善したくなるワークロードって、あるのでしょうかね？
- ロックフリー！
- postgresはCLOCK、そうだったのか。
- 0 でないことだけが重要なのでインクリメントすればいいだけだから CAS スラ必要ない気がしますが
- TinyLFUって最近どこかのblogで見ましたね。
- 最近、TinyLFUの論文読んでブログにしました
- https://po3rin.com/blog/tinylfu
- あ、そうだ。po3rinさんだった。
- Postgresでも、参照カウントや使用カウントを非常に大きくすれば、KEEPになる？
- repeatable readでも述語ロックがかかるって記事をどっかで観たんですがSerializableだけなんですか？
- Postgres は isolation の粒度が　MySQL より粗いんじゃなかったっけ
- nrhd
- https://www.postgresql.jp/document/12/html/transaction-iso.html
- > PostgreSQLのリピータブルリードの実装ではファントムリードが起こらないことを示しています。
- PostgreSQLのrepeatable readは実質snapshot isolationなのでファントムリードが起こらなかったと思います
- https://www.postgresql.jp/document/12/html/runtime-config-resource.html
- > 1GB以上のRAMを載せた専用データベースサーバを使用している場合、shared_buffersに対する妥当な初期値はシステムメモリの25%です。
- PostgreSQL のドキュメントには 25% が妥当。って書いてありますね。
- 実装が簡単だからですかね？
- Linux以外にO_DIRECTがない？
- 最近 io_uring がでました
- snapshot isolationとSSIの差分は read only anomaly と write skew anomalyというふたつのanomalyで，phantomは入らないですね
- https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf
- ↑によるとSnapshot Isolationだとファントムリードが「Sometimes Possible」になってますね
- なるほど，postgresqlのSI実装はphantomを防ぐが，一般的にSIの実装はphantomもありうる，ということですね．
- Change Data Captureがやってることですね> WALを読み込んで転送
- LSNがログレコードが書き込まれるアドレスってこと？ユニークなのか？
- はい、LSNがアドレスで、一意です。
- 通常はinternal counter or timestamp って書いてありました < LSN
- これは分散システムになると難しいやつですね
- 分散システム、Oracle RACみたいなshared everythingだと、LSNは困りますね。インスタンスごとにREDOログファイルがあるので。
- Oracle RACとかでLSN的なものをどうしてるかを勉強した記憶があるのですが、全然思い出せないです。
- 興味なんですけど、blob みたいな大きいデータを DB で管理したい (or する) ことはありますか？ そのとき WAL の書き出しはデータサイズの分だけ重くなるんでしょうか
- postgresのfull_page_writesとかだとどうなるんだろう > BLOB
- Postgresには、なぜかBLOB/CLOB型がないんですよね。他のDBから移植するときに困ります。
- bytea型では、データ丸ごとを読み書きするので、大きなバイナリを格納するのはつらいかしら。
- SQL標準だと、ロケータという機能で、LOBの一部だけを読み書きできたような。
- BLOB/CLOBの実装って、実体はファイルシステム上に置かれていて、そこへのポインタ(ファイルパス)だけDB内に持っていることが多い印象です。
- DB操作を停めずにsync checkpointingをする手法が最近トップ会議によく投稿されていますね．fuzzy checkpointingと両立するとログサイズが小さくなってよいようです
- OracleだとBFILE型ですね。かなり昔からあるもの。
- でも、ファイルシステムにバイナリを置くと、DBMSによるトランザクション処理やバックアップ/リカバリの恩恵を受けられません。
- それを解消するのが、OracleのSecureLOBやSQL ServerのFILESTREAM機能で、特別な修飾子をLOB型に指定すると、高速に読み書きできつつ、DBMSの恩恵を受けられる。
- unique な　path 名を経由すればいけるのでは
- Postgresには、まだまだ基本的なことでやるべきことがたくさんありそう。
- まず log 粒度の設定ができるんですね。あと blob の実装がファイルシステムに頼るのも知りませんでした。。勉強になります。ありがとうございます
- kumagiさんのblogで読んだやつ。
- CMUの先生はエリーズってよんでました
- https://qiita.com/kumagi/items/f336acb482dea33af0fa
- PostgresではWAL内の探索にはLSNが使われている
- log を一本でなく複数本にして contention を減らす手法も研究されてますね
- wal の圧縮ってどう言うアルゴリズムなんだろう
- pglz
- https://15721.courses.cs.cmu.edu/spring2017/papers/24-nvm/p337-arulraj.pdf
- Bloom filter 確かCassandraで使われていたような
- SSTable に該当 Key があるかを調べるために Bloom filter 使われていますね
- 分散トランザクションだとrecoveryどうなるんだろうと気になったんですが、これは13章ででてくるんですね。（今調べながら）

司会者のいろいろ

感想

• fujiiさんの説明、そしてpostgresの実装と絡めた注釈が非常に分かりやすかった。
• CLOCKとかTinyLFUもDBに絡めると少しわかる気がするので不思議。
• postgresのファイルシステム依存は毎回話に上がるけど、そういう哲学で作られてるという他ないのかも知れない。

反省点

• トランザクションの話になるとRDB勢で話し込みがちなので、もう少しNoSQLな方々と話題を共有すべきだった。
• Concurrency Controlの部分にもどうしても踏み込みがちなので、そこをコントロールしつつ上手く次回の議論テーマを作りたかった。
• 次回は分散DBの同時実行制御（第13章）に踏み込まない勇気が必要。