TECHMemo

CassandraのConsistency

Concistency Levelはデータのread, writeのAPIそれぞれで指定するようになっていて、Levelによってread, writeの挙動が異なってくる。

定義されているConsistency Levelは、以下の6つ。定義箇所は、以下の場所に。

https://svn.apache.org/repos/asf/incubator/cassandra/trunk/interface/cassandra.thrift

enum ConsistencyLevel {
    ZERO = 0,
    ONE = 1,
    QUORUM = 2,
    DCQUORUM = 3,
    DCQUORUMSYNC = 4,
    ALL = 5,
    ANY = 6,
}

thriftでgenerateしてクラスを生成し、API(read, write系)でConsistencyLevelを指定する。serviceのところの定義をみること。

以下、Consistency Levelの説明です。

WRITEのConcistency Level

• ZERO
  • 何も保証しない。バックグラウンドで非同期にwrite
• ANY
  • どこかで1回writeされたことを保証する。
• ONE
  • クライアントにresponseを返す前に、ひとつのノードのcommit logとmemory tableに書き込まれたことを保証する。
• QUORUM
  • クライアントにresponseを返す前に<ReplicationFactor> / 2 + 1 のノード群に書き込まれたことを保証する。
• ALL
  • クライアントにresponseを返す前に<ReplicationFactor>ノード群に、書き込まれたことを保証する。
  • いわゆるStrong Consistency

READのConsistency Level

• ZERO
  • サポートしない（意味なし）
• ANY
  • サポートしない
• ONE
  • 最初にレスポンスを返せるノードからレコードを返す 。
  • Concistencyチェックは、consistenc問題を修正するためにバックグラウンドのスレッドで常に行われる。これは、最初のgetで古い値を取得しても、次のgetでは正しいデータが取得できることを意味する。これはread repairと呼ばれる。
  • 実装としては、org.apache.cassandra.service.ConsistencyManagerで行われている。
• QUORUM
  • 全てのノードを検索し、最も新しいタイムスタンプのレコードを返す。
• ALL
  • まだサポートしてない。今後する予定とのこと。

QUORUMのConsistency

これはちょっと面白そうなので、別エントリで。

ツイートする