Enviar pesquisa
Carregar
A critique of ansi sql isolation levels 解説公開用
•
Transferir como PPTX, PDF
•
13 gostaram
•
8,683 visualizações
T
Takashi Kambayashi
Seguir
A Critique of ANSI SQL Isolation Levelsの解説。
Leia menos
Leia mais
Tecnologia
Denunciar
Compartilhar
Denunciar
Compartilhar
1 de 69
Baixar agora
Recomendados
Dbts 分散olt pv2
Dbts 分散olt pv2
Takashi Kambayashi
並行実行制御の最適化手法
並行実行制御の最適化手法
Sho Nakazono
MVSR Schedulerを作るための指針
MVSR Schedulerを作るための指針
NTT Software Innovation Center
トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2
Takashi Hoshino
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
Masahiko Sawada
詳説データベース輪読会: 分散合意その2
詳説データベース輪読会: 分散合意その2
Sho Nakazono
MHA for MySQLとDeNAのオープンソースの話
MHA for MySQLとDeNAのオープンソースの話
Yoshinori Matsunobu
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Toru Makabe
Recomendados
Dbts 分散olt pv2
Dbts 分散olt pv2
Takashi Kambayashi
並行実行制御の最適化手法
並行実行制御の最適化手法
Sho Nakazono
MVSR Schedulerを作るための指針
MVSR Schedulerを作るための指針
NTT Software Innovation Center
トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2
Takashi Hoshino
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
Masahiko Sawada
詳説データベース輪読会: 分散合意その2
詳説データベース輪読会: 分散合意その2
Sho Nakazono
MHA for MySQLとDeNAのオープンソースの話
MHA for MySQLとDeNAのオープンソースの話
Yoshinori Matsunobu
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Toru Makabe
PostgreSQLでスケールアウト
PostgreSQLでスケールアウト
Masahiko Sawada
PostgreSQLによるデータ分析ことはじめ
PostgreSQLによるデータ分析ことはじめ
Ohyama Masanori
大規模データ活用向けストレージレイヤソフトのこれまでとこれから(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
大規模データ活用向けストレージレイヤソフトのこれまでとこれから(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
NTT DATA Technology & Innovation
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
NTT DATA Technology & Innovation
アプリ開発者、DB 管理者視点での Cloud Spanner 活用方法 | 第 10 回 Google Cloud INSIDE Games & App...
アプリ開発者、DB 管理者視点での Cloud Spanner 活用方法 | 第 10 回 Google Cloud INSIDE Games & App...
Google Cloud Platform - Japan
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
NTT DATA OSS Professional Services
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
歩 柴田
Transactional Information Systems入門
Transactional Information Systems入門
nobu_k
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Kazutaka Tomita
Cassandraとh baseの比較して入門するno sql
Cassandraとh baseの比較して入門するno sql
Yutuki r
CXL_説明_公開用.pdf
CXL_説明_公開用.pdf
Yasunori Goto
トランザクション入門
トランザクション入門
Kumazaki Hiroki
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Noritaka Sekiyama
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
NTT DATA OSS Professional Services
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
NTT DATA Technology & Innovation
VSCodeで作るPostgreSQL開発環境(第25回 PostgreSQLアンカンファレンス@オンライン 発表資料)
VSCodeで作るPostgreSQL開発環境(第25回 PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
Raft
Raft
Preferred Networks
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
NTT DATA Technology & Innovation
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
Hiroshi Tomioka
Mais conteúdo relacionado
Mais procurados
PostgreSQLでスケールアウト
PostgreSQLでスケールアウト
Masahiko Sawada
PostgreSQLによるデータ分析ことはじめ
PostgreSQLによるデータ分析ことはじめ
Ohyama Masanori
大規模データ活用向けストレージレイヤソフトのこれまでとこれから(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
大規模データ活用向けストレージレイヤソフトのこれまでとこれから(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
NTT DATA Technology & Innovation
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
NTT DATA Technology & Innovation
アプリ開発者、DB 管理者視点での Cloud Spanner 活用方法 | 第 10 回 Google Cloud INSIDE Games & App...
アプリ開発者、DB 管理者視点での Cloud Spanner 活用方法 | 第 10 回 Google Cloud INSIDE Games & App...
Google Cloud Platform - Japan
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
NTT DATA OSS Professional Services
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
歩 柴田
Transactional Information Systems入門
Transactional Information Systems入門
nobu_k
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Kazutaka Tomita
Cassandraとh baseの比較して入門するno sql
Cassandraとh baseの比較して入門するno sql
Yutuki r
CXL_説明_公開用.pdf
CXL_説明_公開用.pdf
Yasunori Goto
トランザクション入門
トランザクション入門
Kumazaki Hiroki
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Noritaka Sekiyama
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
NTT DATA OSS Professional Services
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
NTT DATA Technology & Innovation
VSCodeで作るPostgreSQL開発環境(第25回 PostgreSQLアンカンファレンス@オンライン 発表資料)
VSCodeで作るPostgreSQL開発環境(第25回 PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
Raft
Raft
Preferred Networks
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
NTT DATA Technology & Innovation
Mais procurados
(20)
PostgreSQLでスケールアウト
PostgreSQLでスケールアウト
PostgreSQLによるデータ分析ことはじめ
PostgreSQLによるデータ分析ことはじめ
大規模データ活用向けストレージレイヤソフトのこれまでとこれから(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
大規模データ活用向けストレージレイヤソフトのこれまでとこれから(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
アプリ開発者、DB 管理者視点での Cloud Spanner 活用方法 | 第 10 回 Google Cloud INSIDE Games & App...
アプリ開発者、DB 管理者視点での Cloud Spanner 活用方法 | 第 10 回 Google Cloud INSIDE Games & App...
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
Transactional Information Systems入門
Transactional Information Systems入門
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraとh baseの比較して入門するno sql
Cassandraとh baseの比較して入門するno sql
CXL_説明_公開用.pdf
CXL_説明_公開用.pdf
トランザクション入門
トランザクション入門
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
VSCodeで作るPostgreSQL開発環境(第25回 PostgreSQLアンカンファレンス@オンライン 発表資料)
VSCodeで作るPostgreSQL開発環境(第25回 PostgreSQLアンカンファレンス@オンライン 発表資料)
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Raft
Raft
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Último
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
Hiroshi Tomioka
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
CRI Japan, Inc.
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
CRI Japan, Inc.
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NTT DATA Technology & Innovation
Último
(7)
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
A critique of ansi sql isolation levels 解説公開用
1.
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
2.
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の実装の主流のひとつになっていまも続いている。 – 何のかんので引用数はかなりある。 – 知らないと話にならない。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 1
3.
Motivation 1
なぜ今更TX処理とかいうのか? – 「もう枯れてんじゃないのか?」 – 割とある程度枯れてはいますね。ただし、全ての問題が解決しているか ?というと、そうでもないようです。 – HadoopやNoSQLで分散環境が普通に導入されつつあります。が、 NoSQLは基本的にはTXはサポートしていません。・・・って、そもそ もTXなんだっけ?という話に戻ることが多いわけです。 – 「TX処理でのconsistency」って、ちゃんと説明できないとまずい。 分散処理のconsistencyとは違いますが、とはいえ・・・ Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 2
4.
Motivation 2
Welcome Back to RDBMSの流れ – 2010年前後に一斉にRDBMSの特許が切れ始める。 まずはINDEX系 – 大規模分散は、ある程度道ができた。 んじゃ残りは? Hadoopが予想外に普及〜「大規模な単純な数え上げ」なら最強 – 今、一斉に「RDBMSに逆張り」を始めている OSS? 中規模〜小規模データの処理 – 基本は「ACIDで可能であれば分散させたい」 いままで屍累々の道を再び。 大規模じゃなくて、中規模ならどうよ? – そもそも分散TXって・・・ Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 3
5.
TX処理
基本的にACID属性 – Atomic すべてのTXは処理は終わるか、さもなければ失敗する TXの最後の操作はcommitかまたはabort – Consistency すべてのTX処理は整合性をもつ 不変述語(invariant predicate)が充足されること – TXの最中は一時的な不変述語が偽になるので、TXの最後に一貫性が保たれるよう にする。 ま、人によっていうことが違うが、ある程度の合意はできている。 「correctである」ということ – Isolated あるTXの処理は、別のTXの処理の影響を受けない – Durable すべてのTX処理の結果は永続化する 本日の話題 – 最大の問題は、ConsistencyとIsolation 特にIsolationがConsistencyに深く絡むので問題 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 4
6.
そんじゃ行ってみよう!
まず注意書き 基本的に論文の紹介なので、かなりいろいろ端折っています。 いちいち全部訳していると全訳になるので、それは勘弁してくださ い。 – 全訳するとそれはそれでかなり意味不明になる気もするので、各自読ん で確認してください 割と細かい部分で微妙な言い回しをしているところがあって、その 辺はサクッと無視しています。TX業界の当時のコンテクストを偲ば せるところもあるのですが、それは各自勝手に味わってください。 – たとえば箱崎方面のDBとか(ry – たとえば赤い会社のDBとか(ry Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 5
7.
そんじゃ行ってみますよ!
Abstract 「ANSI ではIsolation レベルの定義をphenomenaという言い方で定義 している。すなわち、Dirty read, Non-repeatable read, と Phantomであ る。」 「ただ、この定義では、標準的なロック実装を含めたIsolationレベ ルの設定には適切ではない。なので、この曖昧さを明確にし、 Snapshot Isolationを提案することで、よりましなIsolationレベルとい うものを定義しようじゃまいか。」 という内容だ。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 6
8.
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がしっかりしていないとアプリサイドでいち い注意を払う必要が出てきてしまう」という趣旨のことを述べてます。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 7
9.
(解説)「Correctとはどういう意味か?」
全部のTxが意図した通りになっていればいんじゃね? – 意図した通り? – なにその主観的判断わ。 なので、Semanticsを決定して、correctnessの真偽値の判別関数を用 意して、その値が真になる集合を定義する。この集合に入れば、 correctと言える。 そもそも「意図した通りにならない」とはどういう状況よ? – TXさせないぞ三兄弟(世界共通) Lost update Dirty read Inconsistent Read (Non-repeatable, Phantom) Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 8
10.
引き続き論文を
「まず、ANSIの定義ですが・・・Isolationの定義は以下 – 1 READ UNCOMMITTED – 2 READ COMMITTED – 3 REPEATABLE READ – 4 SERIALABLE – になっています。」 「んでそれぞれのレベルはそれぞれの問題となるphenomenaを防止 することになりますよ、とそういう定義ですね。すなわち・・」 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 9
11.
引き続き論文を
「1 READ UNCOMMITTED -> Dirty read 2 READ COMMITTED -> Non-repeatable read 3 REPEATABLE READ -> Phantom 4 SERIALABLE」 一応、この論文では「phenomenaという表現ではなく、anomalyとい う表現を使う」と言っています。違いはまぁあるにはありますが、 「それほど重大では(理解する上では)ありませんよ」と。 anomaly、というのは正確な日本語がないのですが、変則状態とかそ んな訳語が当てられることが多いようです。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 10
12.
引き続き論文を
「ANSIの定義は、そもそも2PL等のロック・スケジューラーに関連 づけられていて、この起こりはロッキング・データフローグラフ・ anomalyという形で定義されたDegree of Consistencyというのが、そ れにあたります。Phenomena(anomalies)でのIsolationの定義は、SQL 標準でのノン・ロックベースでの実装を許容を意図したものだった のでござる」 – 「ロックベースでの実装がIsolationレベルの基本になっていたので、そ れ以外の道を模索するべくANSIは意図していた」ということにようで す。ま、実際、実装はロックベースがほとんどでしょうから、そういう 意味ではANSIの意図自体を否定しているようではないですね。とはい え・・・ んで、「このANSIの定義は、曖昧で、しかもどう広く解釈しても anomalyを排除できず、lockベースのIsolationと異なった結果になる 上に、現在の商用のシステムに役に立ちませんね。」というさんざ んのいいようにつながります。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 11
13.
(解説)基本戦略
Isolationレベルは基本は「どう妥協するか?」という戦術。 – 基本はserializableにもっていく – ただし、concurrencyが下がるので妥協していく。 「世の中一般にはserializableは遅いので使うな」という言い方がさ れることがあるが、DB屋的にはこれは普通に屈辱(のはず。) – lockレスで、そのまま放り込めば、concurrentなままserializableなスケジ ュールを組みあげるというのが、最適な実装。 アプリでの明示ロックは本来はうれしくない。もったまま死なれるとabortが でて、最悪はabortのcascadingが起きて・・・・ – とはいえ、できない・・・ので、どうやってIsolationレベルを緩めるか ということを考える。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 12
14.
とりあえず論文の展開は・・・
以下、各章のサマリーが記述されます。 「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章がサマリーと結論ですね。」 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 13
15.
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の定 義になります。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 14
16.
(解説)再び~「Correctとはどういう意味か?」
全部のTxが意図した通りになっていればよい? – 意図した通り? Semanticsを決定して、correctnessの真偽値の判別関数を用意して、その 値が真になる集合を定義する。この集合に入れば、correctと言える。 「最低でも一つは真である」ということが保証される必要がある – +「判断可能である」 – +「十分に広い集合である」 – ・・・という条件がいる。 最低でも一つは真であるとはどういう状態か? – 「それぞれTXを単独で実行して得られるsemanticを真とする」ということ Serializeの定義 T1T2T3.....Tn 「各TXを順番に実行する。」このとき得られる解釈を真とする 解釈?意味分かんないんだけど?値とか? Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 15
17.
(解説) TX処理の目標
完全にSerializeされた各TX処理の実行結果から得られる「解釈」は 正しい(と設定する) – ただしconcurrencyは、ほぼ存在しない この場合は各TXの内容を順番に実行するだけである。 concurrencyが有った方が効率がよい(という前提)において、各TX を構成操作(operation)に分解して、それぞれの操作をまぜて(shuffle) 実行すると、concurrencyが上がっていく(はず)。 – すなわち、serializeなスケジュール(TXの順序実行)を緩めていって、 concurrencyを上げていくことが目標になる。 同時に処理されるTXのすべてのoperationを、一定のルールに基づい て(各TX内部での順序は保証した上で)並べかえて、正しい解釈を 取得することが可能であるとすると、もっとも制限の緩いルールは 何か? Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 16
18.
(解説) TX処理の目標
そもそもserializeと同じ解釈になる、とはどういうことかを決めない といけないですよね。 – 最後の値が同じならいいのか? – データの連携のコンテストが同じならいいのか? – (途中も含めた)更新処理の結果が同じならいいのか? 合ってるかどうかが判断可能でないと無意味ですね。 判断が実効時間内で計算することが可能でないと無意味だわね。 判別関数が(割と)平易に実装できないと無意味じゃね? おお、あんたこれはまたハードル、ガン上げじゃね? Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 17
19.
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がもっとも集合としては小さい – まずは、データのつながりから見ていく Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 18
20.
(解説)Serializeしたものと同じ「意味」ってなんですか?
TXの文法から T p1.... pm PはトランザクションT の各ステップを表す 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 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 19
21.
(解説) 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である Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 20
22.
(解説) Serializeしたものと同じ「意味」ってなんですか?
準備完了! – スケジュール s のセマンティクスを定義できる H s :D HU – すなわち H s x : H wi x 「データのつながりのセマンティクス」が同じ – Final State Serializability (FSR) – View Serializability (VSR) – 以上はこのエルブラン・セマンティクスで表現可能 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 21
23.
Final State Serializability
(FSR) 定義 – あるhistoryがserialである。 – そのhistoryとfinal stateが同等(final state equivalence)であるhistoryはFSR である。 final state equivalence – 構成されているoperationが同一である。 – historyの最後(final )の各ページの状態(state)に至るまでの再帰的な エルブラン関数の構成が同じである。 – ということ。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 22
24.
View Serializability (VSR)
定義 – あるhistoryがserialである。 – そのhistoryとviewが同等(view equivalence)であるhistoryはVSRである。 view equivalence – 構成されているoperationが同一である。 – historyの最後(final )の各ページの状態(state)に至るまでの再帰的な エルブラン関数の構成が同じである。 – すべてのreadについてのエルブラン・セマンティクスが同一である。 結果としてVSR⊂FSR Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 23
25.
(解説) 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に含まれるから Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 24
26.
ここで論文に戻ります
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) Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 25
27.
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 – この場合は、明確に問題になる。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 26
28.
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)ということもありますね。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 27
29.
補足が続く
「この論文では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といいましょう。」 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 28
30.
んでまとめると・・・
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 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 29
31.
それでは次にどうするのか
ANSIの定義では曖昧すぎるので、別のIsolationをもってくれば、も う尐しまともになるかもしれない・・・一般によく使われている LockベースのIsolationをもってきて比較してみる。 以下、論文の展開 – 「大抵のSQL 製品はロック・ベースのIsolationを利用しているので、ま ずはANSI SQL Isolationをロックの観点から対応させましょうか。(まぁ 無理があるんですがね)」 – 以下、lockのお話。 – 「ロックは基本的にRead(Shared)とWrite(Exclusive)で、異なるTXが同一 のデータまたはデータセットに対してロックをとろうとするとconflictに なります。」 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 30
32.
引き続きLockの話題
– 「predicate lockはある一定の条件にあうデータセットに対してロックを かけるわけだが、これはSQLの言い方としては、phantomを”含む”。すな わち、もしIDMされたのであれば、条件に合致した、であろう、現時点 ではDB上にないデータを含むということ。」 簡単に言うと、TXの開始時点では存在しなかったけれども、その途中で別の TXにより生成されてかつ条件にあるデータセット(すなわちphantom)も本 来はロックの対象になる、という意味ですね。 – 「できんのか?w」って話しは別の話題かとw 現実的には複雑なPredicateであれば、ほぼ非現実的になるので、一定の枠を つくって、あの手この手でなんとかするというのが、ありがちなパターンで すが、有効打はあまりないようです。 predicateを含むTXではserializableなスケジュールは、そもそも困難です。形 式的にはconflictはページ単位で設定はできますが、predicateになった途端に conflictグラフの形成がコスト的に難しいでしょう。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 31
33.
まだLockの話題
– 「んで、複数のTXがあれば、当然ロックは競合しますよ、」と – 次にwell-formedの定義 – well-formed read (write)の定義が出てきますが・・そもそもこういったル ールをなぜ設定しているかというとロックの取得とリリースのタイミン グで、ロックのプロトコルが変わるため、全体としてまずロックのカテ ゴリーを決めておくということだと思います。 – 論文とは別に、ここで厳密な定義を書いておきます。 rule 1 oprerationの前には必ずロックをとる。ロックのリリースは必ずoperation の後になる rule2 TX内部でのあるデータに対するロックは一回のみ(同じデータに対し て、同一TX内部で複数回ロックはとらない) rule3 同様にリリースは一回のみ Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 32
34.
さらにLockの話題
つぎにlong duration lock と short duration lockの説明が来ます。 – long durationはTXがabortかcommitされるまでlock保持するもので、short durationは対象データの操作が終わった直後にlockがリリースされるもの ですね。 次に2PLの定義らしきものを述べます。(論文での表現が微妙なの で) 論文:「あるTXがロックをとっていて、別のTXがconflictロックを とりに行ったときは、前のTXのロックがリリースされるまで、ロッ クがとれない」という表現です 厳密には、「すべてのTXにおいて、その同一TXに含まれる、ある 操作のロックリリースのあとには、そのTX内ではロック取得のステ ップは存在しない」ということになります。ほぼ同じ意味ですが。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 33
35.
基本の定理
ここで、 – 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 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 34
36.
つまり・・・
「 well-formed two-phase locking guarantees serializability」 これぐらい知っておけと? 知らないやつとかあり得ないよね? と? Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 35
37.
(解説)なので、まじめに証明します。
ロジックは簡単です。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が効いてきます。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 36
38.
(解説)引き続き
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 . Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 37
39.
(解説)続き
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). – 以上でござる。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 38
40.
Degree of consistency
Lockの内容を一通り外観したあとで、これをIsolation levelに関連づ けることを行って行きます そのために、まず、degrees of consistencyというコンセプトをロック ・依存関係・anomalyの特徴から四つに分類します。 こいつはGrayの別の論文から引っ張ってきてます。んでその論文の definition 1を見ろ、という内容ですが・・・それはこんな感じです ね。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 39
41.
(解説) 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という概念をとりあえずは導入しています。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 40
42.
LockingベースのIsolationの検討
さらに、Isolationのレベルをロックスコープとr/wのモードとduration (長さ)で分類しています。すなわち Locking READ UNCOMMITTED Locking READ COMMITTED Locking REPEATABLE READ Locking SERIALIZABLE 「一応ANSIの定義に合わせますが、実際はかなり異なったものにな っているので、Lockingという表現を入れて、区別しています。」 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 41
43.
まとめると以下
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) Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 42
44.
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を拡張してますが、これは後述します。」 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 43
45.
(解説)閑話休題
という感じで、これでもか、というぐらいANSIのdisりが続きます・ ・・ 「Repeatable read」という言葉 – 論文の記述にあるとおり、基本的にANSIの用語はきわめて不適切。 – また、現在の使われ方もかなり間違っていることが多いです。 – 「定義として“同一TX内部で同じ値を読んだ時に同じ値が取得できる”と いうことではない」です。 結果がそうなるのであって、定義ではなく効果。 そもそもPhantomは絶対に除去できない。 同一対象についての 別々のTXでのr-wの関係があった時にphantomが除去でき ない程度にそれぞれのTXがIsolateされる、ということ。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 44
46.
Isolationレベルの比較のコンセプトの導入
まず、定義です。 – Isolation levelの「weakness」です。 – あんまり大したことは言ってないのですが、これ以降の論文では大抵は 無条件でweakという用語を使ってきますが、これはその元の定義になっ ていると思います。 定義的には、non-serializable historyがより広く(一つでも多く)含 まれる方が weakです。完全に一致する場合は同値になります。 前提として、Locking SERIALIZABLEがすべてのserializableの集合と 同値ではないことはわかっていますが、便宜的に同値とします。 weaknessでならべると – Locking READ UNCOMMITTED << Locking READ COMMITTED << Locking REPEATABLE READ << Locking SERIALIZABLE 以上で準備完了 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 45
47.
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) るように修正しないといけない。」 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 46
48.
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の広い解釈の方が正しい。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 47
49.
Analyzing ANSI SQL
Isolation Level 次に似たような議論として、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)の時点で検出される。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 48
50.
Analyzing ANSI SQL
Isolation Level 最後に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りつつも、そもそもの意図は悪くなかったwと一応持ち上げるJim Gray先生の面目躍如 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 49
51.
Analyzing ANSI SQL
Isolation Level (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にまとめて ある。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 50
52.
Analyzing ANSI SQL
Isolation Level 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 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 51
53.
Analyzing ANSI SQL
Isolation Level 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の再定義に過ぎない。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 52
54.
(解説)議論・・・
Lock万能主義的な発想について – 割と多い – S2PL⊂CSRが数学的に証明済み したがってserializable – 割と安全の処理することが可能 ただし、実装は実際はかなりハードルが高い – 尐なくともミドルの外部からロックを制御させるという方式は得策では ない – 理論的にはミドル内部では実装した方がかなりセキュアに作り上げるこ とが可能 – ただし、理論的にはwaitが発生するだけパフォーマンスは落ちる わりとバリバリに落ちる ロックが不要な部分では利用すべきではない たとえば、Anomalyを排除できるのであればロックは実質的には不要 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 53
55.
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の中間になる。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 54
56.
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で排除できないものもある。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 55
57.
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から見ることは可能になる。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 56
58.
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の分類に加えることができ ます。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 57
59.
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時にも満たし ている必要があります。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 58
60.
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 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 59
61.
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 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 60
62.
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レベルは直交するということです。・・ ・まーなんというか。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 61
63.
では(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がアレだという話も当然ある。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 62
64.
そひて、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されるということがなくはないw この辺は利他ロック使うとかいろいろ手はあると思う。 – http://dl.acm.org/citation.cfm?id=174638.174639 まー、いろいろ議論はありますが、MVCC最強伝説の流れという風につ ながっているのは間違いないですね。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 63
65.
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は?という問題 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 64
66.
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 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 65
67.
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..) Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 66
68.
個人的なまとめ・・今後につながること
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 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 67
69.
個人的なまとめ・・今後につながること
特に”r-w”は非常に重要 – Snapshot Isolationは、すでに広く実装されてきているが非常に重要な手 段。 – Snapshot Isolationを応用するときには、そもそも何が問題だったのか? ということを抑えておくことが大切。 今後の主流になる分散・並列処理ではserializableは大切な概念 – 分散環境ではまた違った文脈にはなる – とはいえ、基本はここから 以上。 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 68
Baixar agora