A critique of ansi sql isolation levels 解説公開用

A Critique of ANSI SQL Isolation Levels
再読

〜もう一度TX処理の基礎を見直す

2012//
株式会社ノーチラス・テクノロジーズ
@okachimachiorz
http://www.nautilus-technologies.com/
mailto:contact@nautilus-technologies.com
Tel: 03-6712-0636 Fax: 03-6712-0664
Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS Proprietary & Confidential

A Critique of ANSI SQL Isolation Levels
 1995年の論文
– Phil Bernstein, Jim Grayらの共同執筆
– 「ANSI 92のIsolation levelが適切ではない」という内容
– ftp://ftp.research.microsoft.com/pub/tr/tr-95-51.pdf

 位置付け
– 全「TX処理を生業にする」人間が読むべき論文。
– 今までのTXのIsolationの整理になっている。

– Snapshot Isolation (SI) が初めて大々的に登場した。
– 以降、DBの実装の主流のひとつになっていまも続いている。

– 何のかんので引用数はかなりある。
– 知らないと話にならない。

NAUTILUS Proprietary & Confidential 1

Motivation 1
 なぜ今更TX処理とかいうのか？

– 「もう枯れてんじゃないのか？」

– 割とある程度枯れてはいますね。ただし、全ての問題が解決しているか
？というと、そうでもないようです。

– HadoopやNoSQLで分散環境が普通に導入されつつあります。が、
NoSQLは基本的にはTXはサポートしていません。・・・って、そもそ
もTXなんだっけ？という話に戻ることが多いわけです。

– 「TX処理でのconsistency」って、ちゃんと説明できないとまずい。
 分散処理のconsistencyとは違いますが、とはいえ・・・


Motivation 2
 Welcome Back to RDBMSの流れ

– 2010年前後に一斉にRDBMSの特許が切れ始める。
 まずはINDEX系

– 大規模分散は、ある程度道ができた。んじゃ残りは？
 Hadoopが予想外に普及〜「大規模な単純な数え上げ」なら最強

– 今、一斉に「RDBMSに逆張り」を始めている
 OSS?
 中規模〜小規模データの処理

– 基本は「ACIDで可能であれば分散させたい」
 いままで屍累々の道を再び。
 大規模じゃなくて、中規模ならどうよ？
– そもそも分散TXって・・・


TX処理
 基本的にACID属性
– Atomic
 すべてのTXは処理は終わるか、さもなければ失敗する
 TXの最後の操作はcommitかまたはabort
– Consistency
 すべてのTX処理は整合性をもつ
 不変述語（invariant predicate)が充足されること
– TXの最中は一時的な不変述語が偽になるので、TXの最後に一貫性が保たれるよう
にする。
 ま、人によっていうことが違うが、ある程度の合意はできている。
 「correctである」ということ
– Isolated
 あるTXの処理は、別のTXの処理の影響を受けない
– Durable
 すべてのTX処理の結果は永続化する
本日の話題
– 最大の問題は、ConsistencyとIsolation
 特にIsolationがConsistencyに深く絡むので問題

そんじゃ行ってみよう！
 まず注意書き

 基本的に論文の紹介なので、かなりいろいろ端折っています。

 いちいち全部訳していると全訳になるので、それは勘弁してくださ
い。
– 全訳するとそれはそれでかなり意味不明になる気もするので、各自読ん
で確認してください

 割と細かい部分で微妙な言い回しをしているところがあって、その
辺はサクッと無視しています。TX業界の当時のコンテクストを偲ば
せるところもあるのですが、それは各自勝手に味わってください。

