원문: http://wiki.apache.org/cassandra/Operations#Removing_nodes_entirely

Wiki 가이드 내용을 요약하면 표와 같다.

정리하자면, 제거 대상 노드가 살아 있을 경우, decommission이 유리하고, 그렇지 않을 경우에 removetoken을 사용해야 할 것으로 예상된다.

이유는, 아무래도, 없어진 replica에 대해서 누군가로부터 읽어서, 그리고 노드간 송/수신이 일어나야 복원이 되는 removetoken에 비해, decommission의 경우 탈퇴/제거 당시 시점까지의 데이타는 모두 가지고 있기 때문에 속했던 클러스터로 데이타를 주기만 하며, 클러스트에서 계속 서비스 중인 노드들은 이제는 외부로부터 데이타를 받기만 하면 되기 때문이다.

여튼저튼, decommission명령에 더이상 서비스는 담당하지 않겠다는, disable thrift, disable gossip과 같은 행위가 수반되는지를 Source Code로부터 확인은 해봐야 겠지만, 위 정보만으로 우선 메모 해둠...

(최근 발표된 cassandra 1.2.x는 virtual-node 방식이라, decommission은 어떻게 작용할지 의문이나, removetoken은 더이상 의미가 없을 것 같다.)

추후, 확인 하고 내용 추가 예정...

HowTo - YCSB for Cassandra

Install/Configuration

설치/설정이라고 하지만, 특별한게 없다. Cassandra(v1.1.4) 및 JDK는 설치 되어 있다는 전제하에서 YCSB를 다운로드 하고 압축을 해제하는 것으로 완료.

• Machines: node1(172.21.81.139), node2(172.21.81.127)
• OS: Ubuntu 11.10 (oneiric) x86_64
• Cassandra: 1.1.4 (설치 위치: /usr/local/cassandra)
• JDK Version: "1.6.0_27"
• 테스트 작업 위치: /usr/local/src

# cd /usr/local/src/
# wget https://github.com/downloads/brianfrankcooper/YCSB/ycsb-0.1.4.tar.gz
# tar zxvf ycsb-0.1.4.tar.gz

YCSB 테스트를 위한 Cassandra 준비

YCSB & Cassandra 테스트를 위해서, Cassandra에 "usertable"라는 Keyspace에, data라는 Column Family가 필요하다.

KS/CF 생성

# /usr/local/cassandra/bin/cassandra-cli
# create keyspace usertable;
# use usertable;
# create column family data;

YCSB 테스트 실행

ycsb에 포함된 workload 들을 이용해 간단한 테스트를 실습을 수행 해본다.

ycsb의 Usage 및 Commands/Options 확인

# cd /usr/local/src/ycsb-0.1.4
# ./bin/ycsb
Usage: ./bin/ycsb command database [options]

Commands:
    load          Execute the load phase
    run           Execute the transaction phase
    shell         Interactive mode

Databases:
    basic         https://github.com/brianfrankcooper/YCSB/tree/master/basic
    cassandra-10  https://github.com/brianfrankcooper/YCSB/tree/master/cassandra
    cassandra-7   https://github.com/brianfrankcooper/YCSB/tree/master/cassandra
    cassandra-8   https://github.com/brianfrankcooper/YCSB/tree/master/cassandra
    gemfire       https://github.com/brianfrankcooper/YCSB/tree/master/gemfire
    hbase         https://github.com/brianfrankcooper/YCSB/tree/master/hbase
    infinispan    https://github.com/brianfrankcooper/YCSB/tree/master/infinispan
    jdbc          https://github.com/brianfrankcooper/YCSB/tree/master/jdbc
    mapkeeper     https://github.com/brianfrankcooper/YCSB/tree/master/mapkeeper
    mongodb       https://github.com/brianfrankcooper/YCSB/tree/master/mongodb
    nosqldb       https://github.com/brianfrankcooper/YCSB/tree/master/nosqldb
    redis         https://github.com/brianfrankcooper/YCSB/tree/master/redis
    voldemort     https://github.com/brianfrankcooper/YCSB/tree/master/voldemort

