http://redmine.nehome.net/redmine/projects/nosql/wiki/Cassandra_-_Replica-Strategy_and_Snitch-Strategy_and_Partitioner-Strategy
Replica-Strategy
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
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재분배 불리(어려움)