– たとえば箱崎方面のDBとか(ry
– たとえば赤い会社のDBとか(ry


そんじゃ行ってみますよ！

 Abstract

 「ANSI ではIsolation レベルの定義をphenomenaという言い方で定義
している。すなわち、Dirty read, Non-repeatable read, と Phantomであ
る。」

 「ただ、この定義では、標準的なロック実装を含めたIsolationレベ
ルの設定には適切ではない。なので、この曖昧さを明確にし、
Snapshot Isolationを提案することで、よりましなIsolationレベルとい
うものを定義しようじゃまいか。」

 という内容だ。


1 Introduction
 いきなり名文っぽいので、そのまま引用する。

 「Running concurrent transactions at different isolation levels allows application
designers to trade throughput for correctness. Lower isolation levels increase transaction
concurrency but risk showing transactions a fuzzy or incorrect database.」
– 下線は私めの強調

 ここで注目すべきは、concurrentとcorrectという表現がほぼ2回もそれぞれ出てい
ること。

 なんか、無条件でcorrectって言葉が使われていて、違和感があるのが普通です。

 この言葉だけ相当議論があるので、その業界（TX業界）で言われているcorrect
という意味でいいでしょう。

– 自分では「serializeした場合と同じsemanticsになる」意味だと解釈しています。

 引き続き、「それからIsolationがしっかりしていないとアプリサイドでいち
い注意を払う必要が出てきてしまう」という趣旨のことを述べてます。


（解説）「Correctとはどういう意味か？」
 全部のTxが意図した通りになっていればいんじゃね？
– 意図した通り？
– なにその主観的判断わ。

 なので、Semanticsを決定して、correctnessの真偽値の判別関数を用
意して、その値が真になる集合を定義する。この集合に入れば、
correctと言える。

 そもそも「意図した通りにならない」とはどういう状況よ？
– TXさせないぞ三兄弟（世界共通）
 Lost update
 Dirty read
 Inconsistent Read (Non-repeatable, Phantom)


引き続き論文を
 「まず、ANSIの定義ですが・・・Isolationの定義は以下

– 1 READ UNCOMMITTED
– 2 READ COMMITTED
– 3 REPEATABLE READ
– 4 SERIALABLE

– になっています。」

 「んでそれぞれのレベルはそれぞれの問題となるphenomenaを防止
することになりますよ、とそういう定義ですね。すなわち・・」


「1 READ UNCOMMITTED -> Dirty read
2 READ COMMITTED -> Non-repeatable read
3 REPEATABLE READ -> Phantom
4 SERIALABLE」

 一応、この論文では「phenomenaという表現ではなく、anomalyとい
う表現を使う」と言っています。違いはまぁあるにはありますが、
「それほど重大では（理解する上では）ありませんよ」と。

 anomaly、というのは正確な日本語がないのですが、変則状態とかそ
んな訳語が当てられることが多いようです。


 「ANSIの定義は、そもそも2PL等のロック・スケジューラーに関連
づけられていて、この起こりはロッキング・データフローグラフ・
anomalyという形で定義されたDegree of Consistencyというのが、そ
れにあたります。Phenomena(anomalies)でのIsolationの定義は、SQL
標準でのノン・ロックベースでの実装を許容を意図したものだった
のでござる」
– 「ロックベースでの実装がIsolationレベルの基本になっていたので、そ
れ以外の道を模索するべくANSIは意図していた」ということにようで
す。ま、実際、実装はロックベースがほとんどでしょうから、そういう
意味ではANSIの意図自体を否定しているようではないですね。とはい
え・・・

 んで、「このANSIの定義は、曖昧で、しかもどう広く解釈しても
anomalyを排除できず、lockベースのIsolationと異なった結果になる
上に、現在の商用のシステムに役に立ちませんね。」というさんざ
んのいいようにつながります。


（解説）基本戦略
 Isolationレベルは基本は「どう妥協するか？」という戦術。
– 基本はserializableにもっていく
– ただし、concurrencyが下がるので妥協していく。

 「世の中一般にはserializableは遅いので使うな」という言い方がさ
れることがあるが、DB屋的にはこれは普通に屈辱（のはず。）

– lockレスで、そのまま放り込めば、concurrentなままserializableなスケジ
ュールを組みあげるというのが、最適な実装。
 アプリでの明示ロックは本来はうれしくない。もったまま死なれるとabortが
でて、最悪はabortのcascadingが起きて・・・・

– とはいえ、できない・・・ので、どうやってIsolationレベルを緩めるか
ということを考える。


とりあえず論文の展開は・・・
 以下、各章のサマリーが記述されます。
 「2章では、基本的な用語を整理してANSIとロックによるIsolationを定
義します。」

 「その上で3章でASNIを見直した上で、いくつか新しいphenomenaを提
示します。その上で一般的なIsolationレベルを定義して、そういった定
義をANSIとdegrees of consistencyの間にマッピングしますよ。」

 「4章では、MVCCである、Snapshot Isolationを導入します。これにより
、ANSIのいうphenomenaはserializeすることなく、全部排除できます。
Isolationレベルとしては、Read committed とRepeatable readの間に位置し
ます。」

 「5章では、3-4章のIsolationとは異なるanomalyを調べた上で、ANSIの
phenomenaを拡張しても、Snapshot isolationとCursor Stabilityには適用す
ることができませんよ、」という内容。

 「6章がサマリーと結論ですね。」

2. Isolation Definition
 非常に簡潔かつ明快なTXとhistory、およびconflictの定義
A transaction groups a set of actions that transform the database from one
consistent state to another. A history models the interleaved execution of a
set of transactions as a linear ordering of their actions, such as Reads and
Writes (i.e., inserts, updates, and deletes) of specific data items.

 Two actions in a history are said to conflict if they are performed by distinct
transactions on the same data item and at least one of is a Write action.

 さらに「各TXの各Stepのconflictから、グラフが形成され、このグラ
フが同じであれば、それぞれはequivalentであると見なせる。また特
に、そのうちserial historyとequivalentであれば、それをserializableと
言いますよ。」と続きます。

 ここでは自明すぎるでの書いていないのですが、これがcorrectの定
義になります。

（解説）再び～「Correctとはどういう意味か？」
 全部のTxが意図した通りになっていればよい？
– 意図した通り？

 Semanticsを決定して、correctnessの真偽値の判別関数を用意して、その
値が真になる集合を定義する。この集合に入れば、correctと言える。

 「最低でも一つは真である」ということが保証される必要がある
– ＋「判断可能である」
– ＋「十分に広い集合である」
– ・・・という条件がいる。

 最低でも一つは真であるとはどういう状態か？
– 「それぞれTXを単独で実行して得られるsemanticを真とする」ということ

 Serializeの定義 T1T2T3.....Tn
 「各TXを順番に実行する。」このとき得られる解釈を真とする
 解釈？意味分かんないんだけど？値とか？


（解説） TX処理の目標
 完全にSerializeされた各TX処理の実行結果から得られる「解釈」は
正しい（と設定する）
– ただしconcurrencyは、ほぼ存在しない
 この場合は各TXの内容を順番に実行するだけである。

 concurrencyが有った方が効率がよい（という前提）において、各TX
を構成操作(operation)に分解して、それぞれの操作をまぜて(shuffle)
実行すると、concurrencyが上がっていく（はず）。
– すなわち、serializeなスケジュール（TXの順序実行）を緩めていって、
concurrencyを上げていくことが目標になる。

 同時に処理されるTXのすべてのoperationを、一定のルールに基づい
て（各TX内部での順序は保証した上で）並べかえて、正しい解釈を
取得することが可能であるとすると、もっとも制限の緩いルールは
何か？


（解説） TX処理の目標
 そもそもserializeと同じ解釈になる、とはどういうことかを決めない
といけないですよね。
– 最後の値が同じならいいのか？
– データの連携のコンテストが同じならいいのか？
– （途中も含めた）更新処理の結果が同じならいいのか？

 合ってるかどうかが判断可能でないと無意味ですね。

 判断が実効時間内で計算することが可能でないと無意味だわね。

 判別関数が（割と）平易に実装できないと無意味じゃね？

 おお、あんたこれはまたハードル、ガン上げじゃね？


Serializeしたものと同じ「意味」ってなんですか？
 データの読み/書きについて

 「データのつながりのセマンティクス」が同じ
– Final State Serializability (FSR)
– View Serializability (VSR)

 「データアクセスの競合のセマンティクス」が同じ
– Conflict Serializability (CSR)・・・・・・これが論文の定義
– Two actions in a history are said to conflict if they are performed by distinct
transactions on the same data item and at least one of is a Write action.

 ふつうは、後者のCSRで、ごり押しすることが多い
– ただし、CSRがもっとも集合としては小さい
– まずは、データのつながりから見ていく


(解説)Serializeしたものと同じ「意味」ってなんですか？
 TXの文法から
T　 p1.... pm 　PはトランザクションＴの各ステップを表す
n

pi rn x 　ページ xからリード
pj wn x 　ページ xに書き込み

 エルブラン構造の導入
– 準備
ri x 　　ri x 以前に書かれた最後の jを読む　i
w j
wi x 　　wi x 以前に読まれた、同じトランザクションの属するriに依存する

– r/wのエルブラン・セマンティクスを再帰的に以下のように定義する
H s ri x : H s w j x 　i j　　w jはri以前のxに対する最後のw

H s wi x : f ix H s ri y1 ,..... s ri ym
H 　
　　ri y j 　 j
　
,1 mはトランザクションiに属するwi x 以前のすべてのリード
t


(解説) Serializeしたものと同じ「意味」ってなんですか？
 んで、エルブラン領域を設定
– エルブラン領域を HUとする
– まずデータセットの定義
D x, y, z ,....

– トランザクションの定義 ti 　i 0

– 定数記号
f0 x HU

– 関数記号
f ix v1 ,...,vm HU　
ただしv1...vm HU　
wi x はtiに属して、i y |
r y D ri ti wi x mである


 準備完了！
– スケジュール s のセマンティクスを定義できる
H s :D HU

– すなわち H s x : H wi x

 「データのつながりのセマンティクス」が同じ
– Final State Serializability (FSR)
– View Serializability (VSR)

– 以上はこのエルブラン・セマンティクスで表現可能


Final State Serializability (FSR)
 定義
– あるhistoryがserialである。
– そのhistoryとfinal stateが同等（final state equivalence)であるhistoryはFSR
である。

 final state equivalence
– 構成されているoperationが同一である。
– historyの最後（final ）の各ページの状態（state）に至るまでの再帰的な
エルブラン関数の構成が同じである。

– ということ。


View Serializability (VSR)
 定義
– あるhistoryがserialである。
– そのhistoryとviewが同等（view equivalence)であるhistoryはVSRである。

 view equivalence