Options:
    -P file       Specify workload file
    -p key=value  Override workload property
    -s            Print status to stderr
    -target n     Target ops/sec (default: unthrottled)
    -threads n    Number of client threads (default: 1)

Workload Files:
    There are various predefined workloads under workloads/ directory.
    See https://github.com/brianfrankcooper/YCSB/wiki/Core-Properties
    for the list of workload properties.

Load 테스트 수행 (Execute the load phase: 초기 데이타 등록)

• Cassandra 1.1.4이므로, Database로 cassandra-10을 선택.
• 테스트 노드로 2개 장비 모두 사용. (hosts=172.21.81.139,172.21.81.127)
• 기타 추가 옵션 지정은 hosts와 마찬가지로 "-p" 옵션을 이용해, key=value형태로 지정/추가 해준다.
• Cassandra Database에 관련된 특화 옵션은 Usage에서 확인되는 git 웹페이지에서 확인 가능. (하단 <부록> 섹션 참고)

# ./bin/ycsb load cassandra-10 -P workloads/workloada -p hosts=172.21.81.139,172.21.81.127 -p cassandra.connectionretries=1 -p cassandra.operationretries=1
java -cp /usr/local/src/ycsb-0.1.4/slf4j-jdk14-1.7.2.jar:/usr/local/src/ycsb-0.1.4/slf4j-api-1.7.2.jar:/usr/local/src/ycsb-0.1.4/hbase-binding/conf:/usr/local/src/ycsb-0.1.4/voldemort-binding/conf:/usr/local/src/ycsb-0.1.4/nosqldb-binding/conf:/usr/local/src/ycsb-0.1.4/gemfire-binding/conf:/usr/local/src/ycsb-0.1.4/core/lib/core-0.1.4.jar:/usr/local/src/ycsb-0.1.4/cassandra-binding/lib/cassandra-binding-0.1.4.jar:/usr/local/src/ycsb-0.1.4/jdbc-binding/conf:/usr/local/src/ycsb-0.1.4/infinispan-binding/conf com.yahoo.ycsb.Client -db com.yahoo.ycsb.db.CassandraClient10 -P workloads/cassandra -p hosts=172.21.81.139 -p cassandra.connectionretries=1 -p cassandra.operationretries=1 -load
YCSB Client 0.1
Command line: -db com.yahoo.ycsb.db.CassandraClient10 -P workloads/cassandra -p hosts=172.21.81.139 -p cassandra.connectionretries=1 -p cassandra.operationretries=1 -load
Loading workload...
Starting test.
[OVERALL], RunTime(ms), 8666.0
[OVERALL], Throughput(ops/sec), 1153.9349180706208
[INSERT], Operations, 10000
[INSERT], AverageLatency(us), 820.3828
[INSERT], MinLatency(us), 147
[INSERT], MaxLatency(us), 35981
[INSERT], 95thPercentileLatency(ms), 1
[INSERT], 99thPercentileLatency(ms), 2
[INSERT], Return=0, 10000
[INSERT], 0, 6016
[INSERT], 1, 3877
[INSERT], 2, 47
[INSERT], 3, 30
[INSERT], 4, 5
[INSERT], 5, 8
[INSERT], 6, 4
[INSERT], 7, 1
[INSERT], 8, 2
[INSERT], 9, 4
[INSERT], 10, 2
[INSERT], 11, 0
[INSERT], 12, 0
[INSERT], 13, 0
[INSERT], 14, 0
[INSERT], 15, 1
[INSERT], 16, 0
[INSERT], 17, 0
[INSERT], 18, 0
[INSERT], 19, 0
[INSERT], 20, 1
[INSERT], 21, 0
[INSERT], 22, 0
[INSERT], 23, 0
[INSERT], 24, 0
[INSERT], 25, 1
[INSERT], 26, 0
[INSERT], 27, 0
[INSERT], 28, 0
.
.
(중략)
.
.
[INSERT], 987, 0
[INSERT], 988, 0
[INSERT], 989, 0
[INSERT], 990, 0
[INSERT], 991, 0
[INSERT], 992, 0
[INSERT], 993, 0
[INSERT], 994, 0
[INSERT], 995, 0
[INSERT], 996, 0
[INSERT], 997, 0
[INSERT], 998, 0
[INSERT], 999, 0
[INSERT], >1000, 0

