Transaction isolation level
Tanaka-Qtaro-Yasuhiro
最近、データベースのトランザクション処理について、いろいろ考え
る機会があったのですが、自分自身かなりあやふやにしか理解できて
ないことがわかり、勉強しなおしたいと思っています。
例えば、ある isolationレベルのトランザクションで、複数行を順繰り
に削除する処理と更新する処理が同時に走ったときに、テーブルにロッ
クをかける必要があるのかどうか」といった問題を、きちんと解ける
力をつけたいのです。
データベースのトランザクション隔離レベルについて、わかりやすく
説明された書籍やウェブページは無いでしょうか。
「低い隔離レベルだとこういう処理がうまくいかない」といった例が
豊富だと嬉しいです。
--
Tanaka-Qtaro-Yasuhiro mailto:ta...@ca2.so-net.ne.jp
Shinji KONO
In article <bq10bl$1j9$1...@news-wst.ocn.ad.jp>, Tanaka-Qtaro-Yasuhiro <ta...@ca2.so-net.ne.jp> writes
> 最近、データベースのトランザクション処理について、いろいろ考え
> る機会があったのですが、自分自身かなりあやふやにしか理解できて
> ないことがわかり、勉強しなおしたいと思っています。
その「いろいろ考えた」ことが聞きたいなぁ...
> 例えば、ある isolationレベルのトランザクションで、複数行を順繰り
> に削除する処理と更新する処理が同時に走ったときに、テーブルにロッ
> クをかける必要があるのかどうか」といった問題を、きちんと解ける
> 力をつけたいのです。
トランザクションってのは、データベースへの処理の集合で、それを
単位に、逐次に実行したのと同じなって欲しいものですよね。
で、普通に、レコードを 2 phase lock してやって、dead lock を
避けるために、複数のlockをかける時は、順序を全部同じにするよ
うに心がけて... ぐらいでいいんじゃないですか? (僕の理解はそ
の程度...)
ロックの単位をテーブルにするかレコードにするか、あるいは、述
語にするかを一般的に選択する基準は、僕は知りません。そんなも
のはないのだと思います。
> データベースのトランザクション隔離レベルについて、わかりやすく
> 説明された書籍やウェブページは無いでしょうか。
> 「低い隔離レベルだとこういう処理がうまくいかない」といった例が
> 豊富だと嬉しいです。
Date の Database System Concepts とかが教科書だけど...
そういえば、ジム・グレイの「トランザクション処理」も出てたな。
最初にトランザクションを勉強したのは、ジム・グレイのなんかの
レポートでした。
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
河野真治 @ 琉球大学工学部情報工学科,
Yasushi Shinjo
In article <bq10bl$1j9$1...@news-wst.ocn.ad.jp>
Tanaka-Qtaro-Yasuhiro <ta...@ca2.so-net.ne.jp> writes:
> 田中久太郎です。
> データベースのトランザクション隔離レベルについて、わかりやすく
> 説明された書籍やウェブページは無いでしょうか。
> 「低い隔離レベルだとこういう処理がうまくいかない」といった例が
> 豊富だと嬉しいです。
基本的な話は、Tannenbaum の OS か分散システムの教科書でもい
いかと思います。トランザクションの話の部分は、薄いし。
> 例えば、ある isolationレベルのトランザクションで、複数行を順繰り
> に削除する処理と更新する処理が同時に走ったときに、テーブルにロッ
> クをかける必要があるのかどうか」といった問題を、きちんと解ける
> 力をつけたいのです。
「isolation レベル」というのは、トランザクションの基本的な話
にはないです。基本は、begin_transaction, commit, abort の３
つだけ。
In article <3989215...@insigna.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> トランザクションってのは、データベースへの処理の集合で、それを
> 単位に、逐次に実行したのと同じなって欲しいものですよね。
はい。serializability といいます。
> で、普通に、レコードを 2 phase lock してやって、dead lock を
> 避けるために、複数のlockをかける時は、順序を全部同じにするよ
> うに心がけて... ぐらいでいいんじゃないですか? (僕の理解はそ
> の程度...)
これは、トランザクションの「実装」の話です。単にトランザクショ
ンをユーザとして使う時には、「ロックの話は一切でてきません」。
ロックが出てこないというのは、かなりすごい性質です。ロックが
ないので当然デットロックの心配もする必要がありません。ロック
のプログラムではまっている人は、トランザクションが使えるなら
そちらに移行するといいでしょう。(ロックをやめてトランザクショ
ンに移行するという話は、あんまり知られていない技術かもしれま
せん。)
トランザクションの実装は、ロックを使ってもいいし、ログを使っ
たりシャドウ・コピーを使ったり、分散だと２層コミットを使った
りといろいろ難しいです。使う方の楽さとは全然違います。
> Date の Database System Concepts とかが教科書だけど...
> そういえば、ジム・グレイの「トランザクション処理」も出てたな。
> 最初にトランザクションを勉強したのは、ジム・グレイのなんかの
> レポートでした。
ジム・グレイの分厚い教科書は、日本語訳も出ています。
Jim Gray (原著), Andreas Reuter (原著), 喜連川 優 (翻訳):
トランザクション処理〈上下〉―概念と技法―,
日経BP社(2001年).
ISBN: 4822281027, 4822281035
この本は、厚いので、ちょっと気軽に勉強というよりは、気合いを
入れて勉強するのに向いています。私は日英両方持っているけど。
In article <bq10bl$1j9$1...@news-wst.ocn.ad.jp>
Tanaka-Qtaro-Yasuhiro <ta...@ca2.so-net.ne.jp> writes:
> 例えば、ある isolationレベルのトランザクションで、複数行を順繰り
> に削除する処理と更新する処理が同時に走ったときに、テーブルにロッ
> クをかける必要があるのかどうか」といった問題を、きちんと解ける
> 力をつけたいのです。
こういう話だと、ロックは不要です。こんな感じ。
------------------------------------------------------------
begin_transaction();
行を削除;
if( ... )
行を削除;
行を削除;
行を削除;
if( うまくいったみたい() )
commit();
else
abort();
------------------------------------------------------------
「うまくいったみたい()」という述語ですが、ここで判定できない
なら true を入れておいてかまいません。つまり、単に commit()
を呼びます。
もし、何か問題が起きたら、トランザクション処理システムの方で
自動的に abort() が呼ばれます。commit() と呼んでも、abort()
されるかもしれないし、実装によっては、「行を削除」の段階で、
このスレッドが殺される（あとはやるだけ無駄）こともあります。
使う方としては、このコードのレベルでは裏の事情を気にする必要
はありません。
トランザクションは、たしかに fj.comp.databases なんだけど、
fj.comp.parallel としたい感じもあるんですよね。
＼＼ 新城 靖 （しんじょう やすし） ＼＼
＼＼ 筑波大学 電子・情報 ＼＼
Tanaka-Qtaro-Yasuhiro
Shinji KONOさんの<3989215...@insigna.ie.u-ryukyu.ac.jp>から
>> 最近、データベースのトランザクション処理について、いろいろ考え
>> る機会があったのですが、自分自身かなりあやふやにしか理解できて
>> ないことがわかり、勉強しなおしたいと思っています。
>
>その「いろいろ考えた」ことが聞きたいなぁ...
いやあ、お恥ずかしい。
データベースの処理を作るときに、「トランザクションで囲んでおきさえ
すれば、ACID特性はしっかり守られて問題ナシ」とか思って作っていたら、
isolation levelが READ COMMITEDだったので、処理を全部見直す必要が
出てきた、とまあそんなところです。
副問い合わせで最大値とって結合してたり、でもってその結果で削除する
行を決めてたりとか、複雑な処理だとこんがらがっちゃうんですね。
で、トランザクション処理をうまく設計する定石とか基準みたいなものが
あるんじゃないかと思い、さきの質問を投げたわけです。
>トランザクションってのは、データベースへの処理の集合で、それを
>単位に、逐次に実行したのと同じなって欲しいものですよね。
そうなんです。どんなときでもそうなって欲しいんだけど、それが守られ
るのは、ISOLATION LEVELが SERIALIZABLEなときだけなんですよね。
やばそうな処理をするときだけ、ISOLATION LEVELを上げるというのも手な
んだろうけど。
>で、普通に、レコードを 2 phase lock してやって、dead lock を
>避けるために、複数のlockをかける時は、順序を全部同じにするよ
>うに心がけて... ぐらいでいいんじゃないですか? (僕の理解はそ
>の程度...)
そうか、あまり複雑に考える必要もなさそうですね。
基本的に処理中に触るデータには最初に全部順序良くロックする、と。
それで、効率とかトランザクションで保証されるところとかを考慮しなが
ら調整していく感じでしょうか。
>ロックの単位をテーブルにするかレコードにするか、あるいは、述
>語にするかを一般的に選択する基準は、僕は知りません。そんなも
>のはないのだと思います。
そういう基準は、めんどくささと効率とか比べながら、個々の場合で考え
ていくしかないんでしょうね。
>Date の Database System Concepts とかが教科書だけど...
和訳が無いかなと思って調べてみたんですけど、これがそうですかね？
http://www.amazon.co.jp/exec/obidos/ASIN/4621042769
うーん、高すぎて買えない…。図書館にあるかな。
--
Tanaka-Qtaro-Yasuhiro mailto:ta...@ca2.so-net.ne.jp
Shinji KONO
In article <bq29jh$7m1$1...@news-wst.ocn.ad.jp>, Tanaka-Qtaro-Yasuhiro <ta...@ca2.so-net.ne.jp> writes
> データベースの処理を作るときに、「トランザクションで囲んでおきさえ
> すれば、ACID特性はしっかり守られて問題ナシ」とか思って作っていたら、
新城さん方式ね。
> isolation levelが READ COMMITEDだったので、処理を全部見直す必要が
> 出てきた、とまあそんなところです。
あぁ。なるほど。
ACID ってのは、Atomicity, Consistency, Isolation, Durability の
ACID なのね。これらは自分で選択するものですよね。
> 副問い合わせで最大値とって結合してたり、でもってその結果で削除する
> 行を決めてたりとか、複雑な処理だとこんがらがっちゃうんですね。
確かにそうですね。
副問い合わせで最大値とって結合してたり
のあたりは実はどれをとるかは正確である必要はなくて、一方で、
削除の前後で、データベースの正確さは維持したい
みたいな場合もありますよね。
あるいは、
削除によって、データベース中の最大値の性質を維持したい
みたいな場合もあると思います。前者だと、それぞれを二つ別なト
ランザクションにしても良くて、後者では一つにしないとだめです。
> やばそうな処理をするときだけ、ISOLATION LEVELを上げるというのも手な
> んだろうけど。
どっちかっていうと逆でデータベースでなんらかの性質を維持した
いのならば、全部SERIALIZEでないとだめです。「データベースに
は変更を加えないことがわかっている」とか「不正確なデータでも
いいから速くとりたい」ような場合に、ISOLATION LEVELを下げる
ってことじゃないかな。
「性能が下がりそうなところを下げる」ってことなんだと思います。
おそらくは、ISOLATION LEVELで lockの種類を決めているんでしょ
う。Shared lock しかかけないとかさ。
しょせん、実装を知らないでいじっても、結局は混乱するだけって
いうことなんじゃないかなぁ。
KAWAMOTO, Minoru
<bq29jh$7m1$1...@news-wst.ocn.ad.jp>の記事において
Tanaka-Qtaro-Yasuhiroさんは書きました．
>> Shinji KONOさんの<3989215...@insigna.ie.u-ryukyu.ac.jp>から
>> >Date の Database System Concepts とかが教科書だけど...
この書名は Silberschatz の方ですね。
>> 和訳が無いかなと思って調べてみたんですけど、これがそうですかね？
>> http://www.amazon.co.jp/exec/obidos/ASIN/4621042769
>>
>> うーん、高すぎて買えない…。図書館にあるかな。
http://www.amazon.com/exec/obidos/tg/detail/-/0201684195/002-0332840-9124059
原著ならハードカバーで $95...@amazon.com です。値段の方は記憶が曖昧ですが、
八重洲ブックセンターでペーパーバック(7th Ed.)を5,000円ぐらいで買いました。
(２、３年前のこと。8th Ed.はまだハードカバーしか出ていないと思います。)
と思ったらukの方にペーパーバックの扱いがありました。
http://www.amazon.co.uk/exec/obidos/ASIN/0321189566/202-4428601-1157441
版の新しさからいっても、よほど困難でない限り原著を読むのをおすすめします。
Tanaka-Qtaro-Yasuhiro
皆さん、フォローありがとうございます。
Shinji KONOさんの<3989220...@insigna.ie.u-ryukyu.ac.jp>から
>どっちかっていうと逆でデータベースでなんらかの性質を維持した
>いのならば、全部SERIALIZEでないとだめです。「データベースに
>は変更を加えないことがわかっている」とか「不正確なデータでも
>いいから速くとりたい」ような場合に、ISOLATION LEVELを下げる
>ってことじゃないかな。
そうか。そうですよね。
新城さんも書いているようにトランザクションって楽をするためにあるん
だから、低いISOLATION LEVELでロック処理に頭を悩ませるのは、本末転倒
なんでしょうね。
>しょせん、実装を知らないでいじっても、結局は混乱するだけって
>いうことなんじゃないかなぁ。
おっしゃる通りだと思います。
--
Tanaka-Qtaro-Yasuhiro mailto:ta...@ca2.so-net.ne.jp
Tanaka-Qtaro-Yasuhiro
KAWAMOTO, Minoruさんの<bq2f2d$onl$1...@news.sfc.keio.ac.jp>から
>と思ったらukの方にペーパーバックの扱いがありました。
>http://www.amazon.co.uk/exec/obidos/ASIN/0321189566/202-4428601-1157441
>
>版の新しさからいっても、よほど困難でない限り原著を読むのをおすすめします。
英語を読むのは苦手なほうなのですが、値段と版の差を考えると
たしかに原著のほうが良さそうですね。
情報ありがとうございました。
--
Tanaka-Qtaro-Yasuhiro mailto:ta...@ca2.so-net.ne.jp
Yasushi Shinjo
In article <bq29jh$7m1$1...@news-wst.ocn.ad.jp>
Tanaka-Qtaro-Yasuhiro <ta...@ca2.so-net.ne.jp> writes:
> データベースの処理を作るときに、「トランザクションで囲んでおきさえ
> すれば、ACID特性はしっかり守られて問題ナシ」とか思って作っていたら、
> isolation levelが READ COMMITEDだったので、処理を全部見直す必要が
> 出てきた、とまあそんなところです。
isolation level って、そんな話だったんですか。と、例の本を見
てみると、書いてありますね。日本語だと上巻の４８４ページあた
り。「カーソル安定」とか２次とか。「更新データの消失がなく、
ダーティ・データを読まない」という性質が保証されるみたい。
In article <bq29jh$7m1$1...@news-wst.ocn.ad.jp>
Tanaka-Qtaro-Yasuhiro <ta...@ca2.so-net.ne.jp> writes:
> 副問い合わせで最大値とって結合してたり、でもってその結果で削除する
> 行を決めてたりとか、複雑な処理だとこんがらがっちゃうんですね。
> で、トランザクション処理をうまく設計する定石とか基準みたいなものが
> あるんじゃないかと思い、さきの質問を投げたわけです。
図７．８に「一見等かだが実は違うさうつのありふれたプログラム」
というのがあって、２次（read committed）だと失敗する例が出て
います。
exec sql select balance
into:balance
from account
where account_id = :id
balance = balance + 10;
exec sql update = :balance
where account_id = :id;
成功するのは、たとえば、こんなもの。
exec sql update account
set balnce = balance + 10
where account_id = :id;
In article <3989220...@insigna.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 河野真治 @ 琉球大学情報工学です。(Oracle の話?)
> 「性能が下がりそうなところを下げる」ってことなんだと思います。
> おそらくは、ISOLATION LEVELで lockの種類を決めているんでしょ
> う。Shared lock しかかけないとかさ。
書込んだデータは、長期排他ロックて、読込んだデータは短期排他
ロック、ということみたい。表７．９。４８６ページ。
In article <bq4s0n$js9$1...@news-wst.ocn.ad.jp>
Tanaka-Qtaro-Yasuhiro <ta...@ca2.so-net.ne.jp> writes:
> 田中久太郎です。
> 英語を読むのは苦手なほうなのですが、値段と版の差を考えると
> たしかに原著のほうが良さそうですね。
いえいえ。喜連川先生の本ということで、日本語の方がいいと思い
ます。つまり、一種のブランド品なんです。これを持っていると喜
連川先生に少し近づいた気がするということです。
KAWAMOTO, Minoru
<YAS.03No...@kirk.is.tsukuba.ac.jp>の記事において
Yasushi Shinjoさんは書きました．
>> 新城＠筑波大学情報です。こんにちは。
>> In article <bq4s0n$js9$1...@news-wst.ocn.ad.jp>
>> Tanaka-Qtaro-Yasuhiro <ta...@ca2.so-net.ne.jp> writes:
>> > 田中久太郎です。
>> > 英語を読むのは苦手なほうなのですが、値段と版の差を考えると
>> > たしかに原著のほうが良さそうですね。
>> いえいえ。喜連川先生の本ということで、日本語の方がいいと思い
>> ます。つまり、一種のブランド品なんです。これを持っていると喜
>> 連川先生に少し近づいた気がするということです。
もとのくだりはDate本についてですので。
Gray本についてでしたら私も訳本をおすすめします。
という私も文脈を読めていなかったのですが、これぐらいの深さの話になると
Date 本も Silberschatz 本もちょっと量が足りないかと思います。
Shinji KONO
In article <bq53n4$kci$1...@news.sfc.keio.ac.jp>, k1...@sfc.keio.ac.jp (KAWAMOTO, Minoru) writes
> という私も文脈を読めていなかったのですが、これぐらいの深さの話になると
> Date 本も Silberschatz 本もちょっと量が足りないかと思います。
両方とも教科書だから専門書ってわけじゃないですからねぇ。たぶん、
足りないのは量じゃなくて深さなんでしょ?
でも、そんなに深い話だとは思わないけど...