Cassandra 세컨더리 인덱스의 위험 이유 및 대응 방안

Primary Key

카산드라에서 Primary Key는 1개 이상의 파티션 키 + 0개 이상의 클러스터링 키로 구성된다.

먼저 파티션 키는 분산 키로, 파티션 키를 통해 링에 속한 노드 중 데이터가 위치한 노드를 찾는다

• 파티션 키를 사용해서 해시 함수를 통해 계산된 토큰(해시 값)을 사용해서 데이터가 속한 노드를 찾는다.
• 한 파티션 내에서 클러스터링 키를 통해서 컬럼들을 정렬해서 저장하는 구조

Secondary Index

Secondary Index는 Partition Key의 일부가 아니다. 이러한 이유로 카산드라 클러스터 중 어떤 노드에 해당 데이터가 있는지 알 수 없다.

결국 Cassandra에서 Secondray Index로 데이터를 찾으려면 링에 속한 모든 노드를 찾아야만 한다.

이러한 특성 때문에, Primary Index로 조회하는 경우 한 번의 쿼리를 요청하면 1개의 디스크에서 읽는다. 반면 Secondary Index로 조회하는 경우 한번의 쿼리가 N개의 노드에서 디스크를 읽어와야 한다. (와우...)

• 노드를 스케일 아웃하면 할 수록 READ에 대한 성능이 떨어진다.

⇒ 카산드라 세컨더리 인덱스 왠만하면 사용하지 말자..

방안

• 세컨더리 인덱스 대신 역 인덱스 키(테이블)을 추가로 둬서, 듀얼라이트 하는 식으로 구성하는 편이 나음.
  • 단 추가적인 키가 늘어날수록, Write 비용이 증가하니, 적당하게 사용해야 할듯.
• 듀얼 라이트시, 두 테이블에 대한 원자성 보장이 필요한 경우, Batch Operation 통해 원자성을 보장할 수 있음.
  • Batch Operation 관련 내용 -> https://willseungh0.tistory.com/198
• Batch Operation 특성상, 성능 하락이 있을 수 있어, 적절하게 사용해야 한다. (관련 내용은 위의 링크 참고 부탁드립니다.