Run 테스트 수행 (Execute the transaction phase)

# ./bin/ycsb run cassandra-10 -P workloads/cassandra -p hosts=172.21.81.139,172.21.81.127 -p cassandra.connectionretries=1 -p cassandra.operationretries=1
java -cp /usr/local/src/ycsb-0.1.4/slf4j-jdk14-1.7.2.jar:/usr/local/src/ycsb-0.1.4/slf4j-api-1.7.2.jar:/usr/local/src/ycsb-0.1.4/hbase-binding/conf:/usr/local/src/ycsb-0.1.4/voldemort-binding/conf:/usr/local/src/ycsb-0.1.4/nosqldb-binding/conf:/usr/local/src/ycsb-0.1.4/gemfire-binding/conf:/usr/local/src/ycsb-0.1.4/core/lib/core-0.1.4.jar:/usr/local/src/ycsb-0.1.4/cassandra-binding/lib/cassandra-binding-0.1.4.jar:/usr/local/src/ycsb-0.1.4/jdbc-binding/conf:/usr/local/src/ycsb-0.1.4/infinispan-binding/conf com.yahoo.ycsb.Client -db com.yahoo.ycsb.db.CassandraClient10 -P workloads/cassandra -p hosts=172.21.81.139,172.21.81.127 -p cassandra.connectionretries=1 -p cassandra.operationretries=1 -t
YCSB Client 0.1
Command line: -db com.yahoo.ycsb.db.CassandraClient10 -P workloads/cassandra -p hosts=172.21.81.139,172.21.81.127 -p cassandra.connectionretries=1 -p cassandra.operationretries=1 -t
Loading workload...
Starting test.
[OVERALL], RunTime(ms), 13476.0
[OVERALL], Throughput(ops/sec), 742.0599584446423
[INSERT], Operations, 5039
[INSERT], AverageLatency(us), 1280.7376463584044
[INSERT], MinLatency(us), 259
[INSERT], MaxLatency(us), 202840
[INSERT], 95thPercentileLatency(ms), 2
[INSERT], 99thPercentileLatency(ms), 4
[INSERT], Return=0, 5039
[INSERT], 0, 2774
[INSERT], 1, 1840
[INSERT], 2, 289
[INSERT], 3, 66
[INSERT], 4, 20
[INSERT], 5, 10
[INSERT], 6, 5
[INSERT], 7, 6
[INSERT], 8, 5
[INSERT], 9, 3
[INSERT], 10, 6
[INSERT], 11, 1
[INSERT], 12, 2
[INSERT], 13, 2
[INSERT], 14, 2
[INSERT], 15, 1
[INSERT], 16, 0
[INSERT], 17, 1
[INSERT], 18, 1
[INSERT], 19, 0
[INSERT], 20, 1
[INSERT], 21, 0
[INSERT], 22, 0
[INSERT], 23, 1
[INSERT], 24, 0
[INSERT], 25, 1
[INSERT], 26, 0
.
.
(중략)
.
.
[INSERT], 994, 0
[INSERT], 995, 0
[INSERT], 996, 0
[INSERT], 997, 0
[INSERT], 998, 0
[INSERT], 999, 0
[INSERT], >1000, 0
[READ], Operations, 4961
[READ], AverageLatency(us), 1323.8699858899415
[READ], MinLatency(us), 298
[READ], MaxLatency(us), 61646
[READ], 95thPercentileLatency(ms), 2
[READ], 99thPercentileLatency(ms), 4
[READ], Return=0, 4961
[READ], 0, 2226
[READ], 1, 2260
[READ], 2, 362
[READ], 3, 57
[READ], 4, 13
[READ], 5, 7
[READ], 6, 7
[READ], 7, 7
[READ], 8, 4
[READ], 9, 1
[READ], 10, 3
[READ], 11, 2
[READ], 12, 3
[READ], 13, 3
[READ], 14, 1
[READ], 15, 0
[READ], 16, 2
[READ], 17, 0
.
.
(중략)
.
.
[READ], 989, 0
[READ], 990, 0
[READ], 991, 0
[READ], 992, 0
[READ], 993, 0
[READ], 994, 0
[READ], 995, 0
[READ], 996, 0
[READ], 997, 0
[READ], 998, 0
[READ], 999, 0
[READ], >1000, 0

