ぱと隊長日誌

ブログ運用もエンジニアとしての生き方も模索中

SerializabilityとMonotonicityとRigorousnessの関係

概要

motononeなスケジュールのクラスでは、スケジュールから任意のトランザクションが消失してもスケジュールのクラスが変わりません。CSRはmonotoneです。

CSRだけではabortを扱うのが難しいため、ロックによる手法を組み合わせます。SS2PLによって作られるスケジュールはCSRかつRigorousnessを満たします。

用語

VSR : View Serializable, ビュー直列可能
CSR : Conflict Serializable, 競合直列可能
詳細は以下の記事を参照ください。
Serializablitiyとは? 2. View Serializabilityについて - Qiita
Serializablitiyとは? 3. Conflict Serializabilityについて - Qiita

RC : Recoverability, 回復可能性
ST : Strictness
RG : Rigorousness
詳細は以下の資料を参照ください。
トランザクションの並行実行制御 rev.2
もしこの資料を難しく感じたら、まずは以下の資料を読んでみてください。
Two Phase Lock - Qiita
S2PLと永続化 - Qiita
http://db.ss.is.nagoya-u.ac.jp/~ishikawa/lectures/db16/12.pdf

SS2PL : Strong Strict Two Phase Lock
詳細は以下の資料を参照ください。
Two Phase Lock - Qiita
トランザクションの並行実行制御 rev.2

スケジュールのクラス (class of schedules) :
スケジュールのクラスとはVSR/CSR等といったものを指します。「クラス(class)」を「分類」と訳すとイメージしやすいかもしれません。

history : scheduleと同義
以下のスライドの13ページの用語解説でhistoryとscheduleは同列に並べて解説されています。
トランザクションの並行実行制御 rev.2

monotoneの定義

以下の資料を参考に説明します。
http://www.dis.uniroma1.it/~rosati/gd/1-concurrency.pdf
"Monotone classes of schedules"の章です。

t : トランザクション。後に続く数字はトランザクションの番号。
w/r/c/a : write/read/commit/abort。後に続く数字はトランザクションの番号。
S : スケジュール。()内は操作対象。
Tran(S) : Sのトランザクションのセット。
ΠT(S) : T⊆Tran(S)とし、SからTに含まれないトランザクションを削除したスケジュール。

T⊆Tran(S)とはTはTran(S)の部分集合ということです。つまり、Tran(S)={t1,t2,t3}, T={t1,t2}のような関係です。

ΠT(S)の例を資料から引用します。
S = w1(x) r2(x) w2(y) r1(y) r3(x) w1(y) w3(x) w3(y) c1 a2
T={t1,t2}
ΠT(S) = w1(x) r2(x) w2(y) r1(y) w1(y) c1 a2
Tにはt3が含まれていないため、ΠT(S)はSからt3の操作を削除しています。

スケジュールのクラスEが「全てのT⊆Tran(S)においてΠT(S)がEである」ときにEはmonotoneと呼ばれます。つまり、monotoneなスケジュールのクラスは任意のトランザクションが消失してもスケジュールのクラスが変わらない、ということになります。

"Transactional Information Systems"では以下の説明をしています。率直に申し上げますと、私にはうまく解釈(理解)できなかったのでそのまま引用します。もし理解の手助けとなる資料をご存知の方がいらっしゃいましたら、ぜひご教示ください。

Monotonicity of a history class E is a desirable property, since it preserves E under arbitrary projections. Taken the other way around, if a projection of some history s does not belong to a given class E in a dynamic scheduling situation, then it does not make sense to process s any further (or to extend it with additional operations).

Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery (The Morgan Kaufmann Series in Data Management Systems)

Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery (The Morgan Kaufmann Series in Data Management Systems)

VSRはmonotoneではない

以下のスケジュールを検討します。
S = w1(x) w2(x) w2(y) w1(y) w3(x) w3(y)
まず、これがVSRであることをエルブランセマンティクスで確認します。

S = w1(x) w2(x) w2(y) w1(y) w3(x) w3(y)
Tx1_1 = F1()
Tx2_1 = F2()
Tx2_2 = F2()
Tx1_2 = F1()
Tx3_1 = F3()
Tx3_2 = F3()
x = F3()
y = F3()

次にシリアルなスケジュールS'のエルブランセマンティクスを確認します。
S' = w1(x) w1(y) w2(x) w2(y) w3(x) w3(y)
Tx1_1 = F1()
Tx1_2 = F1()
Tx2_1 = F2()
Tx2_2 = F2()
Tx3_1 = F3()
Tx3_2 = F3()
x = F3()
y = F3()

SとS'のエルブランセマンティクスが一致するため、SはVSRといえます。

ここでSとS'からt3を削除したスケジュールを考えます。

Π{t1,t2}(S) = w1(x) w2(x) w2(y) w1(y)
Tx1_1 = F1()
Tx2_1 = F2()
Tx2_2 = F2()
Tx1_2 = F1()
x = F2()
y = F1()

