성능 벤치마크

야후! 클라우드 서비스 벤치마크(YCSB)는 NoSQL 제품 비교와 관련해 가장 유명한 벤치마킹 인프라스트럭처다. YCSB에 제약이 없는 건 아니지만 각기 다른 NoSQL 제품이 어떤 성능을 보여주는지 잘 보여준다. YCSB 툴킷에는 다음과 같은 두 가지 유용한 유틸리티가 들어 있다.

• 워크로드 생성기
• 워크로드 생성기가 사용하는 샘플 로드

YCSB 프로젝트의 온라인 사이트는 https://github.com/brianfrankcooper/YCSB다. 야후!는 벤츠마크에서 여러 인기 있는 NoSQL 제품에 대한 테스트를 수행했다. 가장 최근에 공개된 결과에는 다음과 같은 대상이 포함된다.

• Sherpa/PNUT 빅테이블 유사 시스템(HBase, 하이퍼테이블, HTable, 메가스토어)
• 애저
• 아파치 카산드라
• 아마존 웹 서비스(S3, 심플디비, EBS)
• 카우치디비
• 볼드모트
• 다이노마이트
• 토쿄 캐비넷
• 레디스
• 몽고디비

테스트는 각 단에서 지연 시간과 스루풋을 측정하기 위해 각 단별로 수행됐다. 1단에서는 주어진 하드웨어상에서 워크로드를 최대화함으로써 성능을 측정하는 데 집중한다. 하드웨어는 동일하게 유지한 채 하드웨어가 포화 상태가 될 때까지 워크로드를 증가시킨다. 2단에서는 확장 가능성에 초점을 둔다. 이 말은 워크로드가 늘어남에 따라 하드웨어를 추가한다는 뜻이다. 2단의 벤치마크에서는 워크로드 및 하드웨어 가용성이 늘어남에 따른 지연 속도를 측정한다.

워크로드는 균형 잡힌 철저한 테스트를 위해 성능 및 확장 가능성을 측정할 수 있는 다양한 설정을 갖고 있다. 인기 있는 테스트 케이스는 다음과 같다.

50/50 읽기 및 업데이트

50/50 읽기 및 업데이트 시나리오는 업데이트 중심 테스트 케이스로 간주된다. 이 테스트 케이스에서의 결과를 보면 아파치 카산드라가 읽기 및 업데이트 지연 시간에서 월등한 성능을 보인 것을 알 수 있다. HBase도 거의 유사한 성능을 보여줬지만 카산드라에는 뒤처졌다. 카산드라는 평균 25밀리초의 읽기 지연 시간으로 초당 10,000개의 작업(50/50 읽기 및 업데이트) 이상을 할 수 있다. 업데이트 작업은 초당 10,000개 이상의 작업을 수행하면서 지연 시간이 평균 10밀리초 정도로, 읽기보다 더 우수한 것으로 드러났다. YCSB에서는 NoSQL 제품뿐 아니라 MySQL 제품도 테스트한다. 이 장에서는 RDBMS와 NoSQL의 벤치마크 비교에 대해서는 무시하고 있지만, MySQL의 경우 읽기 및 쓰기 지연 시간이 4,000개 정도의 작업까지는 비슷한 수준을 유지하다가 초당 작업이 5,000개를 넘어서는 순간 빠르게 늘어나는 경향이 있다는 점은 참고할 만하다.

95/5 읽기 및 업데이트

95/5 읽기 및 업데이트 테스트 케이스는 읽기 중심의 테스트 케이스다. 이 테스트 케이스는 정렬 칼럼 패밀리 저장소가 연속적인 범위 읽기에 있어서 가장 성능이 좋다고 주장한 이 장의 몇 가지 이론을 확인시켜준다. HBase는 초당 작업 개수와 상관없이 읽기에 대해 일관된 성능을 제공하는 것으로 보인다. HBase에서 5퍼센트의 업데이트는 거의 지연 시간이 없다. MySQL은 읽기 전용 케이스에서 가장 좋은 성능을 전달한다. 이는 데이터가 캐시로부터 반환되기 때문이다. HBase를 Memcached나 멤베이스 같은 분산 캐시와 결합하면 MySQL의 읽기 성능에 견줄 만한 성능이 나오고, 작업량이 증가함에 따라 확장성도 개선할 수 있다.

카산드라도 읽기 중심 케이스에서 상당한 성능을 보여주고, 테스트에서 HBase를 능가했다. 하지만 카산드라는 궁극적인 일관성 모델을 따른다는 점과 모든 쓰기가 커밋 로그에 첨부된다는 사실을 기억해야 한다.

스캔