– 構成されているoperationが同一である。
– historyの最後（final ）の各ページの状態（state）に至るまでの再帰的な
エルブラン関数の構成が同じである。
– すべてのreadについてのエルブラン・セマンティクスが同一である。

 結果としてVSR⊂FSR


 「データアクセスの競合のセマンティクス」が同じ
– Conflict Serializability (CSR)

– 1.各TXの各Stepのconflictから、グラフが形成される。
– 2.このグラフが同じであれば、各TXはequivalentであると見なせる。
– 3.そのうちserial historyとequivalentであれば、それをserializableと言う。
– 4. serializableであるスケジュールはcorrectである。

– Conflictの定義
 「同一データ（セット）」についての、別々のTXに属するオペレーションがあっ
て二つある場合で、そのどちらかがwriteである場合
 w-r / r-w / w-w

– Serializeされたスケジュールと同じConflictな関係がある場合に、そのスケジ
ュールをConflict Serializability（CSR)という
 r-r は別々のTXであっても順序を入れ替えても問題はない

 各serializabilityの関係
– CSR⊂VSR⊂FSR
 VSRのw-r・r-w・w-wの関係がCSRに含まれるから


ここで論文に戻ります
 Serializableの定義が終わった段階で、次にANSIでのIsolationの定義に
入っていきます。
 「ANSIでは以下の3っつのphenomenaでisolationを定義しています。」
– 以下簡略化するため、シーケンスでの記述をします。
– オリジナルは文言で記述
– P1 Dirty read
– w1(x) r2(x) w2(y)
 c1がアボートになるとまずい、というやつ。

– P2 Non-Repeatable or Fuzzy read
– r1(x)r2(x)w2(x)r1(x)
 同じr1(x)で値が異なっています。同一TX内部なのに・・、というやつ。

– P3 Phantom
– これはpredicateな条件があるので以下
– r1(P)r2(x,P)w2(x,P)r1(P)


ANSIの定義の曖昧性の指摘
 前述のP1-P3の定義が曖昧だという指摘。
– 「ANSIの定義ではcommit, abortの順序が明示されていない。したがって、明
らかにinconsistな状態になる、というよりもなる可能性がある(P: Phenomina)
という状態になってしまう。以降、可能性とあからさまにinconsistな状態(A:
Anomaly)と区別する。」

 P1 w1(x)r2(x) ((c1 OR a1) AND (c2 OR a2)) in any order
– これでcommitとabortがあるケースはすなわち
– w1(x)r2(x)a1c2 ..NG
– w1(x)r2(x)c1a2 .. OK→OKではまずい
– w1(x)r2(x)a2c1 .. OK →OKではまずい
– w1(x)r2(x)c2a1 .. NG
– 要するに4パターンあるわけだが、このうちNGなのは、二つしかない。つま
りANSIの言い方では曖昧な結果になる。

 A1 w1(x)r2(x)(a1 and c2 in any order) すなわち
– w1(x)r2(x) a1c2
– w1(x)r2(x) c2a1
– この場合は、明確に問題になる。

ANSIの定義の曖昧性の指摘
 P2 r1(x)w2(x) (c1 OR a1) AND (c2 OR a2)) in any order
– この場合も同じで
– r1(x)w2(x)c1a2 OK
– r1(x)w2(x)a1c2 NG
– r1(x)w2(x)c2a1 NG
– r1(x)w2(x)a2c1 OK
– で曖昧な解釈が可能になる。NGを定式化するには
 A2 r1(x)w2(x) c2 r(x) c1

 P3r1(P)w2(y in P) (c1 OR a1) AND (c2 OR a2)) in any order
 A3 r1(P)w2(y in P) c2 r1(P) c1
– 基本的にはP2と同じ構造になる。
– 「ANSIはinsertだけを禁じてますが、普通にwrite一般(insert, update,
delete)の方が良いでしょう。」尚、これらをまとめIDM (insert, delete,
modify)ということもありますね。


補足が続く
 「この論文ではMVの話が出てくるが、ANSIではsingle-versionを想定し
てます」

 「そのあとANSIでは、Isolationレベルを各phenomenaで単位で規定して
います。んで、最後のSerializableは、単純に「commonly known as fully
serializable execution」と言っています。」

 「するってーと誤解があって、要は三つのphenomenaをクリアすれば、
serializableですよね？ってことになります。この三つをクリアしたもの
便宜的に Anomaly Serializableといいますかね。」

 「んで、ANSIの解釈は広く解釈できるので、その分そもそも許容され
るhistoryが制限される（restrictive）上に、さらにもともと三つの
phenomenaをクリアしてもserializableにならないケースもございます。
」
– つまり、ない方がいいといっています。

 「P3を除いて、ANSIの定義をシンプルにして、ANSI4.28節の定義をそ
のままANSI Serializableといいましょう。」


んでまとめると・・・
 ANSI SQLIsolation Level Defined in terms of the Three Original
Phenomena (Table1)

