前回に引き続きCassandraについて調査継続中で、今回はThrift APIの ConsistencyLevel について。以下のサイトの該当項目をざっくりと意訳した程度のメモです。
API06 – Cassandra Wiki
Cassandra Thrift APIにおける ConsistencyLevel は、 storage-conf.xml で設定した <ReplicationFactor> (データの複製を保存するノード数)に基づいてread/writeの振る舞いを制御します。以下の条件が成り立つ場合は強い一貫性が得られ、常に最新データを参照できます。
|
1 |
if W + R > ReplicationFactor |
(W: 更新操作を完了する前に更新通知を受け取る必要のあるレプリカの数、R: 読み込み操作でデータオブジェクトにアクセスしたとき, 取りにいく必要のあるレプリカの数)
一貫性よりも速度(遅延時間)の方が重要な場合は、上記の条件を満たさないような低いレベルを使えます。
Write
| Level | Behavior |
| ZERO | 保証しない。バックグラウンドで非同期にwriteされる。 |
| ANY | 少なくともどこか一つのノードにwriteされたことを保証する。 |
| ONE | クライアントにレスポンスを返す前に、一つのノードのCommitLogとMemtableにwriteされたことを保証する。 |
| QUORUM | クライアントにレスポンスを返す前に、<ReplicationFactor> / 2 + 1 つのノード群にwriteされたことを保証する。 |
| ALL | クライアントにレスポンスを返す前に、<ReplicationFactor>つのノード群にwriteされたことを保証する。 |
Read
| Level | Behavior |
| ZERO | サポートしない。 |
| ANY | サポートしない。 |
| ONE | 最初にレスポンスを返せるノードからレコードを返す。一貫性チェックはバックグラウンドのスレッドで常に行われている。これは最初のreadで古い値を取得したとしても、その後のreadでは正しい値を取得できることを意味する。(これは read repair と呼ばれる) |
| QUORUM | 全ノードを探索し、過半数のレプリカからレスポンスを得た時点で最も新しいタイムスタンプのレコードを返す。残りのレプリカの一貫性チェックはバックグラウンドで行われる。 |
| ALL | 全ノードを探索し、全ノードからレスポンスを得た時点で最も新しいタイムスタンプのレコードを返す。 |
この一貫性の設定はデフォルト値に頼らず、明示的にConsistencyLevelを指定するようにした方がいいです。
* 関連記事
Cassandraについて
EventuallyConsistent – 結果整合性