아래 내용은 Memcached와 Redis간의 성능 테스트를 했던 블로그의 내용을 발번역한 자료이다.
원래 원문은 아래 링크이며, 나는 블로그들을 살펴보며, 무슨 말을 하려고 했는지 보고 싶었다.
http://nosql.mypopescu.com/post/1462969783/redis-and-memcached-benchmarks

수많은 테스트를 통해서 나는 벤치마크 테스트 셋을 잘 믿지 않는 편이다.
내가 속해 있는 App-Data 환경에서 테스트해야 좀 믿는다.

하지만 다양한 테스트 결과가 봄으로서, 통찰력이 생길 수 있다는 점은 좋은 것 같다. ^^



1. 블로그 #1
2009년 11월에 한 블로거가 redis와 memcached와 tokyo tyrant와 mysql을 테스트를 하였다.

http://www.ruturaj.net/redis-memcached-tokyo-tyrant-mysql-comparison

redis가 특정 벤치마크테스트에서 get/set에 뛰어난 성능을 보여주였다.

throughput set

throughput get

2. 사건 #2

2010년 8월에 또다른 블로거가 이에 대해서 글을 작성했다.
http://systoilet.wordpress.com/2010/08/09/redis-vs-memcached/

3바이트 키을 가진 10만개 데이터를 넣고, 얼마나 빨리 찾는지 보여주는 테스트이다.




Muti-get 테스트할 때는 Redis가 상당히 안좋게 나왔다. 당시에는 Redis가 multi-bulk 전송기능이 후졌을 때를 기준으로 테스트된 거라, 지금 (2011.8월)은 어떻게 나올지는 모르겠다.



10바이트 키에 최대로 16KB까지 처리할 수 있는 가변 데이터를 테스트했다.
Memcached는 데이터의 길이가 커지면 성능이 떨어지는 이슈가 생겼다. (문서에서는 1Mbyte까지 지원한다고 하지만, 실제로는 상당히 좋지 않은 결과가 나왔다)

memcached가 원래 대용량에 약하며, 길이 제한이 제일 강하다. Amazon Simple DB가 memcached 기반이다.


내용을 봤을 때는 작은용량일때는 memcached가  redis보다 성능이 좋은 것 같다.


3. 블로그 #3

또다른 블로거가 발끈하고 2010년 9월에 쓴 자료가 있다.

http://antirez.com/post/redis-memcached-benchmark.html

벤치마크 테스트를 수정해서 테스트했더니. redis가 더 좋게 나왔다.

블로그 #2의 테스트 결과는 잘 못 테스트했다라는 것이다. busy loop나, 클라이언트 lib, 동일하지 않은 클라이언트 lib 문제로 테스트결과는 잘못되었다가 얘기했다.

Redis VS memcached 

그리고, 백만 key를 get/set 테스트해서 cpu 사용률 결과를 공유했다. 거의 큰 차이가 없었다.

  • memcache: user 8.640 seconds, system 19.370 seconds
  • redis: user 8.95 seconds, system 20.59 seconds

Redis는 set/list/hash에 대해서 atomic하게 get/set를 해줄 수 있기 때문에 하드웨어의 영향을 받을 수 있다. 또한 한계가 있는 상황에서 Redis가 memcached보다 빠르다라고 말할 수 없으며, 테스트 환경에 따라서 둘 중의 하나가 빠르다고 결과가 나올 것이다.


4. 블로그 #4

어떤 분이 성능 비교 글을 쓰며, 블로그 #2, 블고그 #3 모두 똑같은 이슈가 있다고 했다. 한 물리 서버에서 하나의 서버에  하나의 클라이언트를 돌려서 테스트하는 것은 잘못된 경과라고 했다. 그리고, 블로그 #3의 결과가 좀더 괜찮다고 했다.

http://dormando.livejournal.com/525147.html

블로그 #3의 코드를 조금 다듬어 paralle(병렬)로 테스트를 했더니 다음과 같은 결과가 나왔다.







이 블로거는 테스트결과를 공유하고, memcached는 multi-thread로 매우 좋은 결과를 만들었고, redis는 single -thread 때문에 퍼포먼스가 별로였다고 언급했다.

Redis를 가지고 single thread와 multi thread 로 테스트를 했더니 오히려 single thread쪽이 더 좋은 결과를 내었다고 얘기했다.

 


5. 블로그 #5

블로그 #3의 주인이 블로그 #4에 대해서 쓴 글이다.
http://antirez.com/post/update-on-memcached-redis-benchmark.html


이 사람은 2코어의 cpu 사용의 한계를 주고, 100개의 클라이언트로 테스트했다.
  • Memcached was serving 130k SETs per second and 150k GETs per second.
  • Redis was serving 200k SETs per second and 200k GETs per second.
memcached는 멀티 코어를 사용하는 하나의 인스턴스에 대해서는 scale을 못하는 문제가 있음을 얘기했다.
그래서 2개의 memcached를 실행했더니 Redis와 비슷한 성능을 나오는 것을 발견했다.

  • Memcached was serving 200k SETs per second and 200k GETs per second.


Redis가 memcached보다 복잡해서 안정성과 속도를 적절히 유지하면서 쓰레드 기반의 구현이 어려울 수 있다고 했다. Redis는 MGET 성능이 좋지 않기 때문에 Hash데이터를 저장하여 HGETALL 을 써서 한번에 읽고 쓰도록 하는 것이 좋다고 했다.


6. 결론
괜찮은 벤치마크 테스트를 만드는 것은 쉽지 않다. 대부분의 벤치마크 테스트는 잘못된 테스트를 하거나, 실제 개발에서는 사용하지 않는 것들을 테스트하기 때문이다. 따라서 벤치 마크 자료를 보았을 때는 그 자료를 100% 신뢰하지 말라는 것이다. 사용을 위해서는 App 개발 환경에서 사용할 수 있는 테스트 시나리오(data 크기, 동시성 레벨) 를 진행하는 것이 좋다. (당근 옳소~)


'nosql' 카테고리의 다른 글

[Hadoop 설치 에러] bin/hadoop namenode -format 실패시  (0) 2011.08.22
Redis 소개  (2) 2011.08.18
데이터 모델에 따른 Nosql 선택과 고려사항  (0) 2011.06.24
mysql -> mongoDB로 migration  (0) 2011.05.27
Nosql in Facebook  (0) 2011.05.24
Posted by '김용환'
,