Cassandra의 경우, Cassandra의 서버 설정에서 <ReplicationFactor>1</ReplicationFactor>를 통해서 데이타 복제에 대한 설정을 할 수 잇습니다. 클라이언트에서는 데이타를 쓰고, 읽는데 ConsistencyLevel을 통해서 Async 또는 Sync(1개만 되면 리턴, 설정된 개수만큼 저장이 되야 리턴)등의 설정 파라미터를 통해서 정책적으로 성격에 맞게 사용할 수 있습니다. 그래서, ConsistencyLevel은 잘 알고 있어야 할거 같습니다.
0.6.2버전에서의 ConsitencyLevel에 대한 주석내용은 아래와 같습니다.
* The ConsistencyLevel is an enum that controls both read and write behavior based on <ReplicationFactor> in your
* storage-conf.xml. The different consistency levels have different meanings, depending on if you’re doing a write or read
* operation. Note that if W + R > ReplicationFactor, where W is the number of nodes to block for on write, and R
* the number to block for on reads, you will have strongly consistent behavior; that is, readers will always see the most
* recent write. Of these, the most interesting is to do QUORUM reads and writes, which gives you consistency while still
* allowing availability in the face of node failures up to half of <ReplicationFactor>. Of course if latency is more
* important than consistency then you can use lower values for either or both.
* ZERO Ensure nothing. A write happens asynchronously in background
* ANY Ensure that the write has been written once somewhere, including possibly being hinted in a non-target node.
* ONE Ensure that the write has been written to at least 1 node’s commit log and memory table before responding to the client.
* QUORUM Ensure that the write has been written to <ReplicationFactor> / 2 + 1 nodes before responding to the client.
* ALL Ensure that the write is written to <code><ReplicationFactor></code> nodes before responding to the client.
* ZERO Not supported, because it doesn’t make sense.
* ANY Not supported. You probably want ONE instead.
* ONE Will return the record returned by the first node to respond. A consistency check is always done in a
* background thread to fix any consistency issues when ConsistencyLevel.ONE is used. This means subsequent
* calls will have correct data even if the initial read gets an older value. (This is called ‘read repair’.)
* QUORUM Will query all storage nodes and return the record with the most recent timestamp once it has at least a
* majority of replicas reported. Again, the remaining replicas will be checked in the background.
* ALL Not yet supported, but we plan to eventually.
클라이언트에서 데이타를 쓰고, 읽기를 진행할때, 위의 주석에 대한 숙지가 꼭 필요할 것 같습니다. ^^