すぴすらのろぐ

読んだもののメモとかポエムとか

dbts2018 A13/C33（トランザクション関係） 聴講メモ

ポエム TX

db tech showcase 2018 Tokyoの以下のセッションを聴講したメモです。

  • A13 今後のDBのトランザクション処理のあり方について徹底討議する ～"InvisibleWriteRule: トランザクションの書込み最適化" を中心に
  • C33 MVCCにおけるw-w/w-r/r-wのあり方とcommit orderのあり方の再検討～Sundial: Harmonizing Concurrency Control and Caching in a Distributed OLTP Database Management Systemを題材に

Blind Writeについて

xSIGに出された論文 （発表スライド）のInvisible Write Ruleを適用するための条件としてそれ（後のWrite）がBlind Writeである、というものがあった。

Blind Writeとは、書込み対象のタプルをReadせずに、（他のタプル等や外部から与えられた情報を元に）上書きするようなWriteのこと。逆に、書込み対象のタプルを読むWriteは、Read-Modify-Writeという。

Blind Writeが起こりうる状況は何か、なぜ取り除いてもよい無駄なWrite（Invisible Write）が存在するのか、という気持ちを考えていたところ、広義のMaterialized Viewの更新と理解すると納得できた。 ここでいうMaterialized Viewは、SQLのシンタックスとしてのCREATE MATERIALIZED VIEWに限らず、「他のテーブル等や外部の値から計算されるもの」というくらいの意味で書いた。 （センサーデータの例は、エッジ側に生データがあり中央DBにサマリ（Latest値等）を格納する、と解釈する。）

これを突き詰めると、すべてのテーブルは（更新履歴を保持する）ログに対するMaterialized Viewと解釈できてしまうが、 こう考えるとAmazon Auroraが言っているらしい「THE LOG IS THE DATABASE」の気持ちも理解できる。

Blind Writeが起こりうる状況

Materialized Viewの更新（リフレッシュ）方法は大きく2つあり、変更分だけを適用する差分更新タイプと、すべて置き換えてしまう洗替えタイプがある。 ここで差分更新タイプはRead-Modify-Writeに相当し、洗替えタイプがBlind Writeに相当すると言える。

Invisible Writeが存在する気持ち

通常のViewがPull型なのに対してMaterialized ViewはPush型で、必要とされるかにかかわらずWriteすると考えると、（IWRにより除去できる）不要なWriteが存在する気持ちが少し理解できる。

Multi VersionかSingle Versionか

「NoSQL DBはMulti Versionだ」は、「NoSQL DBのストレージは追記型が多く（要出典）で結果的にMulti Versionになっている」くらいに思っている。 （「追記型≒Multi Version」という雑な理解）

NoSQL DBが追記型を選択するのは、一つは実装が簡単だからだと思うが、もう一つは扱うデータが可変長でin-place updateできないからだと思う。 （可変長データを扱うことにより）追記型を選択せざるを得ない状況ならばすでにオーバヘッドのコストは払っているわけで、Multi Versionを扱うときの懸念はConcurrency Controlの難しさだけだ、ということになりそう。

long toransactionについて

long toransactionとしてIn-database バッチ処理を考えると、一つの救いはそれがone-shot requestとみなせるところだと思う。 でもlong transaction（バッチ）が参照するデータをshort transaction（オンライン処理）が更新することを考えると、バッチからオンライン処理に対するr-w依存関係ができてしまうが、バッチ処理の完了は遥か先なので、かなりつらい感じがする。

Multi Versionでw-wはコンフリクトじゃない話

Blind Writeする2つのトランザクションが同時に動いたとき、WriteやCommit操作の順序がどうあってもSerializableになる。 それだけでw-wはコンフリクトではないといっていい気がする。

どちらか一方でもRead-Modify-Writeになると、r-w依存関係が発生するので、順序に制約が生まれる（※1）。

※1: 正確には、Multi Versionだから操作の順序に制約はないけど（並行するWrite結果がどちらも同時に存在してよいけど）、後続のトランザクションがどちらがWriteしたデータを見るかに制約が生まれる。