Isolation level P1 P2 P3
Dirty Read Fuzzy Read Phantom
ANSI READ Possible Possible Possible
UNCOMMITTED
ANSI READ Not Possible Possible Possible
COMMITTED
ANSI Not Possible Not Possible Possible
REPEATBLE
READ
ANOMALY Not Possible Not Possible Not Possible
SERIALIZABLE


それでは次にどうするのか
 ANSIの定義では曖昧すぎるので、別のIsolationをもってくれば、も
う尐しまともになるかもしれない・・・一般によく使われている
LockベースのIsolationをもってきて比較してみる。

 以下、論文の展開
– 「大抵のSQL 製品はロック・ベースのIsolationを利用しているので、ま
ずはANSI SQL Isolationをロックの観点から対応させましょうか。（まぁ
無理があるんですがね）」

– 以下、lockのお話。

– 「ロックは基本的にRead(Shared)とWrite(Exclusive)で、異なるTXが同一
のデータまたはデータセットに対してロックをとろうとするとconflictに
なります。」


引き続きLockの話題
– 「predicate lockはある一定の条件にあうデータセットに対してロックを
かけるわけだが、これはSQLの言い方としては、phantomを”含む”。すな
わち、もしIDMされたのであれば、条件に合致した、であろう、現時点
ではDB上にないデータを含むということ。」

 簡単に言うと、TXの開始時点では存在しなかったけれども、その途中で別の
TXにより生成されてかつ条件にあるデータセット（すなわちphantom）も本
来はロックの対象になる、という意味ですね。
– 「できんのか？ｗ」って話しは別の話題かとｗ

 現実的には複雑なPredicateであれば、ほぼ非現実的になるので、一定の枠を
つくって、あの手この手でなんとかするというのが、ありがちなパターンで
すが、有効打はあまりないようです。

 predicateを含むTXではserializableなスケジュールは、そもそも困難です。形
式的にはconflictはページ単位で設定はできますが、predicateになった途端に
conflictグラフの形成がコスト的に難しいでしょう。


まだLockの話題

– 「んで、複数のTXがあれば、当然ロックは競合しますよ、」と

– 次にwell-formedの定義

– well-formed read (write)の定義が出てきますが・・そもそもこういったル
ールをなぜ設定しているかというとロックの取得とリリースのタイミン
グで、ロックのプロトコルが変わるため、全体としてまずロックのカテ
ゴリーを決めておくということだと思います。

– 論文とは別に、ここで厳密な定義を書いておきます。
 rule 1 oprerationの前には必ずロックをとる。ロックのリリースは必ずoperation
の後になる
 rule2 TX内部でのあるデータに対するロックは一回のみ（同じデータに対し
て、同一TX内部で複数回ロックはとらない）
 rule3 同様にリリースは一回のみ


さらにLockの話題
 つぎにlong duration lock と short duration lockの説明が来ます。
– long durationはTXがabortかcommitされるまでlock保持するもので、short
durationは対象データの操作が終わった直後にlockがリリースされるもの
ですね。

 次に2PLの定義らしきものを述べます。（論文での表現が微妙なの
で）

 論文：「あるTXがロックをとっていて、別のTXがconflictロックを
とりに行ったときは、前のTXのロックがリリースされるまで、ロッ
クがとれない」という表現です

 厳密には、「すべてのTXにおいて、その同一TXに含まれる、ある
操作のロックリリースのあとには、そのTX内ではロック取得のステ
ップは存在しない」ということになります。ほぼ同じ意味ですが。


基本の定理
 ここで、
– well-formed 2 PL locking guarantees serializability という定理が導入されて
います。

– そのまま書きます
 The fundamental serialization theorem is that well-formed two-phase locking
guarantees serializability — each history arising under two-phase locking is
equivalent to some serial history. Conversely, if a transaction is not well-formed or
two-phased then, except in degenerate cases, non-serializable execution histories are
possible

 以上

解説Nothing

つまり・・・

「 well-formed two-phase locking
guarantees serializability」

これぐらい知っておけと？

知らないやつとかあり得ないよね？
と？


(解説)なので、まじめに証明します。
 ロジックは簡単です。TX本引用します。
