Cassandra simple insert/get 하기..

Client 객체는 기본적으로, 카산드라 클라이언트(Cassandra.Client) 생성 예제를 같이 사용하고 있습니다.
가장 기초적인 1개의 Column에 데이타 insert/get 하는 예제입니다..

package net.sjava.cassandra.test;import org.apache.cassandra.thrift.Column;
import org.apache.cassandra.thrift.ColumnPath;
import org.apache.cassandra.thrift.ConsistencyLevel;

public class CassandraTest {
* @param args
public static void main(String[] args) {
// TODO Auto-generated method stub

CassandraClientFactory factory = CassandraClientFactory.getInstance();
String keyspace = “Keyspace1”;
String columnFamily = “Standard2”;
String key = “key1″;
long timestamp = System.currentTimeMillis();

String value =”aaaaaaaaaaaaaaaaaaa_bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb”;
try {
ColumnPath cPath = new ColumnPath(columnFamily);
factory.getClient().insert(keyspace, key, cPath, value.getBytes(“utf-8”), timestamp, ConsistencyLevel.ONE);
Column col = factory.getClient().get(keyspace, key, cPath, ConsistencyLevel.ONE).getColumn();
System.out.println(“Column name: ” + new String(, “utf-8”));
System.out.println(“Column value: ” + new String(col.value, “utf-8″));

value =”aaaaaaaaaa”;

long time2 = System.currentTimeMillis();
factory.getClient().insert(keyspace, key, cPath, value.getBytes(“utf-8”), time2, ConsistencyLevel.ONE);
Column col2 = factory.getClient().get(keyspace, key, cPath, ConsistencyLevel.ONE).getColumn();
System.out.println(“Column2 name: ” + new String(, “utf-8”));
System.out.println(“Column2 value: ” + new String(col2.value, “utf-8”));
} catch(Exception e) {


ConsistencyLevel에 대해서..

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.
 * Write:
 *      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>&lt;ReplicationFactor&gt;</code> nodes before responding to the client.
 * Read:
 *      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.

클라이언트에서 데이타를 쓰고, 읽기를 진행할때, 위의 주석에 대한 숙지가 꼭 필요할 것 같습니다. ^^

ClusterName 바꿔서 발생한 오류..

storage-conf.xml 의  <ClusterName>을 Cluster1으로 바꾸니 에러가 나네요.. ^^;;

INFO 10:00:53,760 Saved ClusterName found: Test Cluster
ERROR 10:00:53,760 ClusterName mismatch: Test Cluster != Cluster1

storage-conf.xml의 <DataFileDirectory>에서 설정한 위치의 하위 디렉토리인 system 디렉토리의 LocationInfo 파일들 다 지우면 된다고 하네요..

카산드라 클라이언트(Cassandra.Client) 생성 예제

카산드라 클라이언트(Cassandra.Client) 클래스는 를 이용해서 카산드라 DB에 데이타를 입력(Insert)하고 검색(Select)하게 도와주는 클래스이다. Cassandra.Client를 생성하고 사용하기 위해서 제가 사용하는 CassandraClientFactory 클래스는 아래와 같습니다.

import org.apache.cassandra.thrift.Cassandra;
import org.apache.thrift.protocol.TBinaryProtocol;
import org.apache.thrift.transport.TSocket;
import org.apache.thrift.transport.TTransport;public class CassandraClientFactory {
private final String SERVER = “localhost”;
private final int PORT = 9160;

// inner class
private Cassandra.Client client;
// singleton instance
private static CassandraClientFactory instance = new CassandraClientFactory();

private CassandraClientFactory() {
try {
TTransport socket = new TSocket(SERVER, PORT);
//out.println(String.format(“connected to %s : %d .”, SERVER, PORT));
TBinaryProtocol binaryProtocol = new TBinaryProtocol(socket, false, false);
this.client = new Cassandra.Client(binaryProtocol);;
} catch(org.apache.thrift.transport.TTransportException e) {

public static CassandraClientFactory getInstance() {
return instance;

public Cassandra.Client getClient() {
return this.client;