Eventual Consistencyまでの一貫性図解大全
読んでいて、ちゃんと理解できていないと思ったYudai.icon
現実的かつ最強の一貫性モデルがLinearizability(線形化可能性)である
条件
操作があたかも一瞬で完了したかのように観測ができ、実時間の中のどこかにプロットできる
プロットされる時間が操作の開始から完了の実時間中のどこかである
外部一貫性とも呼ばれるこれはその差分が実用上どこで出てくるかはよくわからない 条件
並列しない2つの操作は論理的にも実時間と同じ順序で実行される
この文章が直感的でなかった人向けに言い換えると「ある操作が完了した後で始まった別の操作は前の操作を絶対追い越さない」と言い換えても良い。
わかりやすいね
この文章が直感的でなかった人向けに言い換えると「ある操作が完了した後で始まった別の操作は前の操作を絶対追い越さない」と言い換えても良い。
ちょうど外部一貫性についてspannerで見かけて調べ始めて今に至る...wYudai.icon 条件
操作があたかも一瞬で完了したかのように観測でき、実時間の中のどこかにプロットできる
操作が一切行われない実時間上の空白を静止状態と呼び、それを跨るリオーダーは行われない
https://scrapbox.io/files/6a57453bbe32792658e76f2a.png
Linearizabilityは条件上確実にこれを満たすので完全な上位互換にあたるが、External Consistencyは静止状態について何も述べていないように見えるのでその観点ではこちらのほうが強いという言い方はできなくはない。
図で言うとQuiescent Stateと書いてある水色の矩形の領域はどのクライアントも操作をしていない区間なのだが、これをまたがる操作が存在しないことを保証するのがQuiescent Consistencyである。
これかなりわかりやすいYudai.icon
条件
操作があたかも一瞬で完了したかのように観測でき、実時間の中のどこかにプロットできる
同一のクライアントから発行される操作の間ではリオーダーは行われない
この挙動は大雑把に言うと「すべての操作が一本のキューによって投入順に行われているかのように実行される」という理解をすると正しい。
なるほどYudai.icon
一般にCPUのキャッシュ機構が満たしていると言われるConsistencyがこれである
条件
Releaseという指定のついた特定の操作は発行された後に同一クライアントからの他の操作によって追い越されない
Acquireというシエテいのついた特定の操作は発行する際に同一クライアントからの他の操作を追い越さない
付けないとすべての操作が追い越し・追い越される可能性が発生することになる。逆に、すべての操作にAcquireかつReleaseの指定をつけるとそれはSequential Consistencyと同じ挙動になる
確かにYudai.icon
まず因果一貫性とも呼ばれるこの一貫性モデルでは、クライアントはアクセスを行う際にこれまでにどのデータを読み書きしたかという情報をセットで提供する。それによって「この操作はあの操作よりも後」という順序付けをすることがサーバ側で順序付けできるようになるので因果関係が崩壊するような事態を避ける事ができる。
ってことはさ、順序づけと切り分けるって思考になったのは当たり前でしかないんだYudai.icon
ってかこの関係性をもっと早く知っていたら楽だったね
典型的にはベクタークロックを用いてデータにバージョンをつけていく事でこの一貫性レベルに落ちる事が多い。人間の直感に反しないように設計されているっぽく見えるがベクタークロックがそもそもスケールしにくい(参加台数に合わせてベクターが肥大化する)とか、複数のクライアント間で協調した際に思った通りに動いてくれなかったりとかあまり良い事ばかりには見えない
一貫性レベルが落ちるっていうのは、必ずしも他のクライアントと同じとは限らないって部分なんかな
条件
同一のクライアントから同じ場所に書き込まれた値だけは他のすべてのクライアントからもその順序で観測できる
別のクライアントから同じ場所に書き込まれた値はクライアントによって別の順序で観測される場合もある
自分が最近書いた値が自分で読める一貫性レベルである
どこのタイミングで操作が完了したか保証がない
ある値を読めたからと言って次に同じ値を読みに来た時に古い値に巻き戻る可能性も捨てきれない
自分が読めた順序で他のクライアントも読めているかもわからない
いずれ何らかの書き込んだ値になることだけは分かる