– 以下Tx i に属するオペレーションoのロックステップはoli リリースステ
ップはouiと表記
 DTはr,w,a,cの各要素をTXにProjectionしたもの (要はr/w/a/cのみ対象）
 CPはCommitted Projection（要はコミットされたTXのみ対象）

 LEMMA 1
– Let s be the output of a 2PL scheduler. Then for each transaction
ti∈commit(DT(s)) the following holds:
 (1) . If oi (x) ( o ∈{r, w}) occurs in CP(DT(s)), then so do oli (x) and oui (X) with the
sequencing oli (x) < oi (x) < oui (x) .
 (2) . If tj∈commit(DT(s)) , i ≠ j, is another transaction such that some steps pi (x) and
qj (x) from CP(DT(s)) are in conflict, then either pui (x) <qlj (x) or quj (x) < pli (x)
holds.
– If two steps are in conflict, then so are their lock operations; locks in conflict are not set
simultaneously.
 (3). If pi (x) and qi (y) are in CP(DT(s)), then pli (x) < qui (y) , i.e., every lock
operation occurs before every unlock operation of the same transaction .
– ここがみそでwell-formedが効いてきます。


(解説)引き続き
 LEMMA 2
– Let s be the output of a 2PL scheduler, and let G := G(CP(DT(s))) be the
conflict graph of CP(DT(s)) . Then the following holds:
 (1) . If (ti , tj) is an edge in G, then pui (x) < qlj (x) for some data item x and two
operations pi (x), qj (x) in conflict.
 (2). If (t1, t2, . . . , tn) is a path in G, n≧1 , then pui (x) < qln (y) for two data items x
and y as well as operations pi (x) und qn (y) .
 (3) . G is acyclic.→「順序はわからんが、とにかくTxを循環させずに一列に並
べることができる。（トポロジカルソート可能）→serializable」
 Proof
– (1) If (ti , tj ) is an edge in G, then CP(DT(s)) comprises two steps pi (x) and qj
(x) in conflict such that pi (x) < qj (x) .
– According to (1) in Lemma 1, this implies pli (x) < pi (x) < puj (x) and qlj (x) <
qj (x) < quj (x) .
– According to (2) in Lemma 1, we moreover find (a) puj (x) < qlj (x) or (b) quj (x)
< pli (x). Case (b) means qlj (x) < qj (x) < quj (x) < pli (x) <pi (x) < pui (x) and
hence qj (x) < pi (x), a contradiction to pi (x) < qj (x) .
– Thus, pui (x) < qlj (x) (which is case (a)), which had to be shown .

(解説)続き
 Proof続き
– (2) The proof goes by induction on n. The induction base n = 2 follows directly
from part (1): If (t1, t2) is an edge in G, there is a conflict between t1 and t2 Thus,
pul (x) < ql2 (x), i.e., t1 unlocks x before t2 locks x. In other words, when t2 sets a
lock, t1 has already released one.

– Now assume our claim holds for n transactions on a path through G, and
consider a path of length n + 1 . The inductive assumption now tells us that
there are data items x and z such that pu1 (x) < oln (z) in s.
– Since (tn, tn+1) is an edge in G, it follows from (1) above that for operations vn
(y) and qn+l (y) in conflict we have vun (y) < qln+l (y).
– According to (3) of Lemma 1 , this implies oln(z) < vun(y) and hence pul (x) <
qln+1(y)

– (3) Assume that G is cyclic. Then there exists a cycle, say, of the form (t1,t2, . . .
, tn, t1) n≧1. By (2), pu1(x) < ql1(y) for operations p1(x), q1(y), a contradiction to
the two-phase rule (or to (3) of Lemma 1).

– 以上でござる。

Degree of consistency
 Lockの内容を一通り外観したあとで、これをIsolation levelに関連づ
けることを行って行きます

 そのために、まず、degrees of
consistencyというコンセプトをロック
・依存関係・anomalyの特徴から四つに分類します。

 こいつはGrayの別の論文から引っ張ってきてます。んでその論文の
definition 1を見ろ、という内容ですが・・・それはこんな感じです
ね。


(解説) Definition 1
 Degree 3: Transaction T sees degree 3 consistency if:
– (a) T does not overwrite dirty data of other transactions.
– (b) T does not commit any writes until it completes all its writes (i.e. until the end of transaction
(EOT)).
– (c) T does not read dirty data from other transactions.
– (d) Other transactions do not dirty any data read by T before T completes.

– (b) T does not commit any writes before EOT.
– (c) T does not read dirty data of other transactions.

– (b) T does not commit any writes before EOT.


 まぁ非常にわかりづらいというか、これまた曖昧・・・
 Degreeという概念をとりあえずは導入しています。


LockingベースのIsolationの検討
 さらに、Isolationのレベルをロックスコープとr/wのモードとduration
（長さ）で分類しています。すなわち

 Locking READ UNCOMMITTED
 Locking READ COMMITTED
 Locking REPEATABLE READ
 Locking SERIALIZABLE

 「一応ANSIの定義に合わせますが、実際はかなり異なったものにな
っているので、Lockingという表現を入れて、区別しています。」


まとめると以下
 Degrees of
Consistency and Locking Isolation Level defined in terms of
Lock (Table2)
Consistency Level = Read Locks on Data Items and Predicate Write Locks on Data Items and
Locking Isolation Level Predicates
Degree 0 None required Well-formed Writes

Degree1 = None required Well-formed Writes
Locking READ Long duration Write locks
UNCOMMITTED
Degree 2= Locking Well-formed Reads Well-formed Writes
READ COMMITTED Short duration Read locks Long duration Write locks
Cursor Stability Well-formed Reads Well-formed Writes
Read locks held on current of cursor Long duration Write locks
Short duration Read Predicate locks
Locking REPEATBLE Well-formed Reads Well-formed Writes
READ Long duration data-item Read locks Long duration Write locks
Short duration Read predicate locks
Degree 3 = Well-formed Reads Well-formed Writes
Locking SERIALIZABLE Long duration Read locks Long duration Write locks
(both)


Degreeレベルとの検討が続く・・・
 「さて、Degree0 はdirty read / writesが許容されます。単純にアトミックであればよい
」

 「Degree 1-3は順に、Locking READ UNCOMMITTED Locking READ COMMITTED
Locking SERIALIZABLEに相当します。Locking REPEATABLE READに相当するもの
はないですね・・」

 「もともとの最初のオリジナルの定義では、Date・IBMの論文では、Repeatable Read
はserializableか、Locking SERIALIZABLEを意味していました。これはしかし、
Degree3になります。ANSIのいうRepeatable Readは、オリジナルの定義から異なるわ
けです・・・」

 「ANSIの定義のRepeatable Readでは、P3（phantom）を排除できないわけで・・・厳
密にいうと”REPEATABLE”ではないですよね。」
– 要はもともとの意味でのRepeatable Readはserializableであり、したがってPhantomは排除して
おり、したがってちゃんとRepeatable Readになっていたはずだった、というわけです。

 「ANSIと比較する必要があるので、間違っているとはわかっていますが、 Locking
REPEATABLE READ という形で使わせて頂いておりますが（キリッ」

 「あと似たような話で、DateはCursor Stabilityという用語を導入して、Degree2の
isolationを、lost cursor updateを拡張してますが、これは後述します。」


(解説)閑話休題
 という感じで、これでもか、というぐらいANSIのdisりが続きます・
・・

 「Repeatable read」という言葉
– 論文の記述にあるとおり、基本的にANSIの用語はきわめて不適切。
– また、現在の使われ方もかなり間違っていることが多いです。

– 「定義として“同一TX内部で同じ値を読んだ時に同じ値が取得できる”と
いうことではない」です。
 結果がそうなるのであって、定義ではなく効果。
 そもそもPhantomは絶対に除去できない。
 同一対象についての別々のTXでのr-wの関係があった時にphantomが除去でき
ない程度にそれぞれのTXがIsolateされる、ということ。


Isolationレベルの比較のコンセプトの導入
 まず、定義です。
– Isolation levelの「weakness」です。
– あんまり大したことは言ってないのですが、これ以降の論文では大抵は
無条件でweakという用語を使ってきますが、これはその元の定義になっ
ていると思います。

 定義的には、non-serializable historyがより広く（一つでも多く）含
まれる方が weakです。完全に一致する場合は同値になります。

 前提として、Locking SERIALIZABLEがすべてのserializableの集合と
同値ではないことはわかっていますが、便宜的に同値とします。

 weaknessでならべると
– Locking READ UNCOMMITTED << Locking READ COMMITTED <<
Locking REPEATABLE READ << Locking SERIALIZABLE

 以上で準備完了


3 Analyzing ANSI SQL Isolation Level
 順番に分析結果が列挙されます。
 (Remarks2)「Table2のロック・プロトコルはTable1のphenomenaベース
のisolationと最低でも同程度にstrongなlocking isolation levelを定義して
いる。」
– これはスタートポイント

 もっとIsolateされているのか？というのが問題で、結果でいうとYes。
– 一番低いレベルすなわちLocking READ_UNCOMMITTEDで見ると、
DirtyWriteを排除してます。これはANSI SERILAZABLEでやっと排除できる
anomaly

– P0（DirtyWrite)について
 w1[x] w2[x] (c1 or a1) and (c2 or a2) in any order
 これはたとえば、x=yという制限がある場合にw1(x=1)w2(x=2)w2(y=2)c2w1(y=1)c1
