[발 번역] Cassandra의 Read에 대하여

해당 블로그는 KT UCloud의 지원을 받고 있습니다.

해당 포스트는 http://www.datastax.com/docs/1.1/dml/about_reads 을 발 번역한 것입니다. 얼마 전에 카산드라의 Write 에 대해서 올렸는데, Read는 양이 적어서 금방 할 수 있을 것 같아서, 같이 진행하였습니다. Oracle, MySQL등의 RDBMS는 사용자도 많고, 이에 대한 트러블 슈팅을 가진 사람들도 많습니다. NoSQL등의 경우는 그에 비해 사용자도 적고 문제를 공유할 사람들도 적은게 사실입니다. 다만, Oracle, MySQL에서도 내부 구조를 이해하면 개발 시에 편리하지만, NoSQL은 필수로 알아야만 잘 이용할 수 있습니다.

About Reads in Cassandra

하나의 노드에 속한 row 에 읽기 요청이 오면, 응답을 하기 위해서 해당 row는 해당 row에 속하는 컬럼을 포함한 노드에 속하는 모든 SSTable 로 부터 결과를 조합해야 하고, 모든 디스크로 flush 되지 않은 memtable 들로 부터, 정보를 조합해야 합니다. 이런 문제를 효율적으로 처리하기 위해서, 카산드라는 메모리 내에 Bloom filter 라는 것을 이용합니다. 각각의 SSTable은 다른 I/O가 일어나기 전에 요청된 row가 해당 SSTable 에 존재하는지 확인하기 위해서 Bloom Filter를 가지고 있습니다. 그 결과, 카산드라는 다른 스토리지 시스템에 비해서 매우 읽기 부하가 심할때를 포함해서 읽기 성능이 좋습니다.

 

다른 데이터베이스와 마찬가지로, 대부분의 요청 데이터가 메모리에 들어가 있으면 매우 빠릅니다. 자주 요청되는 데이터에 대한 빠른 접근을 위해서 모든 현대의 스토리지 시스템이 몇가지 형태의 캐시를 제공함에도 불구하고,  캐시 용량을 초과하면, 모든 시스템이 성능 저하를 겪게 되고, 디스크 I/O가 필요해집니다.  카산드라의 읽기 성능은 캐시 안에 있을 때 이점이 크지만, 랜덤 디스크 액서스가 필요한 상황에도 극단적으로 느려지지는 않습니다. 읽기 부하가 늘어나 카산드라 내부에 I/O 가 많아지기 시작하면, 클러스터에 새로운 노드를 추가하므로써 쉽게 해결할 수 있습니다.(역자 주: 카산드라 클러스터가 부하가 많은 상황에 서버를 한 번에 많이 추가하면, 해당 서버로 리플리케이션 해야되는 데이터를 가진 서버들의 부하가 함께 늘어나므로, 카산드라는 서버를 한번에 적게 추가하는 것이 좋습니다. )

 

row가 빈번하게 요청되는 것을 위해, 카산드라는 내부적으로 key cache 를 만들어 두었습니다.( 추가적인 row 캐시 ).  캐싱 기능을 이용한 읽기 성능 최적화에 대한 좀 더 설명이 필요하면 Tuning Data Caches 를 보시기 바랍니다.(역자 주: 전체 SSTable을 뒤져야 하는 부담 때문에, 카산드라에서는 Row 캐시를 제공합니다. 다만 해당 기능은 기본적으로는 꺼져있습니다. )

 

카산드라에서 클라이언트의 읽기, 쓰기 요청이 어떻게 처리되는지 자세한 정보가 필요하면, 다음 About Client Requests in Cassandra 페이지를 보시기 바라니다.