workload

기본적으로 제공되는 workload는 하기와 같이 6가지가 제공된다.
(각각이 추구하는 목적은 링크 https://github.com/brianfrankcooper/YCSB/wiki/Core-Workloads 참조)

• workloada
• workloadb
• workloadc
• workloadd
• workloade
• workloadf

workload 예제 설명

예제로 workloadf를 살펴보자

recordcount=1000
operationcount=1000
workload=com.yahoo.ycsb.workloads.CoreWorkload

readallfields=true

readproportion=0.5
updateproportion=0
scanproportion=0
insertproportion=0
readmodifywriteproportion=0.5

requestdistribution=zipfian

위와 같은 내용을 담고 있으며, 각각의 역할을 명칭에서 드러난다.
[Note] File 참조가 싫으면, 하기와 유사하게 "-p" 옵션을 이용해 하나 하나 지정해줘도 된다. 
예를 들어 하기와 같이, 각자의 테스트 목적에 부합되게 설정하여 사용하면 될 것이다.

# ./bin/ycsb \ 
run \ 
cassandra-10 \
-s \ 
-p recordcount=10000 \
-p operationcount=10000 \
-p workload=com.yahoo.ycsb.workloads.CoreWorkload \
-p readallfields=true \
-p readproportion=0.5 \
-p updateproportion=0 \
-p scanproportion=0 \
-p insertproportion=0.5 \
-p readmodifywriteproportion=0 \
-p requestdistribution=zipfian \
-p hosts=172.21.81.139,172.21.81.127 \
-p cassandra.connectionretries=1 \
-p cassandra.operationretries=1 \
-p cassandra.readconsistencylevel=ALL \
-p cassandra.writeconsistencylevel=ALL \
-p cassandra.deleteconsistencylevel=ALL \
-threads 10 

• 전체 몇개의 Count로 테스트를 할 것인지...
• 전체 테스트 Count에서 read/update/scan/insert/readmodifywrite의 비율은 어떻게 할 것인지...

부록

Cassandra Database 특화 옵션

Source:https://github.com/brianfrankcooper/YCSB/blob/master/cassandra/src/main/java/com/yahoo/ycsb/db/CassandraClient10.java

  public static final String CONNECTION_RETRY_PROPERTY = "cassandra.connectionretries";
  public static final String CONNECTION_RETRY_PROPERTY_DEFAULT = "300";

  public static final String OPERATION_RETRY_PROPERTY = "cassandra.operationretries";
  public static final String OPERATION_RETRY_PROPERTY_DEFAULT = "300";

  public static final String USERNAME_PROPERTY = "cassandra.username";
  public static final String PASSWORD_PROPERTY = "cassandra.password";

  public static final String COLUMN_FAMILY_PROPERTY = "cassandra.columnfamily";
  public static final String COLUMN_FAMILY_PROPERTY_DEFAULT = "data";

  public static final String READ_CONSISTENCY_LEVEL_PROPERTY = "cassandra.readconsistencylevel";
  public static final String READ_CONSISTENCY_LEVEL_PROPERTY_DEFAULT = "ONE";

  public static final String WRITE_CONSISTENCY_LEVEL_PROPERTY = "cassandra.writeconsistencylevel";
  public static final String WRITE_CONSISTENCY_LEVEL_PROPERTY_DEFAULT = "ONE";

  public static final String SCAN_CONSISTENCY_LEVEL_PROPERTY = "cassandra.scanconsistencylevel";
  public static final String SCAN_CONSISTENCY_LEVEL_PROPERTY_DEFAULT = "ONE";

  public static final String DELETE_CONSISTENCY_LEVEL_PROPERTY = "cassandra.deleteconsistencylevel";
  public static final String DELETE_CONSISTENCY_LEVEL_PROPERTY_DEFAULT = "ONE";

[PDF] Link - Cassandra High Performance Cookbook¶

http://zopub.com/download?doc_id=519

YCSB 사용할 일이 반복적으로 많아 질것 같아 Script 처리를 하면 좀 편해질까 싶어 막스크립트 작성중... 우선은 Cassandra가 직접적으로 관련이 있어 cassandra-10만 우선 지원.(cassnadra-7,8도 동일하게 가능할듯...)

기능은 단순하다.

- ycsb 명령 줄의 parameter들을 다이얼로그 형태로 지원하는 것일 뿐....

- 그일 첨 시작이라 테스트 해보고 써억~ 편의점이 없다면 과감히 휴지통으로 고고~

실행 예)

