snapshotとserializableの違い。そしてgroup commit。

@kumagi @h_kaw 同じアイテムに対するロックなら、lock escalationと言います。

2011-12-09 16:54:18

@taroleo @h_kaw 同じアイテムに対してread lockとwrite lockを獲得する、という事ですか？その場合は確かに上位互換なwrite lockが有ればread lockが不要なのはわかるのですが、別のアイテム相手でも成り立つのではないでしょうか、と。

2011-12-09 16:57:17

@kumagi @h_kaw 別々のアイテムに対するr(x), w(y) lockで、r(x)をcommit前に手放すのは、snapshot isolationとか、serializableでないプロトコルになるかと

2011-12-09 16:57:35

@taroleo @h_kaw serializableとsnapshotって分離レベル異なるのでしょうか（恥ずかしながら同義語だと思っていました）手放してしまってもserializableなんじゃないかなと思っていたのです…。

2011-12-09 17:00:38

kumagi @kumagi_bot

例えば「a==10の場合に限りb=5を代入」する場合、aのReadLock,bのWriteLockを同時に獲得すれば、その瞬間をコミットと見做してaのReadLockを解放してからbに書きこむ事が出来る。仮に書きこむ対象が複数でもWriteLock取ってるので外部から観測されない

2011-12-09 17:02:04

@kumagi @h_kaw xの値を使ってyを更新するケースがあるので、serializableにするにはxの書き換えをcommit前にできないようにする必要があります。snapshotがあれば、xの２つのversionが作られるのでserializableにできます

2011-12-09 17:03:03

@kumagi @h_kaw 関連して、ディスクにまとめて書き出すなど、group commitと呼ばれる技術もありますよ。

2011-12-09 17:05:34

@taroleo @h_kaw なるほど。つまりReadSetとして手元に複製を作った場合は「snapshotがある」状態なのでserializableと認められるんですね。でもReadSetじゃなくてxを直接使ったwriteの場合はダメ、と。

2011-12-09 17:06:20

@kumagi @h_kaw はい。x->yという依存関係がないなら、そもそも別トランザクションでいいのでは？ということで

2011-12-09 17:07:08

@taroleo @h_kaw ありがとうございます！疑問がすっきり解消しました！

2011-12-09 17:09:37

@taroleo @h_kaw 一見関連してる雰囲気では無いのですが、writeもsnapshotな分離を成せるのならディスク書き出しという遅い操作の間readのロックを解放していられる、という戦略でしょうか。探してみるとずいぶん歴史のある技術のようですね…。

2011-12-09 17:13:23

@kumagi @h_kaw 一応コミットしてロックも解放されるのですが、ディスクへの書き出しをあとでまとめて行う点で似てるかな、と。

2011-12-09 17:17:04

@taroleo @h_kaw ACIDのうちDが満たされなさそうな気がするんですけれど多分なにか独自の戦略によって解決してる…んですよね？

2011-12-09 17:20:59

@kumagi @h_kaw log書き出しのタイミングが遅れるので単純に解決できるとは思いませんが。ただ、その工夫だけで性能がかなり出るのでペイしてるとは思います。毎回fsyncするのと、データがたまってからfsyncすると違いで、後者が速いのは当然なので

2011-12-09 17:30:08

@kumagi @taroleo 横からすみません．素人@h_kawです．Group commitはWAL高速化のために開発された技術だと思います．詳細は次の論文がお勧めです．

2011-12-09 17:30:16

Snapshot IsolationとSerializable Isolationの違いを理解した。古いSnapshotに基づいて値を書き換える場合がある。トランザクション「A=Bの時にA-=100」と「A=Bの時にB-=100」が同時にcommitされうる。

2011-12-09 17:30:56

@h_kaw @kumagi @taroleo Spiro, P. M., Joshi, A. M. and Rengarajan, T. K.: Designing an Optimized Transaction Commit　Protocol

2011-12-09 17:30:57

@h_kaw @kumagi @taroleo , Digital Technical Journal, Vol. 3, No. 1, pp. 1–16 (1991).　です．twitterってホント不便ですね．10000文字くらい書きたい．．．

2011-12-09 17:31:30

@h_kaw @kumagi @taroleo group commit前に関する議論，まだ読めてないので，後で見させて頂きます．申し訳ありません．@taroleo先生，色々と勉強になります．ありがとうございます．

2011-12-09 17:32:12

@h_kaw @taroleo 論文ググってました。1991とか僕保育園前じゃないですか…ものすごい昔に既に踏み尽くされた地平なのですね。やる気出てきました。

2011-12-09 17:32:53

@kumagi @taroleo そうですね，2006年にJim Grayさんに伺った所では，group commitはDB界で極めて重要な発明の1つ，とのことでした．でも要するにI/O最小化です．最新研究はこちらがお勧めです．http://t.co/b5WUmEEo

2011-12-09 17:36:40

@h_kaw @kumagi @taroleo 最近はSSDやPCMなども出て参りましたので，プロトコルが若干変わる可能性もあるのではないかと思います．ただし，当方，この分野は素人ですので，@taroleo先生に補足・修正して頂けたら幸いです！

2011-12-09 17:38:13

「A=BならA-=100」はwL(A)rL(B)で「A=BならB-=100」はrL(A)w(B)なのでそもそもロックの作法の上では同時実行されうる心配が無いんだけれど、時刻印方式の一貫性制御だとその辺ゆるくなっちゃうのねぃ。

2011-12-09 17:39:48