Spannerに関する技術メモ

1. Spanner に関する技術メモ
発表者：通りすがりの @enakai00

2. Disclaimer：
この記事は個人的なものです｡ここで述べられていること
は私の個人的な意見に基づくものであり、私の雇用者に
は関係はありません｡

3. Spannerのインフラデザイン
https://research.google.com/archive/spanner.html

4. 全体構成
Spanserver ⇒ Bigtable に類似の Key-Valueストア
Spanserver は Bigtable の Tablet server に相当 ⇒ Tablet の実体は Colossus 上に存在
DC (Zone) 間で Tablet の内容をレプリケーション（Paxosベースのアルゴリズム）

5. spanserver
(Table A)
spanserver
(Table B)
spanserver
(Table C)
Zone 1
spanserver
(Table A)
spanserver
(Table B)
spanserver
(Table C)
Zone 2
spanserver
(Table A)
spanserver
(Table B)
spanserver
(Table C)
Zone 3
replica replica
Horizontal Consistency
VerticalConsistency
Spannerのチャレンジ
● 同一 Zone の spanserver 間のデータ整合性をどう確保するか？
● Zone 間のデータ整合性をどう確保するか？

6. ところで、Spanserver間のデータの整合性って何？
⇒ トランザクションの仕組みから
整合性の意味を考えてみましょう。

7. トランザクションの動作
https://cloud.google.com/spanner/docs/transactions

8. ロックの種類
Shared Read Lock（共有ロック）
● 他のトランザクションからの書き込みを禁止
● 他のトランザクションからの読み込みは可能
● 他のトランザクションは同時に共有ロックを取得可能
Exclusive Write Lock（排他ロック）
● 他のトランザクションからの読み書きを禁止
● 他のトランザクションは同時にロックを取得できない
● 他のトランザクションが先に共有ロック／排他ロックを取っている場合は、排他ロックは
とれない。

9. リードライト・トランザクションにおけるロックの利用
AさんからBさんに50円送金するトランザクション
⇒ 外部からは時刻 t2 にすべての変更がまとめて行われたように見える
A : 100
B : 200
C : 1300
A : 100
B : 200
C : 1300
A : 50
B : 200
C : 1300
共有ロック
排他ロック
Read A = 100 Read B = 200
Write A = 50
Write B = 250
トランザクション開始
この時点では何も
書き込まれない
Commit
A : 50
B : 250
C : 1300
A : 100
B : 200
C : 1300
A : 50
B : 250
C : 1300
トランザクション中に読んだデータが
勝手に書き換えられることを防止
書き換え中の中途半端な状態が
読み取られることを防止
A : 100
B : 200
C : 1300
トランザクション終了
t1 t2
t2
書き込みデータには
Commit時の
タイムスタンプを付与

10. TNX B
TNX A と TNX B が平行に走る例
⇒ TNX B は時刻 t2 以前に開始しているが、そこは関係なくて、外部からは、
TNX B の処理は時刻 t3 にすべてまとめて行われたように見える！！！！
（トランザクション中に読んだデータはすべて共有ロックで守られているので、
どの時刻に読んだと考えても同じ結果になる点に注意）
A : 100
TNX A
B : 200
C : 1300
A : 100
B : 200
C : 1300
共有ロック
排他ロック
Read A = 100 Read B = 200
Write A = 50
Write B = 250
Commit
A : 50
B : 250
C : 1300
t1 t2
A : 50
B : 250
C : 1300
Read C = 1300 Read B = 250 Write B = 350
Write C = 1200
A : 50
B : 350
C : 1200
Commit
A : 50
B : 350
C : 1200
t3

11. TNX A はデータ A を書き換える（t = t2）
TNX B はデータ B を書き換える（t = t3）
この時、さらに別のトランザクションが A と B の値を読み取ると何が見えべきか？
読み取りリクエストを発行した時刻を T として・・・
● 時刻 t1 < T < t2 ⇒ (A, B) = (100, 200)
● 時刻 t2 < T < t3 ⇒ (A, B) = (101, 200)
● 時刻 t3 < T ⇒ (A, B) = (101, 201)
内部的には、「時刻 T 以前のタイムスタンプの中で最新のタイムスタンプのデータ」を spanserver から
取り出すことでこれを実現
⇒ リードオンリー・トランザクションでは、ロックを取得する必要がない！
A : 100 A : 100 A : 101 A : 101
B : 201
A : 101
B : 201B : 200
A : 101
t2
B : 200B : 200
t2 t2
B : 200
t1 t1 t1
t1 t3t1 t1 t1 t1

12. タイムスタンプベースのトランザクションの課題
行Aと行Bを別々のSpanserverが担当していて、サーバー間で時刻
同期がとれていなくて、行Bにタイムスタンプ t3 を振った時に、間違っ
て t3 < t2 にしちゃったら・・・
だめじゃん！
⇒ Truetime APIで解決

13. （参考）
タイムスタンプを使用しない従来型のアプローチ

14. Table A Table B
RDB without read transaction
Write 1
Write 2
Read 1
Read 2
RDB with read transaction
using read-lock mechanism
Table A Table B
Write 1
Write 2
Read 1
read lock
lock release
リードオンリー・トランザクションでもリードロックが発生する
ので性能が上がらない。
NG

15. Table A Table B
Write 1
Write 2
Read
RDB with read transaction
using MVCC (multi version concurrency control)
Write 0
Transaction ID
0
1
2
get ID
read ID=0
read ID=0
トランザクションIDを一元管理する処理がボトルネックになる

16. Table A Table B
Write 1
Write 2
Read
Spanner's approach
Use timestamp as a transaction ID
Write 0 get current time
read time=0
read time=0
Spannerでは、トランザクションIDの代わりにタイムスタンプを使用す
ることで、ボトルネックを排除
time=0
time=1
time=2

17. よくわかった。
それでは、Zone間のデータの整合性って何？？？
⇒ 今回は省略。m(_ _)m

18. Truetime APIで t3 > t2 を保証する方法
https://research.google.com/archive/spanner-osdi2012.pptx

19. commit
start
Time range
t=0 t=2
Choose commit timestamp as latest possible time t2=X
Realtime
Time range
t=2 t=4
Write data at t(real) > t2 = X
t(real)=X
Truetime API
⇒ 信頼出来る時刻の範囲 (t_after, t_before) を返すAPI
commit
finish
上記の commit finish 以降、つまり、t(real) > t2 = 2 の瞬間に次のトランザクションの
commit start が発生したとすると、 t3 > t(real) > t2 が保証される
（commit start 〜 commit execute の間は、排他ロックが取得されているので、同じ行を含む他のトランザ
クションの commit start は発行されない。)
排他ロック
取得完了

20. Fluctuations of time drifts from time servers
(excerpt from the research paper)
Hardware maintenance
of two time servers
Network latency
improvement
Truetime APIの精度
Truetime APIが返す時刻 (t_after, t_before) の幅が大きいと commit 処理時の
待ち時間が長くなるので、できるだけ小さい幅で返すことが重要

21. Thanks!