HBase는 짧은 1-100 레코드 및 범위 스캔에 있어서 다른 데이터베이스보다 성능이 좋도록 설계됐고 테스트도 이를 확인시켜준다. 카산드라는 스캔과 관련해서는 예측할 수 없는 성능을 보여준다.

확장성 테스트

작업량이 늘어나고 하드웨어가 추가됨에 따라 카산드라와 HBase에서는 성능이 꽤 일관된 모습을 보여줬다. 일부 결과는 세 개 미만의 노드가 있을 때 HBase가 불안정한 상태에 처하는 것을 보여준다. 하드웨어를 추가함에 있어 중요한 점은 바로 탄력성이다. 탄력성은 노드를 추가함에 따라 데이터가 어떻게 리밸런싱되는지를 측정한다. 카산드라는 낮은 성능을 보여주고 안정화되기까지 많은 시간이 걸리는 것으로 드러났다. HBase는 리밸런싱에 따라 성능이 컴팩션의 영향을 받는다는 것을 보여준다. 앞에서 말한 것처럼 성능 테스트는 전체적인 상황을 알려주기는 하지만 테스트에만 의존해 결정을 내리면 잘못된 결정에 이를 수 있다. 또 제품들이 계속해서 발전하고 있고 다른 제품 버전을 테스트하면 또 다른 결과가 나온다. 성능 측정 결과뿐 아니라 기능을 토대로 한 비교를 병행해야 좀 더 현명한 선택을 할 수 있다.

Note

하이퍼테이블 테스트는 YCSB 테스트에 포함되지 않는다. 하이퍼테이블 테스트 및 YCSB 테스트는 별도의 독립 테스트다. YCSB 테스트는 다양한 NoSQL 및 RDBMS 제품을 대상으로 적용하는 데 반해 하이퍼테이블 테스트는 정렬 칼럼 패밀리 저장소의 테스트에만 초점을 맞춘다.

하이퍼테이블 테스트

하이퍼테이블 팀은 구글 빅테이블 복제품인 HBase와 하이퍼테이블을 비교, 대조하기 위한 테스트를 수행했다. 이 테스트에서는 재미있는 결과를 볼 수 있다. 이 테스트는 구글 빅테이블에 대한 연구 논문에서 제안한 방식과도 긴밀한 연관이 있다. 이 테스트를 이해하려면 http://research.google.com/archive/bigtable.html에서 빅테이블 연구 논문의 7절을 읽어보자.

이 결과에서는 대부분의 성능 측정에서 하이퍼테이블이 HBase보다 성능이 우수하다는 점을 일관되게 보여준다. 테스트의 세부 내용 및 결과는 http://hypertable.com/why_hypertable/hypertable_vs_hbase_2/에서 볼 수 있다.

이어서 중요한 측정 결과를 살펴보자.

하이퍼테이블은 작업량에 따라 각 하위 시스템으로 얼마만큼의 메모리를 할당할지 동적으로 조절한다. 읽기 중심 테스트 케이스에서 하이퍼테이블은 대부분의 메모리를 블록 캐시에 할당한다. HBase는 고정 캐시 할당 방식을 갖고 있으며, 이 캐시는 자바 힙 메모리의 20퍼센트다. 지연 시간 관점에서 보면 하이퍼테이블이 HBase보다 지연 시간이 적다는 점을 명확히 알 수 있다. 이런 차이는 데이터 크기가 작을 때 더 분명히 드러난다. 2GB의 최소 데이터만 사용하는 경우 모든 데이터가 캐시에 로드될 수 있다.

랜덤 쓰기, 순차 읽기, 스캔 성능과 관련한 하이퍼테이블 및 HBase의 테스트 결과는 하이퍼테이블이 각 경우마다 더 나은 성능을 보여줬음을 보여준다. 대용량 데이터를 관리하기 위해 클러스터 데이터 저장소를 운영할 때 때로는 이와 같은 성능 차이가 큰 비용을 초래할 수 있다. 더 나은 성능은 더 낮은 컴퓨터 사이클 및 리소스 소비로 이어지는 만큼, 많은 비용을 절약할 수 있다.

그 외 다양한 벤더의 여러 벤치마크 결과도 다음과 같이 확인할 수 있다.

• 도쿄 캐비넷 벤치마크 : http://tokyocabinet.sourceforge.net/benchmark.pdf
• 레디스 속도 측정 : http://redis.io/topics/benchmarks
• 리악 벤치마크 : https://bitbucket.org/basho/basho_bench/
• VoltDB: 키/값 벤치마크 : http://voltdb.com/blog/key/value-benchmarking
• 정렬 벤치마크 : http://sortbenchmark.org/

