Slide 1
Slide 1 text
2021/07/16
Cloud Native Database Meetup #1
分散トランザクション
in CockroachDB
\ ｺﾝﾆﾁﾜ /
#CloudNativeDB
Slide 2
Slide 2 text
● Name: Takanori Yokoyama
○ @kota2and3kan (Twitter, GitHub)
● Job: Technical Support
● Like: DB
○ PostgreSQL, CockroachDB
● Dislike: Real Cockroach @kota2and3kan
こたつ&&みかん
Who am I.
Slide 3
Slide 3 text
※Note※
ちょっと自信が無いとこもあります！
間違ってたらごめんさない！！！
\ ﾕﾙｼﾃ /
Slide 4
Slide 4 text
目次
● 超概要
● 課題
● COMMIT / ABORT (Write) の動作
● Read の動作
● Parallel Commits
● Timestamp を使った Tx の制御
● 宣伝
● まとめ
Slide 5
Slide 5 text
超概要
\ ｶﾞｲﾖｳ /
Slide 6
Slide 6 text
CockroachDB is ...
分散 SQL データベース (RDBMS)
\ ﾌﾞﾝｻﾝ /
Slide 7
Slide 7 text
Node 1 Node 3
クラスタ構成 (3匹の場合)
Node 2
● 分散 DB なので、複数
Node で構成されたクラ
スタで動作する。
論理的に 1つの DB
Slide 8
Slide 8 text
分散 DB なので...
● データは分散して格納される。
● 全ての Node で Tx を実行可能。
\ ﾎﾟｲﾝﾄ /
Slide 9
Slide 9 text
分散 DB なので...
● データは分散して格納される。
● 全ての Node で Tx を実行可能。
\ ﾎﾟｲﾝﾄ /
Slide 10
Slide 10 text
データの格納
● RDBMS なのでユーザか
らは TABLE に見える。
Slide 11
Slide 11 text
データの格納
● RDBMS なのでユーザか
らは TABLE に見える。
● TABLE は Key-Value 形
式に変換される。
Slide 12
Slide 12 text
データの格納
● RDBMS なのでユーザか
らは TABLE に見える。
● TABLE は Key-Value 形
式に変換される。
● Key-Value は 512MB に
分割される (Range)。
Range
Range
Range
Slide 13
Slide 13 text
データの格納
● RDBMS なのでユーザか
らは TABLE に見える。
● TABLE は Key-Value 形
式に変換される。
● Key-Value は 512MB に
分割される (Range)。
● 各 Range を分散して 各
Node に格納する。
k1 ~ k10
k10 ~ k20
k20 ~ k30
Range
Range
Range
Slide 14
Slide 14 text
データの格納
● RDBMS なのでユーザか
らは TABLE に見える。
● TABLE は Key-Value 形
式に変換される。
● Key-Value は 512MB に
分割される (Range)。
● 各 Range を分散して 各
Node に格納する。
● Raft を使って Replica も
作成される (デフォルト 3
つ)。
k1 ~ k10 Replica Replica
k10 ~ k20
Replica Replica
k20 ~ k30
Replica
Replica
Range
Range
Range
Raft Group 1
Raft Group 2
Raft Group 3
Slide 15
Slide 15 text
5匹に増えた場合
● いい感じにスケールアウ
トすることも可能。
● スケールした場合、デー
タは自動でいい感じに分
散される。
● スケールインすることも可
能。
k1 ~ k10 Replica Replica
k10 ~ k20
Replica Replica
k20 ~ k30
Replica
Replica
Slide 16
Slide 16 text
分散 DB なので...
● データは分散して格納される。
● 全ての Node で Tx を実行可能。
\ ﾎﾟｲﾝﾄ /
Slide 17
Slide 17 text
Node の役割 (全ての Node が Coordinator)
k1 ~ k10 Replica Replica
k10 ~ k20
Replica Replica
k20 ~ k30
Replica
Replica
Tx1: Write
(k15, v1)
Tx2: Read
(k3)
Tx3: Write
(k28, v2)
Tx4: Read
(k5)
Tx5: Write
(k12, v3)
● クラスタ内の Node 間に
役割の差異はない。
● 全ての Node が
Coordinator として動作
することが可能。
● つまり、全ての Node で
Read / Write の Tx を処
理可能。
Slide 18
Slide 18 text
Node の役割 (全ての Node が Coordinator)
k1 ~ k10 Replica Replica
k10 ~ k20
Replica Replica
k20 ~ k30
Replica
Replica
Tx1: Write
(k15, v1)
Tx3: Write
(k28, v2)
● CockroachDB では、
Coordinator Node のこと
を Gateway Node と呼
ぶ。
● Gateway Node は、処理
対象の key を持っている
Node に、クエリをルー
ティングする。
Slide 19
Slide 19 text
[再掲] 分散 DB なので...
● データは分散して格納される。
● 全ての Node で Tx を実行可能。
\ ｺｺ ﾃｽﾄﾆ ﾃﾞﾙﾖ /
Slide 20
Slide 20 text
課題
\ ｶﾀﾞｲ /
Slide 21
Slide 21 text
データが分散された状態で...
● Atomicity (原子性) を満たす必要がある。
● 他の Tx の状態を判断する必要がある。
● Tx の順番を判断する必要がある。
\ ﾎﾟｲﾝﾄ /
Slide 22
Slide 22 text
データが分散された状態で...
● Atomicity (原子性) を満たす必要がある。
● 他の Tx の状態を判断する必要がある。
● Tx の順番を判断する必要がある。
\ ﾎﾟｲﾝﾄ /
Slide 23
Slide 23 text
課題 1 : Atomicity を満たす
k1 ~ k10 Replica Replica
k10 ~ k20
Replica Replica
k20 ~ k30
Replica
Replica
Tx:
Write (k1 , v1)
Write (k10, v2)
Write (k20, v3)
● Tx 内の複数 Write は、
全て COMMIT される
か、全て ABORT される
か、のどちらかである必
要がある。
● 中途半端な状態は許され
ない。
● つまり、Atomicity (All or
Nothing) を満たす必要
がある。
Slide 24
Slide 24 text
データが分散された状態で...
● Atomicity (原子性) を満たす必要がある。
● 他の Tx の状態を判断する必要がある。
● Tx の順番を判断する必要がある。
\ ﾎﾟｲﾝﾄ /
Slide 25
Slide 25 text
課題 2 : Tx の状態を判断
k1 ~ k10 Replica Replica
k10 ~ k20
Replica Replica
k20 ~ k30
Replica
Replica
● ある Tx (Tx1) が k15 を
Write する。
● 他の Tx (Tx2) が k15 を
Read する。
● この時、Tx2 は Tx1 が
COMMIT した / ABORT
した / 処理の途中 (未確
定)、のどれであるかを判
断する必要がある。
Tx1: Write
(k15, v1)
Tx2: Read
(k15)
\ ｲｿｶﾞｼｲ /
Slide 26
Slide 26 text
データが分散された状態で...
● Atomicity (原子性) を満たす必要がある。
● 他の Tx の状態を判断する必要がある。
● Tx の順番を判断する必要がある。
\ ﾎﾟｲﾝﾄ /
Slide 27
Slide 27 text
課題 3 : Tx の順番を判断
k1 ~ k10 Replica Replica
k10 ~ k20
Replica Replica
k20 ~ k30
Replica
Replica
● 実際には複数の Tx が複
数の Node で同時に実
行される。
● この時、各 Tx の実行順
序を判断する必要があ
る。
● e.g.
a) Tx1 -> Tx2 -> Tx3
b) Tx2 -> Tx3 -> Tx1
c) Tx3 -> Tx1 -> Tx2
etc...
Tx1:
Write (k15, v1)
Write (k3, v2)
Tx2:
Write (k3, v3)
Write (k25, v4)
Tx3:
Read (k15)
Read (k25)
Slide 28
Slide 28 text
[再掲] データが分散された状態で...
● Atomicity (原子性) を満たす必要がある。
● 他の Tx の状態を判断する必要がある。
● Tx の順番を判断する必要がある。
\ ｺｺﾓ ﾃｽﾄﾆ ﾃﾞﾙﾖ /
Slide 29
Slide 29 text
課題を解決するために...
\ ﾋﾂﾖｳ /
分散トランザクションが必要
Slide 30
Slide 30 text
COMMIT / ABORT (Write) の動作
\ ｺﾐｯﾄ /
Slide 31
Slide 31 text
用語概要
● Transaction Record
○ https://github.com/cockroachdb/cockroach/blob/v20.2.5/pkg/roachpb/data.pb.go#L940
● Write Intent
○ https://github.com/cockroachdb/cockroach/blob/v20.2.5/pkg/roachpb/data.pb.go#L985
○ https://github.com/cockroachdb/cockroach/blob/v20.2.5/pkg/storage/enginepb/mvcc3.pb.go#L
31
● Transaction Liveness Threshold
○ https://github.com/cockroachdb/cockroach/blob/v20.2.5/pkg/kv/kvserver/txnwait/queue.go#L46
Slide 32
Slide 32 text
用語概要 (Transaction Record)
● Transaction の状態を管理する。
● Tx 内で最初に Write された key と同じ Range に書き込まれる。
● 以下の State がある。
○ PENDING
■ Tx は処理中。
○ COMMITTED
■ Tx は COMMIT 済み。
○ STAGING
■ Tx は Parallel Commits で処理中。
○ ABORTED
■ Tx は ABORT 済み。
○ (MISSING)
■ Transaction Record そのものが無い。
Slide 33
Slide 33 text
用語概要 (Write Intent)
● Transaction の状態 (COMMIT / ABORT) が確定していないレコード (KV)
に付けられる印。
● 以下のような情報を持っている。
○ 関連する (当該レコードを Write した) Tx の ID。
○ Write Intent が書き込まれた時間。
Slide 34
Slide 34 text
用語概要 (Transaction Liveness Threshold)
● Transaction の生死 (Tx を管理している Node の生死) を判断するための
閾値 (死んだと判断するまでの時間)。
○ Gateway Node での障害発生有無を確認する場合等に使われる。
○ 文字通り、そのまんまの感じのやつ。
Slide 35
Slide 35 text
COMMIT の仕組み
Range : Set of KV date (512BM)
Tx1 (timestamp t1)
BEGIN;
Write (key1, x1);
COMMIT;
key1 (t0): x0
key2 (t0): y0
key3 (t0): z0
Slide 36
Slide 36 text
Tx 開始
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
COMMIT;
key1 (t0): x0
key2 (t0): y0
key3 (t0): z0
Slide 37
Slide 37 text
key1 を更新
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
COMMIT;
Write (UPDATE) は Inplace
Update ではなく、新しい
Timestamp で追記する。
この時 COMMIT / ABORT が
確定していない KV には “write
intent” という印が付 けられる。
key1 (t0): x0
key2 (t0): y0
key3 (t0): z0
key1 (t1): x1 (intent:Tx1)
Slide 38
Slide 38 text
Transaction Record (PENDING) を作成
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
COMMIT;
Tx の状態を管理するための
”Transaction Record” が他の
KV データ同様に書き込まれる。
各 “write intent” は、対応する
Transaction Record を特定する
情報 (Tx の ID) を持っている。
key1 (t0): x0
key2 (t0): y0
key3 (t0): z0
key1 (t1): x1 (intent:Tx1)
Tx1’s “Transaction Record”
------------------------------------
State: PENDING
Slide 39
Slide 39 text
Transaction Record の State を COMMIT に更新
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
COMMIT;
COMMIT を実行すると、
Transaction Record の値が
COMMITTED に変更される。
このタイミングで、クライアントに
COMMIT 完了を返す。
key1 (t0): x0
key2 (t0): y0
key3 (t0): z0
key1 (t1): x1 (intent:Tx1)
Tx1’s “Transaction Record”
------------------------------------
State: COMMITTED
Slide 40
Slide 40 text
“write intent” を削除 (COMMIT とは非同期で実施)
Range : Set of KV date (512BM)
BEGIN;
Write (key1, x1);
COMMIT;
key1 (t0): x0
key2 (t0): y0
key3 (t0): z0
key1 (t1): x1
Tx1’s “Transaction Record”
------------------------------------
State: COMMITTED
COMMIT 完了後、非同期で
“write intent” が削除され、通常
の KV と同じ状態になる。
Slide 41
Slide 41 text
Tx Record を削除 (COMMIT とは非同期で実施)
Range : Set of KV date (512BM)
BEGIN;
Write (key1, x1);
COMMIT;
key1 (t0): x0
key2 (t0): y0
key3 (t0): z0
key1 (t1): x1
Tx1’s “Transaction Record”
------------------------------------
State: COMMITTED
Tx に関連する全ての “write
intent” が削除された後、
Transaction Record が非同期
で削除される。
Slide 42
Slide 42 text
ABORT の仕組み
Range : Set of KV date (512BM)
Tx1 (timestamp t1)
BEGIN;
Write (key1, x1);
ABORT;
key1 (t0): x0
key2 (t0): y0
key3 (t0): z0
Slide 43
Slide 43 text
Tx 開始
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
ABORT;
key1 (t0): x0
key2 (t0): y0
key3 (t0): z0
Slide 44
Slide 44 text
key1 を更新
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
ABORT;
Write (UPDATE) は Inplace
Update ではなく、新しい
Timestamp で追記する。
この時 COMMIT / ABORT が
確定していない KV には “write
intent” という印が付 けられる。
key1 (t0): x0
key2 (t0): y0
key3 (t0): z0
key1 (t1): x1 (intent:Tx1)
Slide 45
Slide 45 text
Transaction Record (PENDING) を作成
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
ABORT;
Tx の状態を管理するための
”Transaction Record” が他の
KV データ同様に書き込まれる。
各 “write intent” は、対応する
Transaction Record を特定する
情報 (Tx の ID) を持っている。
key1 (t0): x0
key2 (t0): y0
key3 (t0): z0
key1 (t1): x1 (intent:Tx1)
Tx1’s “Transaction Record”
------------------------------------
State: PENDING
Slide 46
Slide 46 text
Transaction Record の State を ABORT に更新
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
ABORT;
ABORT を実行すると、
Transaction Record の値が
ABORTED に変更される。
key1 (t0): x0
key2 (t0): y0
key3 (t0): z0
key1 (t1): x1 (intent:Tx1)
Tx1’s “Transaction Record”
------------------------------------
State: ABORTED
Slide 47
Slide 47 text
“write intent” を削除 (ABORT とは非同期で実施)
Range : Set of KV date (512BM)
BEGIN;
Write (key1, x1);
ABORT;
key1 (t0): x0
key2 (t0): y0
key3 (t0): z0
key1 (t1): x1 (intent:Tx1)
Tx1’s “Transaction Record”
------------------------------------
State: ABORTED
ABORT 後、非同期で ABORT
された key が削除される。
Slide 48
Slide 48 text
Tx Record を削除 (ABORT とは非同期で実施)
Range : Set of KV date (512BM)
BEGIN;
Write (key1, x1);
ABORT;
key1 (t0): x0
key2 (t0): y0
key3 (t0): z0
Tx1’s “Transaction Record”
------------------------------------
State: ABORTED
Tx に関連する全ての key が削
除された後、Transaction
Record が非同期で削除される。
Slide 49
Slide 49 text
Read の動作
\ ﾘｰﾄﾞ /
Slide 50
Slide 50 text
Read Tx はどの値を読み込むのか？
Range : Set of KV date (512BM)
Tx1 (timestamp t1)
BEGIN;
Write (key1, x1);
COMMIT / ABORT;
Tx2 (timestamp t2)
Read (key1);
key1 (t0): x0
Slide 51
Slide 51 text
Read Tx は Timestamp を見て読み込む値を決める
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
Tx1’s “Transaction Record”
------------------------------------
State: PENDING
Tx2 (t2)
Read (key1); -> x0
t0 < t2 < t1 だった場合は、t0 の値 (x0) を
読む。
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
Slide 52
Slide 52 text
Read Tx は Timestamp を見て読み込む値を決める
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
Tx1’s “Transaction Record”
------------------------------------
State: PENDING
Tx2 (t2)
Read (key1);
-> x1 (intent:Tx1)
t0 < t1 < t2 だった場合は、t1 の値 (x1) を
読む。(x1 は “write intent” なのでこの時
点で COMMIT / ABORT は不明)
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
Slide 53
Slide 53 text
Read した値が “write intent” だった場合
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
Tx1’s “Transaction Record”
------------------------------------
State: PENDING
Read した値が “write intent” だった場合、
Tx Record の値を確認する。
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
Tx2 (t2)
Read (key1);
-> x1 (intent:Tx1)
Slide 54
Slide 54 text
Read した値が “write intent” だった場合 (COMMIT)
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
COMMIT;
Tx1’s “Transaction Record”
------------------------------------
State: COMMITTED
Tx Record の値が COMMITTED だった
場合は COMMIT 済みなので、そのまま
x1 を Read する。
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
Tx2 (t2)
Read (key1); -> x1
Slide 55
Slide 55 text
Read した値が “write intent” だった場合 (ABORT)
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
ABORT;
Tx1’s “Transaction Record”
------------------------------------
State: ABORTED
Tx Record の値が ABORTED だった場合
は Tx1 の更新が無かったことになるので、
x0 を Read する。
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
Tx2 (t2)
Read (key1); -> x0
Slide 56
Slide 56 text
Read した値が “write intent” だった場合 (PENDING)
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
…
...
Tx1’s “Transaction Record”
------------------------------------
State: PENDING
Tx Record の値が PENDING だった場合
は状態 (COMMIT / ABORT) が確定して
いないので、Tx1 の完了を待つ。
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
Tx2 (t2)
Read (key1);
-> wait...
Slide 57
Slide 57 text
Read した値が “write intent” だった場合 (MISSING)
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
特定のタイミング (Tx 処理中) や Gateway
Node の障害等に起因して、Tx Record が
存在しない場合もある。
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
Tx2 (t2)
Read (key1);
-> ???
Tx1’s “Transaction Record”
------------------------------------
MISSING
Slide 58
Slide 58 text
Read した値が “write intent” だった場合 (MISSING)
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
Tx Record が無い場合は “write intent” の
Timestamp が “Transaction Liveness
Threshold” の範囲内か否かをチェックす
る。
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
Tx2 (t2)
Read (key1);
-> ???
無い...？
Tx1’s “Transaction Record”
------------------------------------
MISSING
Slide 59
Slide 59 text
Read の動作
補足 (Transaction Liveness Threshold)
\ ﾀﾞｯｾﾝｽﾙﾖ /
Slide 60
Slide 60 text
補足 (Transaction Liveness Threshold)
Node 1
Tx1 (t1)
BEGIN;
Write (key1, x1);
…
Range : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: PENDING
key1 (t0): x0
key1 (t1): x1 (intent:Tx1)
SQL を受け取った Gateway Node (いわゆるコーディネーター) が
Tx を管理している。
Manage
Create
Write
\ ｶﾝﾘ /
Slide 61
Slide 61 text
補足 (Transaction Liveness Threshold)
Node 1
Tx1 (t1)
BEGIN;
Write (key1, x1);
…
Range : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: PENDING
key1 (t0): x0
key1 (t1): x1 (intent:Tx1)
Tx1 の途中で Node 障害が発生すると、その Node が管理していた
Tx1 は ABORT することになるが、Range の中に Transaction
Record が PENDING のまま残ってしまう。
~
Slide 62
Slide 62 text
補足 (Transaction Liveness Threshold)
Node 1 Range : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: PENDING
key1 (t0): x0
key1 (t1): x1 (intent:Tx1)
Range の中に Transaction Record が PENDING のまま残ってい
ると、他の Tx2 が Tx1 の状態を判断できず、いつまでも Tx1 の状
態が確定 (COMMIT or ABORT) するのを待ってしまう。
Tx2 (t2)
Read (key1);
-> wait...
Wait forever...
Read
\ ﾏﾀﾞｰ? /
Node 2
Slide 63
Slide 63 text
補足 (Transaction Liveness Threshold)
Node 1
TxnCoordSender
Tx1 (t1)
BEGIN;
Write (key1, x1);
…
Range : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: PENDING
key1 (t0): x0
key1 (t1): x1 (intent:Tx1)
Transaction Record の残存を防ぐため Gateway Node 内の
TxnCoordSender が Transaction Record に対して定期的に
Heartbeat を実施している。多分デフォルト 1秒間隔。
https://github.com/cockroachdb/cockroach/blob/v20.2.5/pkg/base/constants.go#L27
Heartbeat
\ ｲｷﾃﾙﾖ /
Slide 64
Slide 64 text
補足 (Transaction Liveness Threshold)
Node 1
TxnCoordSender
Tx1 (t1)
BEGIN;
Write (key1, x1);
…
Range : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
Tx1 is expired!
Heartbeat が一定時間途絶えた場合、Tx (Node) が死んでいると判
断できる。この Tx の生死を判断する閾値が “Transaction Liveness
Threshold”。多分デフォルト 5秒。
https://github.com/cockroachdb/cockroach/blob/v20.2.5/pkg/kv/kvserver/txnwait/queue.go#L46
~
Heartbeat
key1 (t0): x0
key1 (t1): x1 (intent:Tx1)
Slide 65
Slide 65 text
Node 1
TxnCoordSender
Range : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
Tx1 is expired!
key1 (t0): x0
key1 (t1): x1 (intent:Tx1)
Tx2 (t2)
Read (key1);
-> x1 (intent:Tx1)
2. Check
1. Read
\ ｲｯﾀｶ... /
Heartbeat
補足 (Transaction Liveness Threshold)
Tx1 を管理する Node が死んだ場合でも、他の Tx2 が write intent
読み込み Transaction Record を確認した際に、正しく「死んだ」と判
断できる。
Node 2
Slide 66
Slide 66 text
Node 1
TxnCoordSender
Range : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: ABORTED
key1 (t0): x0
key1 (t1): x1 (intent:Tx1)
Tx2 (t2)
Read (key1);
-> x0
ABORT
Read
\ ｻﾗﾊﾞﾀﾞ... /
Heartbeat
補足 (Transaction Liveness Threshold)
Tx1 が「死んだ」と判断された場合、それを見つけた Tx2 を管理する
Node 2 が Tx1 の Transaction Record の値を ABORTED に更新
し、Tx2 は 1つ前の値 x0 を Read する (t0 < t1 < t2 の場合)。
Node 2
Slide 67
Slide 67 text
Read の動作
補足 (Transaction Record が作成される条件)
\ ｻﾗﾆﾀﾞｯｾﾝｽﾙﾖ /
Slide 68
Slide 68 text
補足 (Transaction Record が作成される条件)
Node 1
TxnCoordSender
Tx1 (t1)
BEGIN;
Write (key1, x1);
…
Range : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: XXXXXX
key1 (t0): x0
key1 (t1): x1 (intent:Tx1)
1. COMMIT が実行された時。(※詳細は Parallel Commits で)
2. TxnCoordSender が Heartbeat を実行した時。
3. Tx が強制的に ABORT された時。
Create
\ ｼﾞｮｳｹﾝ /
Slide 69
Slide 69 text
補足 (Transaction Record が作成される条件1)
Node 1
Tx1 (t1)
BEGIN;
Write (key1, x1);
COMMIT;
Range : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING
1. COMMIT が実行された時 (STAGING)。
※何故 COMMIT のタイミングなのかについては後述する
Parallel Commits 参照。
When it COMMITs
\ ｺﾐｯﾄ /
key1 (t0): x0
key1 (t1): x1 (intent:Tx1)
Slide 70
Slide 70 text
補足 (Transaction Record が作成される条件2)
Node 1
TxnCoordSender
Tx1 (t1)
BEGIN;
Write (key1, x1);
…
Range : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: PENDING
2. TxnCoordSender が Heartbeat を実行した時。
※Heartbeat は 1秒間隔なので、Tx 内の最初の Write から
1秒経つと Transaction Record が作成される。
When it Heartbeats
\ ｲｷﾃﾙﾖ /
key1 (t0): x0
key1 (t1): x1 (intent:Tx1)
Slide 71
Slide 71 text
Node 1
Tx1 (t1)
BEGIN;
Write (key1, x1);
…
Range : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: PENDING
key1 (t0): x0
key1 (t1): x1 (intent:Tx1)
3. Tx1 が key1 への Write は実行したが Transaction Record は
まだ作成していない状態で障害が発生すると、write intent は
存在するが対応する Transaction Record が無い、という状態
になる。
補足 (Transaction Record が作成される条件3)
~
Write
Not yet...
Slide 72
Slide 72 text
Node 1 Range : Set of KV date (512BM)
key1 (t1): x1 (intent:Tx1)
Node 2
Tx2 (t2)
Read (key1);
-> x1 (intent:Tx1)
2. Check
1. Read
\ ﾅｲ /
3. 他の Tx2 が write intent 読み込んだ際に、対応する
Transaction Record が存在しないことを検知する。
※ただし、この時点で Node 1 が死んでいるか否かは判断でき
ない (単純に Node 1 が処理途中の可能性が有る)。
補足 (Transaction Record が作成される条件3)
key1 (t0): x0
Slide 73
Slide 73 text
Node 1 Range : Set of KV date (512BM)
Node 2 Check Timestamp
\ ｶｸﾆﾝ /
3. Transaction Record が無い場合は、読み込んだ write intent
の Timestamp が Transaction Liveness Threshold 以内か否
かを確認する。
補足 (Transaction Record が作成される条件3)
key1 (t1): x1 (intent:Tx1)
Tx2 (t2)
Read (key1);
-> x1 (intent:Tx1)
key1 (t0): x0
Slide 74
Slide 74 text
Node 1 Range : Set of KV date (512BM)
Node 2 Treat as PENDING
\ ﾏﾂﾜ /
3. write intent の Timestamp t1 が Transaction Liveness
Threshold 以内の場合 PENDING として扱い、待つ。
多分 (Current time - t1) < 5 の場合。
補足 (Transaction Record が作成される条件3)
key1 (t1): x1 (intent:Tx1)
Tx2 (t2)
Read (key1);
-> x1 (intent:Tx1)
key1 (t0): x0
Slide 75
Slide 75 text
Node 1 Range : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: ABORTED
key1 (t0): x0
key1 (t1): x1 (intent:Tx1)
Node 2
Tx2 (t2)
Read (key1);
-> x0
ABORT
Read
\ ｼﾝﾀﾞﾅ /
補足 (Transaction Record が作成される条件3)
3. write intent の Timestamp t1 が Transaction Liveness
Threshold の範囲外 (古い) の場合、Tx1 を ABORT させるた
めに Transaction Record を作成する。
多分 (Current time - t1) > 5 の場合。
Slide 76
Slide 76 text
Read の動作
つづき
\ ﾓﾄﾞｯﾃｷﾀﾖ /
Slide 77
Slide 77 text
Read した値が “write intent” だった場合 (MISSING)
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
Tx1’s “Transaction Record”
------------------------------------
MISSING
Tx Record が無い場合は “write intent” の
Timestamp が “Transaction Liveness
Threshold” の範囲内か否かをチェックす
る。
key1 (t0): x0
key1 (t1): x1 (intent:Tx1)
Tx2 (t2)
Read (key1);
-> ???
無い...？
再掲
Slide 78
Slide 78 text
Read した値が “write intent” だった場合 (MISSING)
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
“write intent” の Timestamp が
“Transaction Liveness Threshold” 以内
の場合、PENDING として扱い、待つ。
key1 (t0): x0
key1 (t1): x1 (intent:Tx1)
Tx2 (t2)
Read (key1);
-> wait...
Tx1’s “Transaction Record”
------------------------------------
MISSING
Slide 79
Slide 79 text
Read した値が “write intent” だった場合 (MISSING)
Range : Set of KV date (512BM)
Tx1 (t1)
BEGIN;
Write (key1, x1);
※Tx1 に「何らかの
問題が発生した」 と
判断される。
key1 (t0): x0
key1 (t1): x1 (intent:Tx1)
Tx2 (t2)
Read (key1);
-> x0
“write intent” の Timestamp が
“Transaction Liveness Threshold” の範
囲外 (古い) の場合、ABORT として処理し
x0 を Read する。
Tx1’s “Transaction Record”
------------------------------------
State: ABORTED
Slide 80
Slide 80 text
Parallel Commits
\ ﾊﾟﾗﾚﾙ /
Slide 81
Slide 81 text
Not Parallel Commits
\ ﾑｶｼ /
初期の頃 (~ v2.0) の実装
Slide 82
Slide 82 text
v2.0 まで
BEGIN;
Write (key1, x1);
Write (key2, y1);
Write (key3, z1);
COMMIT;
Timeline
Tx 内の Statement は順番に
実行される。
Slide 83
Slide 83 text
v2.0 まで
BEGIN;
Write (key1, x1);
Write (key2, y1);
Write (key3, z1);
COMMIT;
Timeline
Write1 実行
Tx Record 作成 (PENDING)
最初の Statement と一緒に
Tx Record も作成される。
Slide 84
Slide 84 text
v2.0 まで
BEGIN;
Write (key1, x1);
Write (key2, y1);
Write (key3, z1);
COMMIT;
Timeline
各 Statement は並列実行でき
ないので、順番に実行される。
Write2 実行
Slide 85
Slide 85 text
v2.0 まで
BEGIN;
Write (key1, x1);
Write (key2, y1);
Write (key3, z1);
COMMIT;
Timeline
各 Statement は並列実行でき
ないので、順番に実行される。
Write3 実行
Slide 86
Slide 86 text
v2.0 まで
BEGIN;
Write (key1, x1);
Write (key2, y1);
Write (key3, z1);
COMMIT;
Timeline
最後に、Tx Record の値を
PENDING -> COMMITTED
に変える処理が実行される。
COMMIT 実行
Tx Record 更新 (COMMIT)
Slide 87
Slide 87 text
v2.0 まで
BEGIN;
Write (key1, x1);
Write (key2, y1);
Write (key3, z1);
COMMIT;
Timeline
Tx 内の Statement は順番に
実行されるので、処理時間は
O(n) になる。
※n = Num of Statements
COMMIT (Tx Record の更新
処理) も入れると O(n+1) にな
る。
Slide 88
Slide 88 text
Not Parallel Commits
\ ﾁｮｯﾄﾏｴ /
ちょっと前 (v2.1 ~ v19.1) までの実装
Slide 89
Slide 89 text
BEGIN;
Write (key1, x1);
Write (key2, y1);
Write (key3, z1);
COMMIT;
Timeline
v2.1 で Pipelining という機能
が実装され、Tx 内の各
Statement は並列で実行され
るようになった。
v2.1 ~ v19.1 まで (Pipelining)
Slide 90
Slide 90 text
v2.1 ~ v19.1 まで (Pipelining)
BEGIN;
Write (key1, x1);
Write (key2, y1);
Write (key3, z1);
COMMIT;
Timeline
Write1 実行
Tx Record 作成 (PENDING)
Write2 実行
Write3 実行
各 Statement を並列で実行。
ただし、全ての Statement の
書き込み完了が返ってくるまで
Tx Record の値を COMMIT
に更新できない。
Slide 91
Slide 91 text
v2.1 ~ v19.1 まで (Pipelining)
BEGIN;
Write (key1, x1);
Write (key2, y1);
Write (key3, z1);
COMMIT;
Timeline
全ての Statement の書き込み
完了が返ってきたら、Tx を
COMMIT する (Tx Record の
値を COMMITTED に更新す
る)。
COMMIT 実行
Tx Record 更新 (COMMIT)
Slide 92
Slide 92 text
v2.1 ~ v19.1 まで (Pipelining)
BEGIN;
Write (key1, x1);
Write (key2, y1);
Write (key3, z1);
COMMIT;
Timeline
Pipelining により各
Statement を並列で実行でき
るようになったので、理論上の
最短処理時間は O(2) になっ
た。
※この O(2) を O(1) にするの
が Parallel Commits。
Slide 93
Slide 93 text
BEGIN;
Write (key1, x1);
Read (key1);
Write (key3, z1);
COMMIT;
Timeline
なお、Statement 間に依存関
係が有る場合は、並列には実
行されず、ちゃんと順番に実行
される仕組みになっている。
v2.1 ~ v19.1 まで (Pipelining : Read-Your-Writes)
Slide 94
Slide 94 text
BEGIN;
Write (key1, x1);
Read (key1);
Write (key3, z1);
COMMIT;
Timeline
Write1 と Write3 は別々の
key に対する Write であり、依
存関係はないので並列実行。
v2.1 ~ v19.1 まで (Pipelining : Read-Your-Writes)
Slide 95
Slide 95 text
BEGIN;
Write (key1, x1);
Read (key1);
Write (key3, z1);
COMMIT;
Timeline
Write1 と Write3 は別々の
key に対する Write であり、依
存関係はないので並列実行。
Read は Write1 が更新した
key1 の値を読む必要が有る
(依存関係が有る) ので、
Write1 完了後に実行される。
v2.1 ~ v19.1 まで (Pipelining : Read-Your-Writes)
Slide 96
Slide 96 text
BEGIN;
Write (key1, x1);
Read (key1);
Write (key3, z1);
COMMIT;
Timeline
Tx 内の Statement 間に依存
関係が有る場合は、必ずしも
O(2) になるわけではない。
※あくまで理論上の最短が
O(2) になる感じ。
※この “理論上の最短” を
O(2) から O(1) にするのが
Parallel Commits。
v2.1 ~ v19.1 まで (Pipelining : Read-Your-Writes)
Slide 97
Slide 97 text
Parallel Commits
\ ｻｲｼﾝ /
最新 (v19.2 ~) の実装
Slide 98
Slide 98 text
Parallel Commits (v19.2 ~)
BEGIN;
Write (key1, x1);
Write (key2, y1);
Write (key3, z1);
COMMIT;
Timeline
Parallel Commits は、
COMMIT の処理 (Tx Record
の作成) も他の Statement と
並列で実行することで、処理時
間の理論上の最短を O(1) に
するもの。
Tx 内で Write する key が全て
確定している必要があり、
Transaction Record は
COMMIT のタイミングで作成
される。
Slide 99
Slide 99 text
Parallel Commits (v19.2 ~)
BEGIN;
Write (key1, x1);
Write (key2, y1);
Write (key3, z1);
COMMIT;
Timeline
書き込み完了前
に COMMIT して
大丈夫か...？
Slide 100
Slide 100 text
Parallel Commits
\ kwsk /
COMMIT (Write) の動作
Slide 101
Slide 101 text
Parallel Commits (Write)
Node 1
Range1 : Set of KV date (512BM)
key1 (t0): x0
Range2 : Set of KV date (512BM)
key2 (t0): y0
\ ｽﾀｰﾄ /
Client
key1, key2 を更新する。
BEGIN;
Write (key1, x1);
Write (key2, y2);
COMMIT;
Slide 102
Slide 102 text
Node 1
Range1 : Set of KV date (512BM)
Range2 : Set of KV date (512BM)
\ ﾘｸｴｽﾄ /
Client
BEGIN;
Write (key1, x1);
Write (key2, y2);
COMMIT;
Write のタイミングではまだ Tx Record は作成しない。
Parallel Commits (Write)
key1 (t0): x0
key2 (t0): y0
key1 (t1): x1 (intent:Tx1)
key2 (t1): y1 (intent:Tx1)
Write
Write
Slide 103
Slide 103 text
Node 1
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING
Keys: key1, key2
Range2 : Set of KV date (512BM)
key1 (t1): x1 (intent:Tx1)
key2 (t1): y1 (intent:Tx1)
\ ﾍｲﾚﾂ /
Parallel Write
Client
BEGIN;
Write (key1, x1);
Write (key2, y2);
COMMIT;
COMMIT のタイミングで Tx Record を作成する。この時、State には STAGING を設定
し、一緒に「更新対象の key の一覧 (key1, key2)」の情報を Tx Record 内に含める。
Parallel Commits (Write)
key1 (t0): x0
key2 (t0): y0
Slide 104
Slide 104 text
Node 1
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING
Keys: key1, key2
Range2 : Set of KV date (512BM)
\ ｶﾝﾘｮｳ / Write OK
Client
BEGIN;
Write (key1, x1);
Write (key2, y2);
COMMIT;
Write OK
Write OK
各 Write 及び Tx Record の作成が完了したことを確認する。
Parallel Commits (Write)
key1 (t1): x1 (intent:Tx1)
key2 (t1): y1 (intent:Tx1)
key1 (t0): x0
key2 (t0): y0
Slide 105
Slide 105 text
Node 1
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING
Keys: key1, key2
Range2 : Set of KV date (512BM)
\ ｵﾜｯﾀﾖ /
Client
BEGIN;
Write (key1, x1);
Write (key2, y2);
COMMIT;
COMMIT Complete
各 Write 及び Tx Record の作成が完了したことを確認した時点で、Client に COMMIT
完了を返す。
Parallel Commits (Write)
key1 (t1): x1 (intent:Tx1)
key2 (t1): y1 (intent:Tx1)
key1 (t0): x0
key2 (t0): y0
Slide 106
Slide 106 text
Node 1
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: COMMITTED
Keys: key1, key2
Range2 : Set of KV date (512BM)
\ ﾋﾄﾞｳｷ /
Client
Client に COMMIT 完了を返した後に「非同期」かつ並列で Tx Record の更新
(COMMITTED に更新) と write intent の削除を実施する。他の Tx が Read する可能
性が有るため、非同期ではあるが「できるだけ速く」更新する。
State is COMMITTED
Resolve intent
Resolve intent
Parallel Commits (Write)
key1 (t1): x1 (intent:Tx1)
key2 (t1): y1 (intent:Tx1)
key1 (t0): x0
key2 (t0): y0
Slide 107
Slide 107 text
Node 1
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: COMMITTED
Keys: key1, key2
Range2 : Set of KV date (512BM)
\ ｵﾜﾘ /
Client
write intent の処理完了後に、Tx Record は削除され更新した値の状態が確定
(COMMIT 済みに確定) する。
Parallel Commits (Write)
key1 (t1): x1
key2 (t1): y1
key1 (t0): x0
key2 (t0): y0
Slide 108
Slide 108 text
Parallel Commits
\ ﾓｯﾄ kwsk /
Read の動作
Slide 109
Slide 109 text
Node 1
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING
Keys: key1, key2
key1 (t1): x1 (intent:Tx1)
Range2 : Set of KV date (512BM)
key1 (t0): x0
key2 (t1): y1 (intent:Tx1)
key2 (t0): y0
Node 2
\ ﾘｰﾄﾞｽﾙﾖ /
\ ﾍｲﾚﾂ /
Node 1 が Tx1 で key1, key2 を更新し、Node 1 の処理途中 (Tx Record の State が
STAGING のタイミング) で Node 2 が Tx2 で key1 を Read する。
Parallel Write
Parallel Commits (Read)
Tx2 (t2) ※t0 < t1 < t2
Read (key1);
Slide 110
Slide 110 text
Node 1
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING
Keys: key1, key2
Range2 : Set of KV date (512BM)
Node 2
\ ﾘｰﾄﾞ /
\ ｼｮﾘﾁｭｳ... /
Node 2 が Tx2 で key1 を Read すると、write intent (COMMIT or ABORT が不定) に
なっている。また、Node 1 は処理中であるため Tx1 の Tx Record に定期的に
Heartbeat が送信されている。
Tx2 (t2) ※t0 < t1 < t2
Read (key1);
Read
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
key2 (t1): y1 (intent:Tx1)
key2 (t0): y0
Parallel Commits (Read)
Heartbeat
Write OK
Write OK
Write OK
Slide 111
Slide 111 text
Node 1
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING
Keys: key1, key2
Range2 : Set of KV date (512BM)
Node 2
\ ｶｸﾆﾝ /
\ ｼｮﾘﾁｭｳ... /
Node 2 (Tx2) が key1 の状態を確認するために Tx Record を参照すると、State が
STAGING であることがわかる。また、Node 1 からの Heartbeat も継続しているため
Node 1 (Tx1) は生きている (処理中) であることも確認できる。
Tx2 (t2) ※t0 < t1 < t2
Read (key1);
Check
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
key2 (t1): y1 (intent:Tx1)
key2 (t0): y0
Parallel Commits (Read)
Heartbeat
Write OK
Write OK
Write OK
Slide 112
Slide 112 text
Node 1
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING
Keys: key1, key2
Range2 : Set of KV date (512BM)
Node 2
\ ﾏﾂﾜ /
\ ｲｷﾃﾙﾖ /
Tx1 を管理する Node1 からの Heartbeat が続いているため、Node 1 (Tx1) は生きて
いる (処理中) と判断し、Node 2 (Tx2) は Tx1 が完了するまで待つ。
Tx2 (t2) ※t0 < t1 < t2
Read (key1); -> wait...
Heartbeat
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
key2 (t0): y0
Parallel Commits (Read)
key2 (t1): y1 (intent:Tx1)
Write OK
Write OK
Write OK
Slide 113
Slide 113 text
Node 1
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING
Keys: key1, key2
Range2 : Set of KV date (512BM)
Node 2
\ ﾀｲｷ /
\ ｼｮﾘﾁｭｳ... /
Tx1 は処理中... (Heartbeat は継続)
Tx2 は待機... (Tx1 の完了待ち)
Tx2 (t2) ※t0 < t1 < t2
Read (key1); -> wait...
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
key2 (t1): y1 (intent:Tx1)
key2 (t0): y0
Parallel Commits (Read)
Heartbeat
Write OK
Write OK
Write OK
Slide 114
Slide 114 text
Node 1
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: COMMITTED
Range2 : Set of KV date (512BM)
Node 2
\ ｵﾜｯﾀｯﾎﾟｲ /
\ ｵﾜｯﾀﾖ /
Tx1 の処理が完了すると、Tx2 (Node 2) は Tx1 にて更新された値 (x1) を Read する。
後述する Status Recovery Procedure は非常に重い処理であるため、Tx1 を管理する
Node 1 が生きている場合は、Tx1 が COMMIT されるまで待つ。
Tx2 (t2) ※t0 < t1 < t2
Read (key1); -> x1
Read
State is COMMITTED
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
key2 (t1): y1 (intent:Tx1)
key2 (t0): y0
Parallel Commits (Read)
Slide 115
Slide 115 text
Parallel Commits
\ ｻﾗﾆ kwsk /
障害発生時の Read (Status Recovery Procedure)
Slide 116
Slide 116 text
Node 1
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING
Keys: key1, key2
key1 (t1): x1 (intent:Tx1)
Range2 : Set of KV date (512BM)
key1 (t0): x0
key2 (t1): y1 (intent:Tx1)
key2 (t0): y0
Node 2
\ ﾘｰﾄﾞｽﾙﾖ /
\ ﾍｲﾚﾂ /
Case 1 : Node 1 が Tx1 で key1, key2 を更新し、Node 1 の処理途中 (Tx Record の
State が STAGING のタイミング) で Node 2 が Tx2 で key1 を Read する。また、全て
の write intent 書き込み完了後に Node 1 で障害が発生する。
Parallel Write
Status Recovery Procedure1
Tx2 (t2) ※t0 < t1 < t2
Read (key1);
Slide 117
Slide 117 text
Node 1
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING
Keys: key1, key2
key1 (t1): x1 (intent:Tx1)
Range2 : Set of KV date (512BM)
key1 (t0): x0
key2 (t1): y1 (intent:Tx1)
key2 (t0): y0
Node 2
\ ﾘｰﾄﾞｽﾙﾖ /
全ての write intent 書き込み完了後に Node 1 で障害が発生する。また、Node 1 の障
害に起因して Tx1 の Tx Record への Heartbeat が途切れる。
Status Recovery Procedure1
~
Heartbeat
Tx2 (t2) ※t0 < t1 < t2
Read (key1);
Write OK
Write OK
Write OK
Slide 118
Slide 118 text
Node 1
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING (expired)
Keys: key1, key2
Range2 : Set of KV date (512BM)
Node 2
\ ﾘｰﾄﾞ /
Node 2 が Tx2 で key1 を Read すると、write intent (COMMIT or ABORT が不定) に
なっている。また、Node 1 に障害が発生し Heartbeat が途切れたため、Tx1 は expired
となる。
Tx2 (t2) ※t0 < t1 < t2
Read (key1);
Read
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
key2 (t1): y1 (intent:Tx1)
key2 (t0): y0
Status Recovery Procedure1
Heartbeat
Slide 119
Slide 119 text
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING (expired)
Keys: key1, key2
Range2 : Set of KV date (512BM)
Node 2
\ ｶｸﾆﾝ /
Node 2 (Tx2) が key1 の状態を確認するために Tx Record を参照すると、State が
STAGING であることがわかる。また、Node 1 からの Heartbeat が途切れているため
Node 1 (Tx1) が死んだと判断する。
Tx2 (t2) ※t0 < t1 < t2
Read (key1);
Check (Tx1 is expired)
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
key2 (t1): y1 (intent:Tx1)
key2 (t0): y0
Status Recovery Procedure1
Node 1
Slide 120
Slide 120 text
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING (expired)
Keys: key1, key2
Range2 : Set of KV date (512BM)
Node 2
\ ｻﾗﾆｶｸﾆﾝ /
Tx Record に含まれている更新対象の key の情報を基に、Tx1 の更新対象である
key2 の write intent が作成されているかを確認する。
Tx2 (t2) ※t0 < t1 < t2
Read (key1);
Check
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
key2 (t1): y1 (intent:Tx1)
key2 (t0): y0
Status Recovery Procedure1
Node 1
Slide 121
Slide 121 text
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING (expired)
Keys: key1, key2
Range2 : Set of KV date (512BM)
Node 2
\ ｺﾐｯﾄﾀﾞﾅ /
Tx Record (STAGING) 内に含まれている key の write intent が全て書き込まれている
場合、implicitly committed (暗黙的な COMMIT である) として扱い、Tx2 (Node 2) は
write intent の値を Read する。
Tx2 (t2) ※t0 < t1 < t2
Read (key1); -> x1
Read
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
key2 (t1): y1 (intent:Tx1)
key2 (t0): y0
Status Recovery Procedure1
Node 1
Slide 122
Slide 122 text
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: COMMITTED
Keys: key1, key2
Range2 : Set of KV date (512BM)
Node 2
\ ｺﾐｯﾄﾀﾞﾖ /
他の Tx が Status Recovery Procedure を実行しなくても済むように、Node 2 が Tx1
の Tx Record の State を COMMITTED に更新する。
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
key2 (t1): y1 (intent:Tx1)
key2 (t0): y0
Status Recovery Procedure1
Node 1 State is COMMITTED
Slide 123
Slide 123 text
Status Recovery Procedure2
Node 1
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING
Keys: key1, key2
Range2 : Set of KV date (512BM)
Node 2
\ ﾘｰﾄﾞｽﾙﾖ /
\ ﾍｲﾚﾂ /
Case 2 : Node 1 が Tx1 で key1, key2 を更新し、Node 1 の処理途中 (Tx Record の
State が STAGING のタイミング) で Node 2 が Tx2 で key1 を Read する。また、key2
の write intent 作成前に Node 1 で障害が発生する。
Parallel Write
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
key2 (t1): y1 (intent:Tx1)
key2 (t0): y0
Tx2 (t2) ※t0 < t1 < t2
Read (key1);
Slide 124
Slide 124 text
Status Recovery Procedure2
Node 1
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING
Keys: key1, key2
Range2 : Set of KV date (512BM)
Node 2
\ ﾘｰﾄﾞｽﾙﾖ /
一部の write intent 書き込み完了前に Node 1 で障害が発生する。また、Node 1 の障
害に起因して Tx1 の Tx Record への Heartbeat が途切れる。
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
key2 (t1): y1 (intent:Tx1)
key2 (t0): y0
Tx2 (t2) ※t0 < t1 < t2
Read (key1);
~
Heartbeat
Write OK
Write OK
Slide 125
Slide 125 text
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING (expired)
Keys: key1, key2
Range2 : Set of KV date (512BM)
Node 2
\ ﾘｰﾄﾞ /
Node 2 が Tx2 で key1 を Read すると、write intent (COMMIT or ABORT が不定) に
なっている。また、Node 1 に障害が発生し Heartbeat が途切れたため、Tx1 は expired
となる。
Tx2 (t2) ※t0 < t1 < t2
Read (key1);
Read
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
key2 (t1): y1 (intent:Tx1)
key2 (t0): y0
Status Recovery Procedure2
Node 1
Heartbeat
Slide 126
Slide 126 text
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING (expired)
Keys: key1, key2
Range2 : Set of KV date (512BM)
Node 2
\ ｶｸﾆﾝ /
Node 2 (Tx2) が key1 の状態を確認するために Tx Record を参照すると、State が
STAGING であることがわかる。また、Node 1 からの Heartbeat が途切れているため
Node 1 (Tx1) が死んだと判断する。
Tx2 (t2) ※t0 < t1 < t2
Read (key1);
Check (Tx1 is expired)
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
key2 (t0): y0
Node 1
Status Recovery Procedure2
key2 (t1): y1 (intent:Tx1)
Slide 127
Slide 127 text
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING (expired)
Keys: key1, key2
Range2 : Set of KV date (512BM)
Node 2
\ ﾅｲ /
Tx Record に含まれている更新対象の key の情報を基に、Tx1 の更新対象である
key2 の write intent が作成されているかを確認する。しかし、key2 の write intent は存
在していないことが確認される。
Tx2 (t2) ※t0 < t1 < t2
Read (key1);
Check
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
key2 (t0): y0
Node 1
Status Recovery Procedure2
key2 (t1): y1 (intent:Tx1)
Slide 128
Slide 128 text
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: STAGING (expired)
Keys: key1, key2
Range2 : Set of KV date (512BM)
Node 2
\ ｱﾎﾞｰﾄﾀﾞﾅ /
Tx1 は ABORT したものとして扱い、Tx2 (Node 2) は x0 を Read する。
Tx2 (t2) ※t0 < t1 < t2
Read (key1); -> x0
Read
Node 1
key1 (t0): x0
key2 (t0): y0
Status Recovery Procedure2
key1 (t1): x1 (intent:Tx1)
key2 (t1): y1 (intent:Tx1)
Slide 129
Slide 129 text
Range1 : Set of KV date (512BM)
Tx1’s “Transaction Record”
------------------------------------
State: ABORTED
Range2 : Set of KV date (512BM)
Node 2
\ ｼﾝﾀﾞｯﾎﾟｲ /
他の Tx が Status Recovery Procedure を実行しなくても済むように、Node 2 が Tx1
の Tx Record の State を ABORTED に更新する。
Tx2 (t2) ※t0 < t1 < t2
Read (key1);
Node 1
State is ABORTED
key1 (t1): x1 (intent:Tx1)
key1 (t0): x0
key2 (t1): y1 (intent:Tx1)
key2 (t0): y0
Status Recovery Procedure2
Slide 130
Slide 130 text
Parallel Commits (v19.2 ~)
BEGIN;
Write (key1, x1);
Write (key2, y1);
Write (key3, z1);
COMMIT;
Timeline
COMMIT 時に作成する Tx
Record (STAGING) の中に更
新対象の key の一覧を含める
ことで、処理時間を (最短で)
O(1) にしつつ、他の Tx の
Read も正しく処理できるように
している。
Slide 131
Slide 131 text
Parallel Commits (v19.2 ~)
BEGIN;
Write (key1, x1);
Write (key2, y1);
Write (key3, z1);
COMMIT;
Update Tx Record &
Remove write intent
Timeline
非同期 (async)
Client に COMMIT 完了を返し
た後に、非同期で Tx Record
の値を (できるだけ速く)
COMMITTED に更新し、write
intent を削除する。
Status Recovery Procedure
は「重い処理」であり、通常
(Gateway Node が生きてる場
合) は COMMIT 完了を待つ
が、障害発生時は他の Node
で適切に対処できる。
Slide 132
Slide 132 text
Timestamp を使った Tx の制御
\ ﾀｲﾑｽﾀﾝﾌﾟ /
Slide 133
Slide 133 text
上 2つについてはお話ししましたが...
● Atomicity (原子性) を満たす必要がある。
● 他の Tx の状態を判断する必要がある。
● Tx の順番を判断する必要がある。
\ ｶﾀﾞｲ /
Slide 134
Slide 134 text
3つ目についてはまだ話してません
● Atomicity (原子性) を満たす必要がある。
● 他の Tx の状態を判断する必要がある。
● Tx の順番を判断する必要がある。
\ ｶﾀﾞｲ /
Slide 135
Slide 135 text
しかし
\ But... /
Slide 136
Slide 136 text
時間が足りません...
\ ﾀﾘﾅｲ /
Slide 137
Slide 137 text
が
\ ｶﾞｯ /
Slide 138
Slide 138 text
資料 (スライド) はあります
\ ｱﾙﾖ /
Slide 139
Slide 139 text
宣伝
\ ｾﾝﾃﾞﾝ /
Slide 140
Slide 140 text
前編
https://speakerdeck.com/kota2and3kan/how-commit-works-in-cockroachdb
今回のセッションの元ネタです。内容はほぼ同じですが、概要やおまけ等、少し
だけ詳しく情報が載っているので、興味がある方は是非。
\ ｾﾞﾝﾍﾟﾝ
/
Slide 141
Slide 141 text
後編
https://speakerdeck.com/kota2and3kan/resolving-tx-conflicts-in-cockroachdb
今回のセッションの続きの資料です。Timestamp を利用した Tx の制御につい
てまとめているので、興味がある方は是非。
\ ｺｳﾍﾝ
/
Slide 142
Slide 142 text
まとめ
\ ﾏﾄﾒ /
Slide 143
Slide 143 text
● 分散 RDBMS には分散トランザクションが必要。
● CockroachDB は Transaction Record を使って分散 Tx を実
現している。
● 更に、Parallel Commits で性能向上も図っている。
● 今回紹介した内容以外の機能も使って (Timestamp 等を使っ
て) Tx の競合を解決したり一貫性を確保したりしている。
まとめ
Slide 144
Slide 144 text
Thank you!