Π{t1,t2}(S') = w1(x) w1(y) w2(x) w2(y)
Tx1_1 = F1()
Tx1_2 = F1()
Tx2_1 = F2()
Tx2_2 = F2()
x = F2()
y = F2()

この場合、エルブランセマンティクスが一致しないため、Sからt3を削除したスケジュールはVSRではありません。
また、任意のトランザクション(ここではt3)を削除することでスケジュールのクラス(VSRに該当する⇒該当しない)が変わりました。これはmonotoneなクラスの定義に反しており、VSRはmonotoneではないといえます。

CSRはmonotoneである

CSRはmonotoneです。これを証明もしくは説明する資料が見つからなかったため、ここで直感的な説明を試みます。

S = r1(x) r1(y) r2(x) r2(z) w1(y) r3(y) r3(z) w3(y) w2(x) w2(z)
このときの先行グラフ(precedence graph)は下図となります。
f:id:pato_taityo:20171210124106p:plain
この先行グラフにはサイクルがないため、CSRといえます。

この先行グラフからトランザクションのいずれかを削除しても、サイクルが現れることはありません。つまり、任意のトランザクションを削除してもCSRなままといえます。これからCSRはmonotoneといえます。

monotoneとアボートの関係

monotoneとアボートについて以下の説明をした記事があります。

Monotoneとは「スケジュールから任意のトランザクションが消失してもスケジュールのクラスが変わらない特性」であり、アボートや永続化を考える上で重要である
※括弧閉じを追記しています

Serializablitiyとは? 3. Conflict Serializabilityについて - Qiita

これに関して詳細を説明する資料を探したのですが、見つけることができませんでした。そこで私なりにアボートの場合の観点から考察してみます。

まず、serializabilityの観点から考察します。
monotoneなスケジュールの任意のトランザクションが消失してもスケジュールのクラスが変わらない、ということはCSRのスケジュールで一部のトランザクションがアボートしてもCSRのままであるといえます。つまり、トランザクションがアボートした後も同じクラス(例えばCSR)であるかを検証する必要がないといえます。

次に、RC/ST/RGの観点から考察します。
CSRとRC/ST/RGは直交しています。また、RC⊃ST⊃RGの関係にあります。
詳しくは以下のスライドの26ページの図を参照ください。
トランザクションの並行実行制御 rev.2
monotoneであるCSRでRC/ST/RGと直交していることから、monotoneということだけではRC/ST/RGを保証することができないとわかります。このままだとabortを扱うのが難しくなります。

serializabilityを満たしながらabortを扱うために、スケジューリングだけでなくロックも組み合わせます。SS2PLによって作られるスケジュールはCSRかつRGを満たすことができます。

PostgreSQLマニュアルの「リピータブルリード分離レベル」における「制御レコード」とはなにか?

PostgreSQL(9.1以降)マニュアルの「13.2.2. リピータブルリード分離レベル」に以下の記述があります。

リピータブルリードモードでは、全てのトランザクションがデータベースの一貫した不変のビューの状態を参照することが保証されます。 しかし、このビューは常にいくつかの同じレベルの同時実行トランザクションの直列(一度に一つずつの)実行と一貫性を持つとは限りません。 例えば、このレベルの読み取りのみのトランザクションは、バッチが完了したことを示すために更新された制御レコードを参照することができますが、 制御レコードのより以前のバージョンを読み取るため、論理的にそのバッチの一部となる詳細なレコードの1つを参照することはできません。 この分離レベルで実行するトランザクションによりビジネスルールを強制しようとすることは、競合するトランザクションをブロックするために注意深く明示的なロックを持たないと、正確に動作しないことが多くあります。

13.2. トランザクションの分離

説明に「制御レコード」とありますが、その意味をこの記述から理解することは困難です。実際、PostgreSQLのMLにも同様の質問が寄せられており、その回答を以下のリンクで見ることができます。
Re: Confused by example in 13.2.2

回答ではドキュメントを理解するため、PostgreSQLWikiを紹介しています。
SSI - PostgreSQL wiki

この例では銀行の小切手処理を例に挙げています。ここではcontrolテーブルのdeposit_no列で処理対象のバッチ(小切手の集合)を制御しています。例えば、4/1に受領した小切手はdeposit_noは1、4/2なら2、といった具合です。受領した小切手の詳細はこのdeposit_noの値と共にreceiptテーブルに格納します。

Wikiの記載をベースに問題となるケースを説明します。

  1. 4/1の営業終了時刻間際に銀行の担当者が小切手の処理を行いました。トランザクションT1にてdeposit_no=1で小切手の情報をreceiptテーブルにinsertします。ですが、処理が遅れたため、この時点ではまだcommitしていません。
  2. 銀行の上役が営業終了時刻ちょうどに小切手の締め処理を行いました。これにより、トランザクションT2でdeposit_noは1→2へインクリメントされました。
  3. 小切手の締め処理が行われたことで、後続の小切手一覧出力処理が行われます。トランザクションT3でdeposit_no=1の小切手一覧を出力しますが、T1はcommitしていないため、この一覧に含まれません。
  4. ようやくT1がcommitされました。

本来期待していたトランザクションの依存関係はT1→T2→T3でした。ですが、T1のcommit前にT2, T3が行われたことで、T3→T1の依存が生まれました(この順でなければT3にT1の結果が含まれないことを説明できない)。となると、T1→T2→T3→T1という矛盾した依存が発生します。
また、一見すると奇妙なことですが、T1のcommit前にT3の Read Only なトランザクションが発生しなければ、上記の矛盾は生じません。この場合、期待していた結果通りとなります。

これは"Read Only Anomaly"と呼ばれているものです。以下の解説記事が分かりやすいです。
いろんなAnomaly - Qiita

冒頭のPostgreSQLマニュアルで「制御レコード」とはWikiの例でいえばcontrolテーブルのレコードであり、「詳細なレコード」とはreceiptテーブルのレコードのことになります。

NTTDATATC2017「本当は恐ろしい分散システムの話」聴講メモ

前書き

NTTデータ テクノロジーカンファレンス 2017 (NTTデータ テクノロジーカンファレンス2017 デジタルトランスフォーメーション成功のカギ~ Hadoop, Spark, ブロックチェーン | NTTデータのHadoopソリューション)
【テクノロジー】本当は恐ろしい分散システムの話
の聴講メモです。

スピーカーはNTT ソフトウェアイノベーションセンタの熊崎さん(@)です。

メモは口頭説明を中心にまとめています。私の理解不足でメモの内容に間違いが混入しないよう確認を行いましたが、おかしな箇所がありましたらご指摘ください。
念のため、Twitterのつぶやきを参考にした内容チェックも行いました。
#NTTDATATC since:2017-10-30 until:2017-10-31 - Twitter Search

【参考】としている個所は私が挿入しています(補足や参考資料など)。登壇者の講演内容ではありませんので、その旨ご了承ください。

聴講メモ

BIG DATA LANDSCAPE 2017

このような資料は「カオスマップ」と呼ばれている。

【参考】

スライド内に記載の引用元リンクはこちらです。
http://mattturck.com/bigdata2017/

壊れにくいハードウェアを使えば良いのか?

壊れにくいハードウェアを使っていても、台数が多ければ壊れる。

CAP定理

CAPは定理と言い切っているが、証明できていないのはいかがなものか。

【参考】

2002年にMITのSeth Gilbertとナンシー・リンチがブリュワーの予想の厳密な証明を提出し、定理として確立した。

CAP定理 - Wikipedia

とあり、CAP定理は証明されているようです。

ここで熊崎さんが述べたかったのは、「"3つのうち2つ"という公式はミスリーディング」ということだったと思われます。
詳細は以下の記事を参照ください。
12年後のCAP定理: "法則"はどのように変わったか

Jepsen Test

【参考】

テストの名前の由来について熊崎さんの解説があったのですが、ほとんどメモできなかったので調べてみました。

スライドの画像の引用元リンクです。
Jepsen: On the perils of network partitions
この画像は Carly Rae Jepsen の "Call Me Maybe" のPV映像に歌詞をもじって重ねています。

テストの名前はこの歌手の名前から付けたようです。

なお、この曲のPVをYouTubeで見ることができます。きっと一度は耳にしたことがあるはず。

Partitionさせてみる

この実験の結果より、Redisはパーティションで作った分断に弱いということが言える。

ここまでのまとめ

異常系のテストは難しいし、正しく網羅的にできていないことが多い。

Fault Injection Testとは?

システムは複数のレイヤーで構成されている。そのレイヤーを攻撃するのが Jepsen Test だ。

HDDもSDDも壊れる!

ニアラインディスクはデータのバックアップ用。

【参考】
ニアラインディスクの詳細は以下の記事を参照ください。
ニアラインディスクの利用用途は | Tintri

実験設定

ディスク内のデータが少し化けただけでダメージを受けるシステムは多い。

「一度に化ける/壊れるエラーは一か所だけ」とは3多重であればその内の1つだけが壊れるということ。これをRedisでテストしてみた。

他のシステムたち

Cassandra は last-write-win で最後に書いたものが勝つ、という障害対応を行っている。だが、最後に書いたデータが化けていると悲惨なことになる(化けデータが伝搬する)。

その猿、凶暴につき

Netflixは障害系のテストのために本番で障害を起こす。

Chaos Kong はAWSのリージョンを丸ごと落とす。この場合は何日に実施するかを予告されている。避難訓練のようなもの。

NetflixのChaos Engineering

部署のレベルでフォールバックの仕組みを作っている。

カナリア分析のメトリクスの例としてはCPUやメモリなどがある。

サルと和解せよ

Chaos Engineeringの導入には、まず何が正しいかを定義し、段階を追って準備を進める。

所感

以下のtweetにまとめました。

このような素晴らしい資料を公開していただけたことに感謝いたします。