となると、不整合が起きる。
 それからw1[x]w2[1]a1の場合に問題が発生します。w0[x]を仮定して（before-image)
、w1[x]のundoがw0[x]をもってくる形だとw2[x]を消し去ることになります。また
とはいえ、それができないとa2が発生したときにもとに戻れない。
「ANSIの規約は、全部のisolationレベルでP0を排除でき
 (Remarks3)
るように修正しないといけない。」

Analyzing ANSI SQL Isolation Level
 前述のphenomenaの広い解釈が必要になるケースがある。
– 既出のA1-A3で確認してみる。
 A1 w1(x)r2(x)(a1 and c2 in either order) ~ Dirty read
 A2 r1(x)w2(x) c2 r1(x) c1 ~ Non repeatable read
 A3 r1(P)w2(y in P) c2 r1(P) c1 ~Phantom

– H1: r1[x=50]w1[x=10] r2[x=10]r2[y=50]c2 r1[y=50]w1[y=90]c1
 これはx=50から40を引いて、yに40を加えるTX1の最中に、別のTX2がx,yの両
方を値を調べるという例。
 TX1がコミットされていないので、当然inconsistentな結果（分析）になる。
 問題はこのAnomalyがA1-A3で検出されないということ。
– A1のようにabortはない、A2のように二回読むということもない、A3のように
predicateがあるわけではない。

 ただし、ここでP1の広い解釈をとると検出できる。
– P1 w1(x)r2(x) ((c1 OR a1) AND (c2 OR a2)) in any order
– むしろA1よりもANSIの広い解釈の方が正しい。

 次に似たような議論として、P2の広い解釈の方がA2よりも適切であ
るケース
– H2: r1(x=50) r2(x=50)w2(x=10)r2(y=50)w2(y=90)c2 r1(y=90)c1
– これはxから40を引いて、yに40を加えるTX2が、x,yの両者を読むTX1の
間にはいったため、TX1で不整合が起きているケース

– DirtyReadではなく、P1では検出できない。しかも同じデータを2度読ん
でいるわけでないし、predicateがあるわけではない。もう一度読みなお
せば値は変わるのだが、そうしているわけではなく、A2が適用できない
。よって、P2の広い解釈でA2を置きなおすことにより解決する。

– P2 r1(x)w2(x) (c1 OR a1) AND (c2 OR a2)) in any order
– r1(x=50) 、w2(x=10)の時点で検出される。


 最後にA3とP3について
– H3: r1(P) w2(insert y to P)r2(z)w2(z)c2 r1(z)c1
– たとえば、有効な従業員のリストをとって、その数をカウントするような場
合。TX1で有効な従業員のリストを取得、そのあとでTX2が新規の従業員を
追加してカウントを更新し、そののちTX1でカウント数を取得する場合、不
整合が発生する。

– H3はserializableではない。またpredicateの評価を二度おこっているわけでは
ないのでA3でひっかかることもない。これもP3の広い解釈で処理する。

 P3 r1(P)w2(y in P) (c1 OR a1) AND (c2 OR a2)) in any order
– ひっかかりますね・・・これはANSIの意図したとおりでしょう。

 (Remarks4)厳密な解釈のA1-A3は意図せざるweaknessが発生する。なの
で、広い解釈を行うことで正しい処理をすることができる。これがも
ともとANSIのP1-P3が意図したもの。
– ANSIをdisりつつも、そもそもの意図は悪くなかったｗと一応持ち上げるJim
Gray先生の面目躍如


 (Remarks5)ANSIの定義は完全ではない。かなりのanomalyが残る。
新しいphenomenaがロックの定義を完全にするために定義されなけ
ればならない。またP3は書き換えるべき。2TX目のc2,a2を除いた
historyを限定しない形での定義は以下になる。

– P0 w1(x)w2(x) (c1 OR a1) Dirty Write
– P1 w1(x)r2(x) (c1 OR a1) Dirty Read
– P2 r1(x)w2(x) (c1 OR a1) Fuzzy or Non-repeatable Read
– P3 r1(P)w2(y in P) (c1 OR a1) Phantom

– 追記としてはP3のw2(y in P)のPは、ANSIはinsertのみだが、別段insert,
update, deleteでも問題はない。以上のisolationレベルはtable3にまとめて
ある。


 ANSI SQL Isolation Level Defined in terms of four Phenomena (Table3)

Isolation level P0 P1 P2 P3
Dirty Write Dirty Read Fuzzy Read Phantom
READ Not Possible Possible Possible Possible
UNCOMMITTED
READ Not Possible Not Possible Possible Possible
COMMITTED
REPEATBLE Not Possible Not Possible Not Possible Possible
READ
SERIALIZABLE Not Possible Not Possible Not Possible Not Possible


 Table2とTable3が同値であることの解説
– 単一バージョンのケース（マルチバージョンを想定しない）では、それぞれ
のP0-P3のphenomenaはロックを隠ぺいしているものに過ぎない

– たとえば、P0では、実際のところ、w1の書き込みが終了したあとでの、w2
の書き込みを排除してるわけで、これはLong-termのWriteロックをとってい
るのと同じことになる。predicateでも同じで、すべてのisolationレベルで
Dirty Readを制限することになる。

– 同じことはP1でも言えて、これはWell-formed read を強制することになる。
つまり、r2のロックを必ずとるということと同じになる。P2の排除はデータ
に対するlong-termのreadロックを意味する。最後にP3はlong-termのpredicate
のreadロックをとることになる。

 よってTable3は、Table2のロックベースのIsolationと同じになる。

– ・・・よって、考え方としては、ロックベースで実装してしまえば、実際は
isolationを保障することの同じになる、という考え方（たぶんこの論文の考
え方）と、ロックを実装しなくてもanomalyを排除できれば、実際はロック
と同じことが実現できるということ考え方がある、ということになる。

 (Remarks6) Table2とTable3は同値。実際はlockの再定義に過ぎない。

