Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
How COMMIT Works in CockroachDB ~Short Version~
kota2and3kan
March 09, 2021
Technology
0
48
How COMMIT Works in CockroachDB ~Short Version~
kota2and3kan
March 09, 2021
Tweet
Share
More Decks by kota2and3kan
See All by kota2and3kan
分散トランザクション in CockroachDB / Distributed Tx in CockroachDB
kota2and3kan
0
1k
Resolving Tx Conflicts in CockroachDB ~Short Version~
kota2and3kan
0
140
Resolving Tx Conflicts in CockroachDB
kota2and3kan
5
970
How COMMIT Works in CockroachDB
kota2and3kan
15
1.8k
20190701_What_is_CockroachDB
kota2and3kan
10
1.6k
Other Decks in Technology
See All in Technology
プログラミング未経験の学生をエンジニアにしてきたノウハウを公開
shinofumijp
0
200
ZOZOTOWNのProduction Readiness Checklistと信頼性向上の取り組み / Improvement the reliability of ZOZOTOWN with Production Readiness Checklist
akitok_
5
2.1k
1年間のポストモーテム運用とそこから生まれたツール sre-advisor / SRE NEXT 2022
fujiwara3
6
3.7k
NestJS + Prisma2 で歩む RLS の世界
ynaka81
1
100
20220523_akibaaws-online-08-s3
hiashisan
0
110
Who owns the Service Level?
chaspy
5
1.4k
⚡Lightdashを試してみた
k_data_analyst
0
220
Apache Kafka and the World of Streams
hashitokyo
0
130
Data Warehouse or Data Lake, which one do I choose?
ahana
0
150
Scrum Fest Niigata 2022 開発エンジニアに聞いてみよう!
moritamasami
1
680
0->1 フェーズで E2E 自動テストを導入した私たちの、これまでとこれから
yoyakoba
0
860
220521_SFN_品質文化試論と『LEADING QUALITY』/220521_SFN_Essay_of_Quality_Culture_and_LEADING_QUALITY
mkwrd
0
330
Featured
See All Featured
Six Lessons from altMBA
skipperchong
14
1.3k
Three Pipe Problems
jasonvnalue
89
8.6k
Building a Scalable Design System with Sketch
lauravandoore
447
30k
GraphQLとの向き合い方2022年版
quramy
16
8.1k
VelocityConf: Rendering Performance Case Studies
addyosmani
316
22k
Gamification - CAS2011
davidbonilla
75
3.9k
Intergalactic Javascript Robots from Outer Space
tanoku
261
25k
The Brand Is Dead. Long Live the Brand.
mthomps
45
2.7k
Building Applications with DynamoDB
mza
83
4.6k
Reflections from 52 weeks, 52 projects
jeffersonlam
337
17k
WebSockets: Embracing the real-time Web
robhawkes
57
5k
Navigating Team Friction
lara
175
11k
Transcript
How COMMIT works in CockroachDB ~ Short Version ~ \
ミジカイ /
• Name: Takanori Yokoyama ◦ @kota2and3kan (Twitter, GitHub) • Job:
Technical Support • Like: DB ◦ PostgreSQL, CockroachDB • Dislike: Real Cockroach @kota2and3kan こたつ&&みかん Who am I.
※Note※ ちょっと自信が無いとこもあります! 間違ってたらごめんさない!!! \ ユルシテ /
目次 • CockroachDB についてざっくり概要 • COMMIT (Write) の動作 • Read
の動作 • 宣伝 • まとめ
CockroachDB についてざっくり概要 \ ガイヨウ /
CockroachDB is ... 分散 SQL データベース
全てのノードで Read / Write のクエリを処理可能 Load Balancer Service (k8s) etc...
Read / Write
CockroachDB についてざっくり概要 格納されるデータ (Key-Value) の構造 \ キーバリュー /
Table と Key-Value id c1 c2 c3 1 foo bar
baz 2 hoge fuga piyo 3 (・ω・´) (´・ω・`) m9(^Д^) key value /Table/54/1/1/0/1615095374.173379261,0 c1: foo, c2: bar, c3: baz /Table/54/1/2/0/1615095392.837630582,0 c1: hoge, c2: fuga, c3:piyo /Table/54/1/3/0/1615095596.484809926,0 c1: (・ω・´), c2: (´・ω・`), c3: m9(^Д^) test ※ id -> Primary Key ・Key-Value 形式に変換。 ・Key で Sort。 ・最近はデフォルトだと 1 record = 1 KV。 ・Key は以下の形式で変換される。 ・Key に Timestamp が含まれている。 /Table/Table ID/Primary Key ID/Value of PK/Column Family/Timestamp https://github.com/cockroachdb/cockroach/blob/master/docs/tech-notes/encoding.md
Keyspace test Monolithic & Sorted by key tbl1 tbl2 key
value /Table/54/1/1/0/1615095374.173379261,0 c1: foo, c2: bar, c3: baz /Table/54/1/2/0/1615095392.837630582,0 c1: hoge, c2: fuga, c3:piyo /Table/54/1/3/0/1615095596.484809926,0 c1: (・ω・´), c2: (´・ω・`), c3: m9(^Д^) Key-Value と Keyspace Key-Value 形式に変換された各 Table は、 Key で Sort された Keyspace (論理的に 1つの大きな塊) に map される。
Keyspace と Range Range1 Range2 Range3 ・ ・ ・ Range
N 512MB 512MB 512MB Keyspace ・いい感じに分割。 ・デフォルト 512MB。
Replica と Leaseholder Range1 Range2 Range3 Range1 Range2 Range3 Range1
Range2 Range3 lease lease lease • Range を各ノードにいい感じに分散。 • Raft を使って Replica を作成 (3つ)。 • Replica の 1つが lease を持つ。 • lease を持つ Range をLeaseholder と呼 ぶ。 • Read / Write は全て Leaseholder で処 理。 • 基本 Leaseholder = “Raft Leader” にな る。
Replica と Leaseholder Range1 Range2 Range3 Range1 Range2 Range3 Range1
Range2 Range3 lease lease lease • Range 毎に Raft Group を作成。 Raft Group 1 Raft Group 2 Raft Group 3
CockroachDB についてざっくり概要 SQL を誰が処理するか \ クエリ /
Gateway Node (Coordinator) • クエリを受け取った Node は “Gateway Node” と呼ばれる。
◦ いわゆる “コーディネーター” Node。 • Gateway Node が Tx を管理する。 ◦ Tx 内の各 SQL は Gateway Node 経由で各 Node にルーティングされる。 SQL
Range1 Range2 Range3 lease • Gateway Node 内に Leaseholder が有る。
◦ 自分で処理。 • Gateway Node 内に Leaseholder が無い。 ◦ Leaseholder を持つ Node にクエリをルーティ ング。 • つまり Tx 内の各 SQL は Raft Leader 経由で Read / Write を実行する。 ◦ Raft Leader を持つ Node に SQL がルーティン グされる。 Gateway Node の動作
Write Query その1 Write lease lease lease • Gateway Node
== Leaseholder
Write Write Query その2 lease lease lease • Gateway Node
!= Leaseholder
COMMIT (Write) の動作 \ コミット /
用語概要 • 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
用語概要 (Transaction Record) • Transaction の状態を管理する。 • Tx 内で最初に Write
された key と同じ Range に書き込まれる。 • 以下の State がある。 ◦ PENDING ▪ Tx は処理中。 ◦ COMMITTED ▪ Tx は COMMIT 済み。 ◦ STAGING ▪ Tx は Parallel Commits で処理中。 ◦ ABORTED ▪ Tx は ABORT 済み。 ◦ (MISSING) ▪ Transaction Record そのものが無い。
用語概要 (Write Intent) • Transaction の状態 (COMMIT / ABORT) が確定していないレコード
(KV) に付けられる印。 • 以下のような情報を持っている。 ◦ 関連する (当該レコードを Write した) Tx の ID。 ◦ Write Intent が書き込まれた時間。
用語概要 (Transaction Liveness Threshold) • Transaction の生死 (Tx を管理している Node
の生死) を判断するための 閾値 (死んだと判断するまでの時間)。 ◦ Gateway Node での障害発生有無を確認する場合等に使われる。 ◦ 文字通り、そのまんまの感じのやつ。
COMMIT の仕組み Range : Set of KV date (512BM) Tx1
(timestamp t1) BEGIN; Write (key1, x1); COMMIT; key1 (t0): x0 key2 (t0): y0 key3 (t0): z0
Tx 開始 Range : Set of KV date (512BM) Tx1
(t1) BEGIN; Write (key1, x1); COMMIT; key1 (t0): x0 key2 (t0): y0 key3 (t0): z0
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)
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
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
“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 と同じ状態になる。
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 が非同期 で削除される。
Read の動作 \ リード /
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
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
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
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)
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
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
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...
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
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
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
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
宣伝 \ センデン /
こちら「LT のつもりで作成してたのに気づいたらページ数が 142 ページになっていたスライド」です。ご査収ください。 How COMMIT Works in CockroachDB https://speakerdeck.com/kota2and3kan/how-commit-works-in-cockroachdb
• Gateway Node の障害が発生した際の動作 (検知 / 対処) や、Parallel Commits と いう仕組み (1ラウンドのコンセンサスで分散 Tx を COMMIT するやつ) についても 解説しています。 宣伝
まとめ \ マトメ /
まとめ LT で分散 Tx を語るの is 無理! \ ムリ /
まとめ 興味がある人は是非! https://speakerdeck.com/kota2and3kan/how-commit-works-in-cockroachdb \ ミテネ /
Thank you!