맥락 비교

앞의 두 절에서는 기능과 벤치마크 관점에서 NoSQL 옵션을 비교했다. 이 절에서는 NoSQL 제품의 개발 및 발전을 초래한 조건과 관련한 맥락 정보를 제공한다.

모든 NoSQL 제품이 동일하지는 않다. 또 모든 NoSQL 제품이 기능 및 벤치마크와 관련해 동일한 성능을 보여주지도 않는다. 하지만 각 NoSQL 제품은 자체 역사, 동기, 사용 사례, 고유 가치 제안이 있다. 각 제품의 역사 및 발전 과정에 대한 이해를 토대로 이들 제품을 바라보면 어떤 NoSQL 제품을 사용하는 게 적합한지 좀 더 명확히 이해할 수 있을 것이다. 인기 있는 도큐먼트 데이터베이스와 관련해 다음의 인터넷 자료를 살펴보자.

• 카우치디비 : 카우치디비의 개발자인 다미엔 카츠가 개인적인 관점에서 카우치디비의 개발 역사에 대해 설명하는 얼랭 팩터리의 2009년 세션 동영상(http://www.erlang-factory.com/conference/SFBayAreaErlangFactory2009/speakers/DamienKatz)을 보자. 다미엔은 카우치디비에 대한 영감에 대해서 얘기하면서, 왜 좀 더 작은 집으로 아내와 아이들을 이주시키고 저금해둔 돈에 의지해 살면서 데이터베이스를 개발하기로 결정했는지 얘기한다. 또 얼랭으로 전환하고 아파치 재단에 참여하기로 한 결정에 대해서도 얘기해준다. 이 동영상은 제품을 만든 동기와 이유를 알려준다.
• 몽고디비 : 크리스티나 코드로우가 자신의 블로그에 쓴 몽고디비에 대한 비공식적 역사(http://www.snailinaturtleneck.com/blog/2010/08/23/history-of-mongodb/)를 읽어보자.

키/값 중심 데이터베이스와 관련해서는 다음 자료를 참고하자.

• 레디스 : 안티레즈가 lloogg.com에서 MySQL 대신 레디스로 전환하기로 결정한 후 쓴 다음의 메일링 리스트 포스트(http://groups.google.com/group/redisdb/browse_thread/thread/0c706a43bc78b0e5/17c21c48642e4936?#17c21c48642e4936)를 읽어보자.
• 도쿄 캐비넷 : http://fallabs.com/tokyocabinet/에 있는 제품 홈페이지에서 도쿄 캐비넷의 가치 제안에 대해 읽어보자.
• 교토 캐비넷 : 도쿄 캐비넷을 만든 이들은 교토 캐비넷이라는 새 제품도 만들었다. 자세한 사항은 http://fallabs.com/kyotocabinet/을 참고하자.

빅테이블 및 다이나모 복제품(HBase, 하이퍼테이블, 카산드라, 리악)의 역사는 주로 구글 및 아마존의 성능을 모방하려는 시도의 역사다. 이들 복제품의 초기 역사 및 발전 과정을 들여다보더라도 구글 및 아마존에서 나온 훌륭한 개념을 모방하려는 여정밖에 드러나지 않는다. 물론 개념을 모방하기도 쉽지 않고 새로운 발견과 혁신 과정이 뒤따른다. 또 사용자들이 새롭고 다양한 사례에 이들 제품을 사용함에 따라 제품이 빠르게 발전하고 있다. 이들 제품의 발전 과정은 초기 영감을 제품의 구현체 위에 많은 신기능을 추가하는 것에 가깝다.

NoSQL은 새롭게 떠오르는 분야다. 이들 제품의 역사를 이해하는 게 도움이 되기도 하지만 대다수 NoSQL 제품의 역사는 지금 쓰여지고 있다.

정리

이 장에서는 간략하게나마(아쉽지만 이 장을 통해 방대한 설명을 하거나 모든 문제에 대한 만병통치약을 줄 수는 없다) 인기 있는 NoSQL 제품을 서로 비교했다. NoSQL 제품은 주의해서 선택해야 하며, 각 제품의 기능, 성능, 역사를 이해한 후 비로소 제품을 선택해야 한다.

이 장에서는 모든 기능을 설명하거나 제품을 선택할 수 있는 모델을 제공하지 않았다. 대신 이 책의 앞 장에서 다룬 내용을 기반으로 설명을 이어갔다. 이 과정에서 중요한 사실을 몇 가지 지적하고 핵심적인 관점을 정리했다. 항상 그렇듯 선택은 여러분의 몫이다.