（解説）議論・・・
 Lock万能主義的な発想について
– 割と多い
– S2PL⊂CSRが数学的に証明済み
 したがってserializable
– 割と安全の処理することが可能
 ただし、実装は実際はかなりハードルが高い

– 尐なくともミドルの外部からロックを制御させるという方式は得策では
ない
– 理論的にはミドル内部では実装した方がかなりセキュアに作り上げるこ
とが可能
– ただし、理論的にはwaitが発生するだけパフォーマンスは落ちる
 わりとバリバリに落ちる
 ロックが不要な部分では利用すべきではない
 たとえば、Anomalyを排除できるのであればロックは実質的には不要


4 Other Isolation Type
 次にたいていの商用DBのisolationの実装は、READ COMMITTEDと
REPEATABLE READの間になることが多い。ので、anomalyを追加
する。
– Isolationの定義は「何ができる」ということではなく、このAnomalyを保
持できない、という定義であることに注意

 4.1 Cursor Stability
– Lost updateのphenomenonの排除が目的。
– P4 Lost Update
 P4 r1(x) w2(x) w1(x) c1
– 当然CSRではなくserializableではない。
 例で行くと
– H4: r1[x=100] r2[x=100] w2[x=120] c2 w1[x=130] c1
– READ COMMITTEDのレベルでは起こりうる。
– c2のコミットがw1の前に完了しているのでP0はパスされてしまう。P1はw→rの順で
のanomalyなので排除できない。
– P2では実は排除ができる。なぜかというと r→wの順で、最初のrの含まれるTXのコ
ミットの前に、wのTXがコミットになっているので。
– 要はrepeatable readの排除と同じになる。よってP4はREAD COMMITTEDと
REPEATABLE READの中間になる。

Cursor Stability
 Cursor Stabilityは READ
COMMITTEDを、SQLのカーソルでのロックの
振る舞いに対して拡張したもの。
– カーソルでフェッチしたreadからそのままロックをとる。そのままwriteロッ
クにコンバージョンをとって、カーソル自体で別のフェッチを行うこともで
きる。

 P4C rc1(x)w2(x) w1(x) c1は避けられる（rc1はカーソルでのリード）

Cursor Stability << Repeatable Read た
 (Remarks7) ReadCommitted <<
だしP4でありながら、Cursor Stabilityで排除できないものもある。


4.2 Snapshot Isolation（SI）
 いわゆるMultiVersionのConcurrencyControlの手法で、書き込みは常
に新しいversionを形成して、読みこみは適切なversionを選択すると
ういう方式。
– Snapshotの取得時刻＝Start-Timestampで、この時間はTXの最初のreadの
開始よりも前であればいつでもよい。
– Start-Timestampに生成されたsnapshot dataへのアクセスはブロックされな
い。
– writeはsnapshotに書き込まれ、同一TX内部で再読み込みの場合はその書
き込みから読まれる。
– Start-Timestamp以降の他のTXからの更新は読むことはできない。

– SIではcommitを行う場合は、Commit-Timestampを取得し、Start-
TimestampとCommit-Timestampの間に当該TXが書き込みを行うデータに
対して別のTXの書き込みcommitがない場合だけできる。それ以外は
abortになる。
 これは一般にFirst-committer-winと呼ばれてLostUpdateの排除になる。もちろ
んcommitが成功した場合は、その結果は他のTXから見ることは可能になる。


P1でのSIの例
 H1: r1[x=50]w1[x=10] r2[x=10]r2[y=50]c2 r1[y=50]w1[y=90]c1
 H1.S1 r1(x0=50) w1(x1=10) r2(x0=50) r2(y0=50) c2 r1(y0=50)
w1(y1=90) c1
– んでSerializableです。SIのデータフローの依存関係を維持したまま単一
versionのhistoryにマップすることは可能。この場合View-Equivalenceにな
る。
– たとえば、H1.S1のケースだと
– H1.S1.SV r1[x=50]r1[y=50] r2[x=50] r2[y=50]c2 w1[x=50]w1[y=90]c1
 H1.S1 とH1.S1.SVのRead From relationはそれぞれ同じで・・
– [t0-x0-t1] [t0-x0-t2] [t1-x1-tM] [t0-y0-t2] [t0-y0-t1] [t1-y1-tM]
– 完全に一致します。よってView-Equivalent

 んで、このView-Equivalentが可能なので、SV(Single version)にマッ
ピングができるので、はじめてIsolationの分類に加えることができ
ます。


SIとConstraint violation
 Snapshot
Isolationはserializableではない。というのは、ある対象をreadし
て、別の対象にwriteという感じなることがあるので・・

– H5: r1[x=50]r1[y=50]r2[x=50]r2[y=50] w1[y=-40]w2[x=-40]c1 c2
– これは無理。TXが交差するので・・・SIでは起きうる（というのはTXで読
み込めるversionは選択できないので）

 ここで、TXがそれぞれx, yの値を書き込んでx+yが正であることが制約
になっているとする。

 さらに、具合が悪い事にそれぞれのTXが適切にisolateされるとする。・
・・するとH5のように制約が保持でない。これにより、 Constraint
violationが発生する。

 Constraint violation は一般的かつ重要なconcurrency anomalyの一つ。
– DBは複数のデータにわたる制約を満たしています。
– 例えば、キーの一意性・参照整合性・二つの行でのリプレケーション・・
– これらをまとめて invariant constraint predicate と言います。
– TXの開始時点にconstraintを満たしているのであれば、commit時にも満たし
ている必要があります。


Data Item Constraint Violation
 二つ（複数）のデータ・アイテムの制約で起きるanomaly

 A5A Read Skew
– r1[x] w2[x]w2[y]c2 r1[y] c1 or a1
– TX1でskewが発生するanomaly

 A5B Write Skew
– r1[x]r2[y]w1[y]w2[x] c1 or a1

 P2(r-w)が排除されたもの中（P2の内部）では起きない。よって・・

 REPEATABLE READより低い（弱い）カテゴリーで有効な議論

 ANSI 厳密な解釈では行制約(Row Constraint Violation)は引っかかるが一般的なものは
