[cassandra] read repair

카산드라에는 read repair(한국어로 굳이 번역하면 읽기 보수 정도?) 라는 것이 있다.

Eventually consistency를 제공한 것은 성능을 포기할 수 없기 때문인데..

데이터의 동기화를 하지만 완벽하지 않을 수 있다. 언제든지 데이터가 이슈가 될 수 있어서 read repair로 데이터의 이슈를 보정할 수 있다. read할 때 quorum으로 하면 데이터를 안전하게 최신 데이터의 맞춰 가져올 수 있다. 

https://docs.datastax.com/en/cassandra/2.1/cassandra/operations/opsRepairNodesReadRepair.html

https://docs.datastax.com/en/cassandra/2.1/cassandra/dml/dmlClientRequestsRead.html

http://www.datastax.com/dev/blog/common-mistakes-and-misconceptions

하지만, read repair를 한다는 것은 성능의 저하를 발생시킬 수 있는 부분이 있다. 

read_repair_chance의 기본 값이 0.1일 텐데. 0으로 바꾸면 성능 저하가 없을 수 있다. 

만약 write : 1, read: quorum으로 하면 read_repiar_chance의 값을 높일 수도 있을 것이다.

CRDT관점으로 설명된 카산드라

https://aphyr.com/posts/294-jepsen-cassandra

merge하는 부분을 잘 보면 좋을 것 같다.

* 주의할 점

DateTieredCompactionStrategy에는 read repair를 포함하기 때문에 read_repair_chance를 0으로 해야 한다.. 기본 정책은 0.1이기 때문에 cassandra.yml 파일을 수정해서 재시작을 해야 한다. 따라서 테이블에 DateTieredCompactionStrategy의 사용을 주의해서 써야 한다.

The compaction strategy DateTieredCompactionStrategy precludes using read repair, because of the way timestamps are checked for DTCS compaction. In this case, you must set read_repair_chance to zero. For other compaction strategies, read repair should be enabled with a read_repair_chancevalue of 0.2 being typical.

-----

qcon london에서 crdt 내용이 나왔다. 

https://qconlondon.com/london-2016/system/files/presentation-slides/matthiaspeter.pdf