ScyllaDB 테스트 마무리

:: ScyllaDB 소개 및 테스트 바로가기 ::

ScyllaDB 소개

Scylla vs. Cassandra benchmark 따라하기 1 : VirtualBox에서 테스트

Scylla vs. Cassandra benchmark 따라하기 2 : 사내 개발장비 테스트

Scylla vs. Cassandra benchmark 따라하기 3 : AWS 테스트

ScyllaDB 테스트 마무리

이전 포스트에서는 3차례에 걸쳐서 ScyllaDB vs. Cassandra Benchmark를 테스트해봤다. 3번에 걸친 테스트에서 ScyllaDB에서 주장하는 10배의 성능 향상을 직접 확인하지는 못했다. 그렇다고 ScyllaDB가 홈페이지에서 정확하지도 않은 내용을 주장하는 것은 아니다.

테스트 환경이 제한적이다보니 10배의 성능 향상을 확인 못한 것이지 ScyllaDB에서 테스트한 것과 동일한 사양으로 테스트를 진행한다면 충분히 가능할 것이라 생각한다.

중간 규모의 서비스에서는 Cassandra를 운영한다 하더라도 시스템 사양을 24Core/128Gb로 맞추기는 힘들다. 그나마 적절한 수준이 8~16Core/32Gb일 것이고 현실적으로는 8Core/16Gb정도의 사양으로 운영하게 될 수 있다.

사내 개발장비를 통해서 진행한 테스트(ScyllaDB vs. Cassandra benchmark 따라하기 2 : 사내 개발장비 테스트)가 현실과 가장 유사할 수 있다.

사내 개발장비 테스트에서 보여준 ScyllaDB의 성능은 "그럭저럭한 Request 부하에서는 Cassandra에 가까운 성능을 보여준다"고 할 수 있다. 하지만 AWS를 통한 테스트(ScyllaDB vs. Cassandra benchmark 따라하기 3 : AWS 테스트)에서 확인할 수 있었던 것 처럼 "Request가 증가할수록 ScyllaDB는 Cassandra보다 더 좋은 성능을 보여준다"는 것을 확인할 수 있었다.

지금까지 확인된 사실을 바탕으로 ScyllaDB와 Cassandra의 성능을 짐작해보면 다음과 같이 표현할 수 있다.

<그림 1. Cassandra와 ScyllaDB의 초당 Request 증가에 따른 TPS 변화 예상>

적절한 시스템 사양만 갖춘다면 "Redis의 속도를 가진 Cassandra"를 갖는 것이 불가능하지만은 않다고 보인다.

<그림 2. Redis의 속도를 가진 Cassandra>

만약 현재 Cassandra를 운영하고 있는 경우라면 2016년 1월에 ScyllaDB GA버전이 나온 후 ScyllaDB로 교체하는 것을 고려해볼만한 가치가 있는 것 같다. 

그리고 rowkey, column name 등이 정렬된다는 특징을 이용하면 Message Queue, Time Series DB, CEP 등을 구현하는데 매우 유용할 수 있을 것 같다.