無理。

 Table2（lock）では行制約は守れる。Table1では(A1/A2はとめるけど）行制約は守れ
ない。

 一方ここで、Snapshot Isolationを考えると、実は・・・・

 REMARK8 READ COMMITTED << Snapshot Isolation


READ COMMITTED << Snapshot Isolationの証明
 SI
– first-committer-win P0の排除
– time-stampによりP1を排除
– よってREAD COMMITTED ≦ SI

 さらに
– A5AはREAD COMMITTEDでも発生する。が、SIで排除可能。r(y1)がタ
イムスタンプで引っかかる

 よってREAD COMMITTED << Snapshot Isolation


REPEATBLE READ と Snapshot Isolationの関係
 まず
– A2はSIでは発生しない（Snapshotは同じデータを読むので）
 A2 r1(x)w2(x) c2 r(x) c1
– しかし、SIではWrite Skewが発生する。
 A5B Write Skew r1[x]r2[y]w1[y]w2[x] c1 or a1
– しかし、P2の防止はA5Bを発生させない。
– よって、SIはRepeatable Readでは発生しないanomalyが発生する。

 一方
– SIではA3が発生しない。SnapShotとっているから！
 A3 r1(P)w2(y in P) c2 r1(P) c1
– でもRepetableReadではそうではないので Anomalyが発生する。

 REMARK 9 REPEATABLE READ >< SI

 現実の実装ではRepeatable
Readの代替としてSnapshot Isolationを利用す
ることが多いのだが、Isolationレベルは直交するということです。・・
・まーなんというか。

では（P3の意味での） phantomは？
 しかし、SIではP3は除去できない。
– 違うデータのinsertはFirst-committer-winでは除去できない。
 たとえば「合計値だけ」でSIをpredicateでとっても、合計値に影響するデー
タがinsertされれば・・・・ダメじゃん・・・

 ただし、A3の定義ではphantomは発生しない。すなわち

 REMARK 10 SI はA1-A3を排除できる。
– ANOMALY SERIALIZABLE << SI

 SIはA3の意味でのphantomは除去できる。したがって、ANSIの
serializableよりも、もっとIsolationレベルが高い。
– そもそもANSIのserializableがアレだという話も当然ある。


そひて、SI万歳な記述ですよ。
 SI
– Snapshot Isolation gives the freedom to run transactions with very old
timestamps, thereby allowing them to do time travel….
 ボールド強調は元論文のママ

– ・ブロックなしで処理ができる。（ただし、非常に古いtimeStampの場合は
abortされる可能性が高い）

– ・実装が比較的簡単。activeなTXのStart-Timestamp以降にcommitする全部の
TXの更新処理を記録しておく。

– ・基本的に楽観処理。リードが多いことが前提。更新がちょっと議論の余地
あり。長い処理での更新処理は、特に短いTXとの競合にちょっとまずい。
 ロングバッチ処理の更新TXが全部abortされるということがなくはないｗ
 この辺は利他ロック使うとかいろいろ手はあると思う。
– http://dl.acm.org/citation.cfm?id=174638.174639

 まー、いろいろ議論はありますが、MVCC最強伝説の流れという風につ
ながっているのは間違いないですね。

4.3 Other Multi-Version System
 そのほかのMVな仕組みについて
– リードオンリーにする方式。
– 更新は可能だが、first-committer-winを実装しない方式。

 Oracle Read Consistency
– MVCC
 TX開始時点で最新のcommitされた値を取得
– first-committer-winではなく、first-write-win
 Writeロックによる
– READ COMMITTED << Oracle Read Consistency
– P4C(Cursor lost update)はキャッチできる
– しかし、P3(Repeatable read), P4(Lost update), A5A(Read skew)はミスする
 SIはP4とA5Aはキャッチする

 あとはおまけですが、SQL標準はよく見ると実はそれぞれのTXのス
テートメントレベルでatomicにしている
– この辺は本来はちょっとややこしくなる。同じTX内部での複数のsubTX
があった場合の利用するversionは？という問題

Summary
 Isolationの関係図
Serializable == Degree3 == {Date, DB2}Repeatable Read
A5B
P3
A5B
Repeatable Read Snapshot Isolation
P2 A3
P2
Oracle Consistent Read
Cursor Stability
A3, A5A, P4
P4C
P4C

Read Committed == Degree 2

P1

Read Uncommitted == Degree 1

P0

Degree 0


 Isolation Types Characterized by Possible Anomalies Allowed (Table 4)
Isolation Level P0 P1 P4C P4 P2 P3 A5A A5B
Dirty Dirty Cursor Lost Fuzzy Phantom Read Write
Write Read Lost Update Read Skew Skew
Update
READ Not Possible Possible Possible Possible Possible Possible Possible
UNCOMMITTED Possible
== Degree 1
READ COMMITTED Not Not Possible Possible Possible Possible Possible Possible
==Degree 2 Possible Possible
Cursor Stability Not Not Not Sometimes Sometimes Possible Possible Sometimes
Possible Possible Possible Possible Possible Possible

REPEATBLE READ Not Not Not Not Not Possible Not Not
Possible Possible Possible Possible Possible Possible Possible
Snapshot Not Not Not Not Not Sometimes Not Possible
Possible Possible Possible Possible Possible Possible Possible

ANSI SQL Not Not Not Not Not Not Not Not
SERIALIZABLE Possible Possible Possible Possible Possible Possible Possible Possible
==Degree 3
=Repetable Read (Date,
IBM,Tandem..)

個人的なまとめ・・今後につながること
 correctの概念は非常に重要
– なんらかのsemanticsを準備する必要がある
– データのcorrectnessについては、consistencyとほぼ同義
– consistencyとisolationは表裏一体

 isolationを明確に確保するには、どのようなanomalyが発生するのか
を抑えておく必要がある。
– anomalyの発生はconflictを中心に発生する
– w-w
 Dirty Write
 Lost Update
 Write Skew
– w-r
 Dirty Read
– r-w
 Inconsistent Read (Fuzzy Read)
 Phantom (predicate)
 Read Skew


個人的なまとめ・・今後につながること
 特に”r-w”は非常に重要
– Snapshot Isolationは、すでに広く実装されてきているが非常に重要な手
段。
– Snapshot Isolationを応用するときには、そもそも何が問題だったのか？
ということを抑えておくことが大切。

 今後の主流になる分散・並列処理ではserializableは大切な概念
– 分散環境ではまた違った文脈にはなる
– とはいえ、基本はここから

 以上。


A critique of ansi sql isolation levels 解説公開用

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Recently uploaded

Recently uploaded (12)

A critique of ansi sql isolation levels 解説公開用