ycsb_runner.sh

http://redmine.nehome.net/redmine/projects/nosql/wiki/Cassandra_-_Replica-Strategy_and_Snitch-Strategy_and_Partitioner-Strategy

Replica-Strategy

• Keyspace 생성시 설정한다.
  

  [default@unknown] CREATE KEYSPACE score with placement_strategy='org.apache.cassandra.locator.NetworkTopologyStrategy' and strategy_options={0:3};
  

• Cluster내에서 Replica들을 어떻게 분산 시킬지를 결정
• Type에는 2가지 지원
  • SimpleStrategy
  • NetworkTopologyStrategy

SimpleStrategy

• Row키에 대한 MD5 Hash결과에 의해 Data저장 노드가 결정되면, 무조건 Ring에서 시계방향으로 바로 다음(Next) 노드들에게 Replica를 배치 시키는 방식.
• 뒤에 나올 내용인 Snitch-Strategy의 설정은 모두 무시된다. 단순히 Ring의 시계방향만 고려됨.

NetworkTopologyStrategy

• 먼저 Cassandra에서 말하는 "DataCenter"란?
  

  Replication-Group(복제 그룹)을 의미 하며, 복제를 목적으로 클러스트 내에서 묶여진 논리적인 그룹이다.주의할 것은 물리적인 DataCenter을 의미하는 것이 아님.
  

• DataCenter/Rack에 걸쳐 정확하게 Replica를 배치 하기위해 Snitch정보에 의존적이다.
• SimpleSnitch 모드가 아닌 Snitch-Strategy에 의해 정의된 Replication-Group(or Each DataCenter)정보를 기준으로 Replica를 적절히 배치.
• Replica 배치는 각각의 DataCenter별로 독립적으로 설정한다.(비대칭 Replica 수 운영 가능)
  

  DC1에는 3개, DC2에는 2개 이런식으로...
  

