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

Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved.Proprietary & ConfidentialNAUTILUS

A Critique of ANSI SQL Isolation Levels 再読

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

2012//株式会社ノーチラス・テクノロジーズ

@okachimachiorzhttp://www.nautilus-technologies.com/

mailto:[email protected]: 03-6712-0636 Fax: 03-6712-0664

Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved.NAUTILUS 2Proprietary & 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 の実装の主流のひとつになっていまも続いている。

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


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 の定義

「各 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 の文法から

エルブラン構造の導入– 準備

– r/w のエルブラン・セマンティクスを再帰的に以下のように定義する

に書き込み　ページ

からリード　ページの各ステップを表すはトランザクションＴ　　

x

x

P....1

xwp

xrp

ppT

nj

ni

mn

に依存するするトランザクションの属以前に読まれた、同じ　　

　を読む以前に書かれた最後の　　

iii

jii

rxwxw

jiwxrxr

以前のすべてのリードに属するはトランザクション　　　　

　

に対する最後の以前のは　　　

xwtmjyr

yrHyrHfxwH

wxrwjixwHxrH

iiji

misisixis

ijjsis

1,

,.....:

:

1


( 解説 ) Serialize したものと同じ「意味」ってなんですか？んで、エルブラン領域を設定

– エルブラン領域を HU とする– まずデータセットの定義

– トランザクションの定義

– 定数記号

– 関数記号　

,....,, zyxD

0iti　

HUf x 0

であるに属して、は

　ただし　

mxwrDyyrtxw

HUvv

HUvvf

itiiii

m

mix

i

|

...

,...,

1

1


( 解説 ) Serialize したものと同じ「意味」ってなんですか？準備完了！

– スケジュール s のセマンティクスを定義できる

– すなわち

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

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

HUDsH :

xwHxsH i:


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⊂


( 解説 ) Serialize したものと同じ「意味」ってなんですか？「データアクセスの競合のセマンティクス」が同じ

– 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

P3 r1(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 SQL Isolation Level Defined in terms of the Three Original

Phenomena (Table1)

Isolation level P1 Dirty Read

P2 Fuzzy Read

P3 Phantom

ANSI READ UNCOMMITTED

Possible Possible Possible

ANSI READ COMMITTED

Not Possible Possible Possible

ANSI REPEATBLE READ

Not Possible Not Possible Possible

ANOMALY SERIALIZABLE

Not Possible Not Possible Not Possible


それでは次にどうするのか 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 ol∈ i (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 p∈ i (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 pu≧ i (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 (t 1,t2, . . . , tn, t1) n 1. By (2), pu≧ 1(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.

Degree 2: Transaction T sees degree 2 consistency if:– (a) T does not overwrite dirty data of other transactions.– (b) T does not commit any writes before EOT.– (c) T does not read dirty data of other transactions.

Degree 1: Transaction T sees degree 1 consistency if:– (a) T does not overwrite dirty data of other transactions.– (b) T does not commit any writes before EOT.

Degree 0: Transaction T sees degree 0 consistency if:– (a) T does not overwrite dirty data of other transactions.

まぁ非常にわかりづらいというか、これまた曖昧・・・ 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 = Locking Isolation Level

Read Locks on Data Items and Predicate Write Locks on Data Items and Predicates

Degree 0 None required Well-formed Writes

Degree1 =Locking READ UNCOMMITTED

None required Well-formed WritesLong duration Write locks

Degree 2= Locking READ COMMITTED

Well-formed ReadsShort duration Read locks

Well-formed WritesLong duration Write locks

Cursor Stability Well-formed ReadsRead locks held on current of cursorShort duration Read Predicate locks


Locking REPEATBLE READ

Well-formed ReadsLong duration data-item Read locksShort duration Read predicate locks


Degree 3 = Locking SERIALIZABLE

Well-formed ReadsLong duration Read 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 が発生したときにもとに戻れない。

(Remarks3)　「 ANSI の規約は、全部の isolation レベルで P0 を排除できるように修正しないといけない。」


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 P0Dirty Write

P1Dirty Read

P2Fuzzy Read

P3Phantom

READ UNCOMMITTED

Not Possible Possible Possible Possible

READ COMMITTED

Not Possible Not Possible Possible Possible

REPEATBLE READ

Not Possible Not Possible Not Possible Possible

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 はカーソルでのリード）

(Remarks7) ReadCommitted << Cursor Stability << Repeatable Read　ただし 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 最強伝説の流れという風につながっているのは間違いないですね。

http://dl.acm.org/citation.cfm?id=174638.174639


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

Repeatable Read Snapshot Isolation

Cursor Stability

Oracle Consistent Read

Read Committed == Degree 2

Read Uncommitted == Degree 1

Degree 0

A5B

A5B

A3

A3, A5A, P4

P3

P2

P4C

P1

P0

P2

P4C


Isolation Types Characterized by Possible Anomalies Allowed (Table 4)Isolation Level P0

Dirty Write

P1Dirty Read

P4CCursor Lost Update

P4Lost Update

P2Fuzzy Read

P3Phantom

A5ARead Skew

A5BWrite Skew

READ UNCOMMITTED== Degree 1

NotPossible

Possible Possible Possible Possible Possible Possible Possible

READ COMMITTED==Degree 2

NotPossible

NotPossible

Possible Possible Possible Possible Possible Possible

Cursor Stability NotPossible

NotPossible

NotPossible

Sometimes Possible

Sometimes Possible

Possible Possible Sometimes Possible

REPEATBLE READ NotPossible

NotPossible

NotPossible

NotPossible

NotPossible

Possible NotPossible

NotPossible

Snapshot NotPossible

NotPossible

NotPossible

NotPossible

NotPossible

Sometimes Possible

NotPossible

Possible

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

NotPossible

NotPossible

NotPossible

NotPossible

NotPossible

NotPossible

NotPossible

NotPossible


個人的なまとめ・・今後につながること 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 解説公開用

Technology