[cassandra] 카산드라 팁 - 조심히 사용해야 할 내용

1. where 절의 in

in을 사용할 때는 많은 키의 정보를 한 번에 읽어야 할 때, 최대한 작게 사용하는 것이 좋다. 

read를 QUORUM으로 설정했다면 최대 2개 노드에 요청하기 때문에, 100개의 키를 사용한다면, 최대 200번을 호출해서 결과를 얻어올 것이다.

2. Paging (limit)

데이터가 어느 정도 많아지면 limit을 써서 pagination을 하는 것이 성능에 문제 없다.  

데이터가 많아지면 timeout이 발생할 수 있다. 개인적으로는 백 만개의 row도 20개 씩 읽으면 문제가 없다. 

3. secondary index

secondary index는 데이터가 클러스터내에서 동기화되지 않고 노드에만 저장되어 있다. 따라서 만약 secondary index만 가지고 select문을 사용한다면 해당 노드에 요청해 scan all을 하게 된다. 따라서 반드시 써야 한다면 값의 범위가 광범위하지 않는 것이 좋다(빨리 검색될 수 있는 컬럼이어야 한다)

데이터가 적을 때나 쓸만한 index이다. 대용량에서는 쓰면 안된다. 

secondary index가 없으면 allow filtering를 사용해야 하는데..(사실 이런 쿼리를 만들었다면 다시 만들어야 한다. 잘못 만든 모델링이다) 성능 이슈가 발생한다. 

이런 문제로 cassandra 3.4부터 SSTable Attached Secondary Index (SASI)가 추가되었다. 인덱스가 별도 테이블이 아니라 SSTable에 존재하도록 하여 조금 좋아지게 했다고 한다. 

https://docs.datastax.com/en/cql/3.3/cql/cql_using/useSASIIndex.html

CREATE INDEX d_index ON crizin(d) USING 'org.apache.cassandra.index.sasi.SASIIndex';

4. 잦은 삭제

작은 삭제는 tombstone과 gc를 유발시킬 수 있다. 

데이터가 삭제되면 gc_grace_seconds(기본 값: 864000)로 되어 있어서 10일간은 그대로 남아 있고, tombstone이라고 하지만 사실 데이터가 있다. 따라서, 검색(select)할 때 tombstone도 스캔한다. 따라서 작은 삭제가 일어나는 테이블은 gc_grace_seconds를 수정할 필요가 있을 수도 있다. 

5. strong consistency 욕심

http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html

strong consistency를 주기 위해 write할 때 consistency를 all로 주고 read할 때 consistency를 one으로 줄 수 있다.

단점은 노드가 하나라도 문제가 있어서 데몬이 내려가 있다(node failure)면, UnavailableException 예외가 발생할 것이다. QUORUM 또는 LOCAL_QUORUM이 나을 수 있다.

strong consistency를 높이려면 replication factor보다는 read consistency level과 write consistency level을 잘 잡는게 중요하다(말은 이렇게 하지만, 실제 상용 서비스에 적용할 때는 가장 어려운 것 같다..트레이드 오프와 node repair에 대한 고민은 늘 존재한다)

6. 데이터 복구 (data repairing)

데이터가 별로 사용하지 않는 곳, 서비스에 영향을 주지 않는 곳에서는 nodetool repair 를 사용해도 큰 이슈는 없지만, 대용량에서는 어마어마한 일이 벌어질 수 있다. 공부를 많이 하고 효과적인 전략을 세워야 한다. 

(cassandra summit 슬라이드 보면 관련 내용이 많다. )

(블로그에 내용을 따로 작성하고 있다. 즉, 운영을 어느 정도 해보고 자신있을 때 진행하는 게 좋다. 잘못하면 서비스 장애 가 발생할 수 있다.)

7. 여러 클러스터로 사용

하나의 클러스터에 이런 저런 용도의 테이블을 저장하기 보다는 여러 클러스터로 나누어 테이블을 저장하는 것이 좋다. compaction은 side effect가 존재할 수 있다. Hbase처럼 최대한 클러스터를 분리시키는 것이 훨씬 낫다.