• 첫 Replica들은 각각의 DataCenter들에 우선적으로 하나씩 결정(배치)된다.(by Partitioner)
• 나머지 Replica들은 각각의 DataCenter들에 지정된 갯수만큼 배치되는데, 이때 Snitch정보인 Replication-Group정보(Rack)를 참조해서, 각 DataCenter의 Ring정보에서 시계방향으로 돌면서, 이전 Replica와 비교해 동일 Replication-Group이 아닌 Rack이 나올때까지 검색해서 배치한다.
• 단, 분리 배치 할 노드가 부족할 경우에는 동일 Rack이라도 배치하게 된다.
• 얼마나 많은 Replica를 사용할지를 결정할 때 고려해야 할 것
  • DataCenter간의 지연시간을 투자하지 않고, 로컬의 데이타(Local-Data)를 읽을 수 있게 한다.
  • 여러가지 장애 상황에 대한 대처가 가능해야 한다.
• Multi-DataCenter구조하에서 아래와 같은 2가지 방법이 추천된다.
  • 각각에 DataCenter에 2개의 Replica를 두는 것.
    • Replication-Group당 하나의 노드장애를 커버 가능하고, 장애상황하에서 "Consistency-Level ONE"으로 Local-Data 읽기가 가능.
  • 각각의 DataCenter에 3개의 Replica를 두는 것.
    • "Strong Consistency Level Local_QUORUM"모드에서, Replication-Group당 하나의 노드장애를 커버 가능하거나, "Consistency-Level ONE"모드에서는 Replication-Group당 다중(2대) 노드의 장애가 커버 가능.
• Snitch는 복제 범위 내에서 효율적으로 노드간 통신을 하며, 클라이언트 응용프로그램과 카산드라 사이의 요청처리에는 여향을 미치지 않는다.
• Cluster의 모든 노드는 동일한 Snitch를 사용해야 한다.(cassandra.yaml)

Snitch-Strategy

• Snitch ??
  

  노드가 전체 네트워크 토플로지에서 그룹화 되는 방법을 정의 하는 역할
  

SimpleSnitch

• cassandra.yaml 에서 설정.
• DataCenter/Rack에 대한 구분이 없다.
• Partitioner에 의해 저장될 노드가 정해지면, Replica에 대해서는 무조건 시계방향으로 나머지 Replica개수 만큼 Next(다음) 노드들에게 순차적으로 배치 시킨다.

RackInferringSnitch

• 클러스트 내에서, 노드의 IP정보를 기반으로 그룹화 한다. (옥텟 기반)
• IP가 10.DDD.RRR.NNN 이라고 한다면,
  • DDD값은, DataCenter를 의미, 동일하면 같은 DataCenter로 간주.
  • RRR값은, Rack을 의미, 동일하면 같은 Rack으로 간주.
  • NNN값은, 노드를 구분.
• DDD와, RRR 값이 중요하다.
• NetworkTopologyStrategy와 사용하면 유리.

PropertyFileSnitch

• 클러스트 내에서, 노드들의 그룹화를 특정 속성파일(cassandra-topology.properties)을 통해 정의 한다.
• 모든 노드정보를 속성파일에 기술해야 한다. (관리의 번잡)
• 모든 노드는 동일 속성파일을 유지 해야 한다.
• 관리 정보는 RackInferringSnitch와 유사
  • 노드별 DataCenter/Rack 정보 정의

Partitioner

• cassandra.yaml 에서 설정.
• Data(Replica가 아님)가 저장될 노드를 결정하는 방식 정의.

RandomPartitioner (RP)

• Data의 Row-Key에 대해 MD5 Hash값을 기준으로, 저장할 노드 결정.
• Data가 어느 노드에 저장될지 예측 불가.
• 저장과 동시에 정렬 불가.
  • Full-Text Search 불가.
  • Range Scan 불가.
  • 부하 분산 유리.
  • 확장성/Data재분배 유리(가능)

ByteOrderedPartitioner (BOP)

• Data의 Row-Key 자체가 노드가 된다.
• Row-Key값으로 노드가 결정되므로, 저장과 동시에 정렬이 된다.
  • Full-Text Search 가능.
  • Range Scan 가능.
  • 부하 분산 불균형
  • 확장성/Data재분배 불리(어려움)