조대협의 블로그

MongoDB를 구성할때 보면, 가장 많이 권장 받는 부분 중의 하나가, 메모리량과 디스크 성능이다.메모리 크기가 아주 sensitive한 요인이 되는데, 어떤 부분이 문제가 되는지 내부 저장 구조를 살펴 봄으로써 이해를 돕고자 한다. 저장 구조mongodb는 기본적으로 memory mapped file (OS에서 제공되는 mmap을 사용) 을 사용한다. mongodb는 데이타를 write할때, 논리적으로 memory 공간에 write하고, 일정 주기에 따라서, 이 메모리 block들을 주기적으로 disk로 write하는데, 이 디스크 writing 작업은 OS에 의해서 이루어 진다. OS에 의해서 제공되는 Virtual Memory를 사용하게 되는데, Pysical Memory 양이 작더라도 Virtu..

초간단 Mongo DB Quick Start Guide 조대협 (http://bcho.tistory.com) Mongo DB는 NoSQL 중에서 가장 널리 사용되는 인기있는 제품이다. 사용과 운영이 다른 시스템에 비해서 매우 쉽고, JSON 기반의 Document를 제공하기 때문에, 데이타 구조에 대한 이해 및 사용이 쉽다. 또한 index나 search와 같은 feature를 제공하고 있고, 근래에는 Text Search와 GridFS를 이용한 파일 저장 그리고, 위치 정보 저장 및 쿼리등 다양한 기능을 제공하고 있다. Mongo DB는 10gen이라는 회사에서 개발되어서, 현재 오픈소스로와 상용 버전으로 공급되고 있다. 이 글에서는 Mongo DB에 대한 이해를 돕기 위해서 간단한 설치에서 부터, 자..

미국의 NoSQL 인기 순위를 분석해보니, mongodb가 앞도적인 1위, 2위권은 cassandra,hbase 그리고 다음이 redis 맨 아래로 riak,couchdb 등이 있다.아무래도 기능이 편리한 mongodb 가 단연 인기고, 난이도는 있지만 확장성에 우위가 있는 cassandra,hbase가 그 뒤를 따른다. 분석 방법은 indeed.com 이나 monster.com의 구인 광고중, 해당 기술별 구인 광고를 분석하였다. mongodb 276cassandra 149hbase 146redis 91coherence 53couchdb 40riak 24

NoSQL 데이타 모델링 #1Facebook Server Side Architecture Group http://www.facebook.com/groups/serverside 조대협빅데이타,클라우드,NoSQL은 요즘 기술적인 화두중에 하나이다. 그중에서도 NoSQL은 많은 사람이 관심을 갖고 있음에도 불구하고, 기존의 RDBMS 데이타 모델링 관점에서 접근을 하기 때문에, 많은 문제를 유발한다. NoSQL은 데이타 베이스이기도 하지만 RDBMS와는 전혀 다른 성격을 가지고 있고, 접근 방식도 틀리다. 특히 테이블 구조를 정의 하는 데이타 모델에 따라서 NoSQL의 성능은 하늘과 땅차이만큼 차이가 난다. 이 글에서는 NoSQL의 데이타 모델링 기법에 대해서 소개하고자 한다.※ 깨지는 그림은 클릭해서 봐주세..

짧으나마 NoSQL 경험해보고 배운 내용을 정리해보면 1. RDB는 Entity를 정의하고 데이타 모델링을 정의한 후에, 쿼리와 APP을 개발한다. 반대로 NoSQL은 App을 먼저 디자인하고, 필요한 쿼리 결과를 먼저 정의 한후에, 그에 맞춰서 데이타 모델링을 해야 한다. 2. 절대 Normalization은 하지 말고, DeNormalization을 할것. 데이타 중복을 허용하여 성능을 높이고, 데이타안에 데이타를 넣는 (Composition) 모델등을 사용하여 Query 수를 줄여야 한다. 3. 내 애플리케이션의 서비스 특성과 이에 맞는 NoSQL을 선택한다. BigTable 계열, Cassandra 계열, Document DB 계열등 많은 계열의 NoSQL이 있고, 그 특성도 매우 다르다 (언뜻 ..

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하다..

Google의 BigTable에서 시작된 것들 - HBase (Java) - HyperTable (C++) 주로 대규모 분산처리 특히 Map&Reduce에 알맞고, 동시 대규모 클라이언트를 지원하는데 뛰어 나다 Amazon Dynamo 로 부터 시작된 것들 - Voldemork - Riak FaceBook에서 시작된것 - Cassandra Write에 Optimize되었으며, Read는 Write에 비해 느림. 대규모 데이타 저장에 최적화됨 그밖에 Mongo 계열 -MongoDB 쉽다. 그리고 AutoSharding과 Balacing 제공. 10gen에서 Commercial Support -CouchDB : MongoDB와 특성은 유사하나 내부 기술 구조는 다름

MongoDB Deployment 아키텍쳐를 간단하게 보면 다음과 같다. mongos들을 앞단에 쭈욱 늘어놓고, 이는 라우터의 역할을 한다. mongos간의 load balancing은 앞단에 L4등의 로드 밸런서를 사용하고, Cache Hit율등을 높이기 위해서 L4는 Hash 방식등의 Sticky setting을 한다. 뒷단에 mongod를 배치하고, 최소한 3 copy replica 구조로 설정한다. inter data center에 대한 replication을 설정하고, 이는 DR이나 Back up 용도로 사용한다 inter data center replication은 항상 여러가지 숙제를 주는데, 이 경우 backbone의 속도 차이로 인하여 data의 일관성이 깨질 수 있으니, 1. DR/Ba..

대충 2시간 정도 MongoDB를 훝어보니 구조 - mongod는 실제 데이타 베이스 핸들링 프로세스로 mysqld와 유사 - 앞단에 mongos 라는 프로세스를 띄워서 클러스터 구성을 하면, mongos가 로드 밸런서 역할을 함 클러스터링을 할경우 - Sharding을 사용하여 데이타를 분산 저장해야 함 - 이 경우 같은 shard내에 mongod를 3 copy로 replication하여 데이타 유실을 방지를 권고한다. - 고급 문서 대부분 내용이 Shard 구성과 Index 구성이다. 이게 키 포인트인듯 ※ 이 과정은 Redundant한 하드웨어 구성으로 인하여 하드웨어 코스트를 올릴 수 있다. 성능 부분에서는 - mongodb는 memory 기반의 index를 사용하여 cassandra나 hbase..

http://bigdatalowlatency.com/ 대용량 분산 데이타 처리에 대한 글이 많다. 큐브리드에서도 NoSQL 벤치마크한 자료들이 많네요. 그것도 영어로.. http://blog.cubrid.org/dev-platform/nosql-benchmarking/ 여기 Foursquare에서 MongoDB에 대한 장애 케이스가 있네요 http://monetary.egloos.com/3600459 결국은 메모리가 빵빵해야 하고, 용량 초과되기 전에 증설을 자알~~ 해야 한다는것.