Cassandra Thrift APIのConsistencyLevel

前回に引き続きCassandraについて調査継続中で、今回はThrift APIの ConsistencyLevel について。以下のサイトの該当項目をざっくりと意訳した程度のメモです。
API06 – Cassandra Wiki

Cassandra Thrift APIにおける ConsistencyLevel は、 storage-conf.xml で設定した <ReplicationFactor> (データの複製を保存するノード数)に基づいてread/writeの振る舞いを制御します。以下の条件が成り立つ場合は強い一貫性が得られ、常に最新データを参照できます。

(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 – 結果整合性

あわせて読む:

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です