블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


MongoDB 깜빡 잊고 있었다. Read / Write 성능이 빠를 수 밖에 없다는 걸..
Mongo는 Write시에, Memory에 먼저 Write후에, 1분 단위로 Flushing하는 Write Back 방식을 쓴다. 즉 메모리에만 쓰면 되니까는 Write가 무지 빠르다. 반대로 Read시에는 파일의 Index를 메모리에 로딩해놓고 찾는다(memory mapped file). 이러니 성능이 좋을 수 밖에, 단 Flushing전에 Fail이 되면 데이타 유실에 의해서 Consistency 가 깨지는 문제가 발생하고, Configuration 구조상 메모리 사용량이 많으며, 확장성에 제약이 있다.
특히 Write 구조에서는 비동기 식으로 Write를 하기 때문에 Disk 성능에 덜 Sensitive하다. 즉 이 말은 DiskIO성능이 상대적으로 낮은 클라우드에서 더 잘돌아간다는 이야기.

이에 비해서 Cassandra(같은 Dynamo 계열인 Riak도 마찬가지) 는 Write Back이나 Memory Mapped file을 사용하지 않기 때문에 MongoDB에 비해서 성능이 낮을 수 밖에 없다. 더군다나, Write나 Read시 1개 이상의 Node에서 값을 읽거나(R Value) 쓰기 때문에(W Value) Consistency가 mongoDB에 비해서 나으며, 당연히 확장성도 더 높다.

즉 확장성+일관성 vs 성능간의 Trade Off 구조다.
 
한국 내 정도 서비스 할 수준이라면 걍 mongo가 났겠네.. 대규모 서비스라면 Cassandra 고민해봐야 할듯 하고.
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. CharSyam 2012.03.05 18:57  댓글주소  수정/삭제  댓글쓰기

    MongoDB의 경우 그래서 Working Set 이 모두 메모리에 들어가 있어야 최적의 성능을 발휘합니다. 최대한 메모리 많이 달고 사용해야 한다는... 현재 다음뷰에서 mongodb 로 서비스 한다고 들었습니다. 적당한 규모에서는 문제가 없을듯 하지만, 그것보다는 mongodb 와 cassandra의 데이터 모델이 달라서 할 수 있는 용도가 다르다는게 차이가 날것 같네요.

  2. 예린아빠 2012.04.19 23:35  댓글주소  수정/삭제  댓글쓰기


    금번 프로젝트에 적용하면서 느낀바로는
    Memory가 넉넉하지 않을 경우는 위에서 열거한 모든 장점이 단점으로 바뀐다는 사실입니다.
    특히 App/Web Server에 혼용하는 구성으로 갈 경우에는 특히 더. (메모리가 넉넉하다 하더라도 절대 비추입니다.)
    문제는 어느정도의 Memory가 넉넉하다는 것이지요. 넉넉(?)한 사전 검토 없이 막연한 산정으로
    시스템을 구성하고 접근하는 것은 아주 위험합니다.