2012. 08. 28Austin

MongoDB Tutorial

I. 목차1. NoSQL ? 2. Data 의 변화 3. MongoDB 4. MongoDB Best Practices

1. NoSQL?NoSQL 주요 특징

Schema free ReplicationSimple APINo Relation / No JoinBig Data Store

NoSQL 의 종류 Document Store

MongoDB , CouchDB , Jackrabbit , Lotus Notes.. Key/Value Store

Amazon SimpleDB , MemcacheDB …Column Store

Hadoop/HBase , Cassandra , Hypertable …Graph DB

Neo4J , HyperGraphDB….

2. Data 의 변화

< 과거 : MB,GB 단위의 데이터 > < 현재 : TB,PB 단위의 데이터 >

2.1 서비스 기업들의 Needs 변화1. 서비스 기업들의 Needs 변화

급격한 데이터 증가 Downtime 없는 DB ( 자동 Switch System 요구 ) 지리적 분산 DB ( IDC 센터 분할 요구 )

이 모든 것에 대한 솔루션이 필요 함

2.2 CAP 이론

분산 시스템이 갖추면 좋은 세가지 특성 ( Consistency ,Availability ,Partition Tolerance )C (Consistency )

모든 노드가 같은 시간에 같은 데이터를 보여줘야 한다 .A (Availability )

몇몇 노드가 다운되어도 다른 노드 들에게 영향을 주지 않아야 한다 .P (Partition Tolerance)

일부 메시지가 손실 되더라도 시스템은 정상 동작을 해야 한다 .CAP 이론에 따르면 위 3 가지 중에 동시에 2 가지만 보장할 수 있고 3 개를 모두 보장하는 것이 불가능 하다 . 그래서 데이터를 관리할 때 이 3 가지 중 에 어느 2 가지에 중점을 두느냐가 아주 중요한 부분이다 .

http://blog.nahurst.com/visual-guide-to-nosql-systems

3.1MongoDB 특징Document-oriented storage

Full Index Support

Replication & High Availability

Auto-Sharding

Querying

Fast In-Place Updates

Map/Reduce

GridFS

Commercial Support

3.1.1 MongoDB 설치1. 다운로드 http://www.mongodb.org/downloads2. 압축 해제

tar xvfz mongodb-linux-x86_64-2.2.0.tgz –C /usr/local/mongodb3. 실행cd /usr/local/mongodb/mongodb-linux-x86_64-2.2.0./bin/mongod --config configfile.conf

Wed Sep 5 21:05:49 [initandlisten] MongoDB starting : pid=24494 port=27018 dbpath=/raid/mongo/db 64-bit host=MOBILE02Wed Sep 5 21:05:49 [initandlisten] db version v2.2.0-rc0, pdfile version 4.5Wed Sep 5 21:05:49 [initandlisten] git version: 33dc8445316479bbaa062db00f179fa5c39bbddbWed Sep 5 21:05:49 [initandlisten] build info: Linux domU-12-31-39-16-30-A2 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:34:28 EST 2008 x86_64 BOOST_LIB_VERSION=1_49Wed Sep 5 21:05:49 [initandlisten] options: { config: "/usr/local/mongodb-linux-x86_64-static-legacy-2.2.0-rc0/config/mongod.conf", dbpath: "/raid/mongo/db", logappend: "true", logpath: "/raid/mongo/logs/mongod.log", oplogSize: 1024, port: 27018, replSet: "tapad", rest: "true" }Wed Sep 5 21:05:50 [initandlisten] journal dir=/raid/mongo/db/journalWed Sep 5 21:05:50 [initandlisten] recover : no journal files present, no recovery neededWed Sep 5 21:05:50 [initandlisten] waiting for connections on port 27018Wed Sep 5 21:05:50 [websvr] admin web console waiting for connections on port 28018

설정 관련 옵션 http://www.mongodb.org/display/DOCS/File+Based+Configuration

3.1.2 MongoDB 접속 및 DB 생성[root@MOBILE02 mongodb]# ./bin/mongo localhost:27018MongoDB shell version: 2.2.0Connecting to: 127.0.0.1:27018/test>use TestMongo # 데이터 베이스 선택switched to db TestMongo db.testcollection.count() #Collection 카운트Insertdb.[collection].insert ( 내용 );Selectdb.[collection].find( 조건 );Updatedb.[collection].find( 조건 , 내용 );Deletedb.[collection].remove( 조건 );

http://www.mongodb.org/display/DOCS/SQL+to+Mongo+Mapping+Chart

3.2.1 Replica SetMySQL Replication 지원 Master 장애 시 수동으로 복구

MongoDBMaster/Slave 방식의 Replication 지원 Replica Set 이란 방식으로 Replication 지원Replica Set 과 Replication 의 차이 ?Replica Set 은 Master 장애 시 자동으로 Slave 중 최근 데이터 동기화한 서버를 찾아서 Master 로 선출 ( 약 10 sec 미만 소요 )

3.2.2 Replica SetD

rive

r

Primary

Secondary

Secondary

AsynchronousReplication(oplog 로 복제 )

WriteRead

Read

Read

3.2.3 Replication & Failover

Member1SEC-

ONDARY

Member3PRIMARY

Member2SEC-

ONDARY

Member1PRIMARY

Member3PRIMARY

Member2SEC-

ONDARY

Member1PRIMARY

Member3SECONARY

Member2SEC-

ONDARY

Step 1 ( Service Start ) Step 2 ( Member3 Fault )

Step 3 ( Member3 Repair & Attach )

Vote

3.2.4 Replica Set – App ViewD

rive

r

WriteRead

Read

Read

MongosMon-god

(mas-ter)

Mon-god

(slave)

Mon-god

(slave)

3.2.4 Replica Set – App ViewD

rive

r

WriteRead

Read

Read

MongosMon-god

(mas-ter)

Mon-god

(mas-ter)

Mon-god

(slave)

3.3.1 Sharding

특징MongoDB 의 Scale Out 형 서버 확장 방식데이터를 각각의 Shard 에 분산 Write 속도 향상Shard 추가 시 downtime 없음

분산Shard Key 의 개수 균등화Disk Utilization , Time크기 한계를 넘은 Chunk 를 1/2 로 나누어 교환

명령 수행 방식 Operation routeScatter , gather

3.3.1 Sharding

3.3.2 Server Layout

mongod

config

mongos

mongod

config

mongos

mongod

config

mongos

mongod mongod mongod

mongod mongod mongod

shard1 shard2 shard3

Replica Set

App Server App Server App Server

KeepalivedLVS

3.5.1 Map ReduceMapReduce?MapReduce 는 구글에서 분산 컴퓨팅을 지원하기 위한 목적으로 제작하여 2004 년 발표한 소프트웨어 프레임워크다 . 이 프레임웍은 페타바이트 이상의 대용량 데이터를 신뢰 할 수 없는 ( 저가 ) 컴퓨터로 구성된 클러스터 환경에서 병렬 처리를 지원하기 위해서 개발되었다 .

http://ko.wikipedia.org/wiki/MapReduce

http://highlyscalable.wordpress.com/2012/02/01/mapreduce-patterns/

3.5.1 MongoDB - Map ReduceMongoDB 에서 map/reduce 는 데이터를 배치로 처리하거나 집계연산 (aggregation operation) 에 유용합니다 . 추구하고자 하는 것은 Hadoop 과 같은 어떤것을 사용하여 한 컬렉션의 모든 입력 값들을 가지고 어떤 컬렉션에 결과를 출력하는 것입니다 . SQL 에서 GROUP BY 를 사용했을지도 모를 상황에서 , map/reduce 는 mongodb 에서 적합한 방법입니다 .http://www.mongodb.org/display/DOCS/MapReduce

DBCollection coll = db.getCollection( collectionName );

BasicDBObject cond = new BasicDBObject();cond.put( FIELD_SCHEMA.PRIZE_ID.getName() , prizeId );cond.put( FIELD_SCHEMA.STATE.getName() , state );

String map = "function() { emit( { prizeId: PRIZE_ID , stateId:STATE } , { price: CHARGE_PRICE } ); }";String reduce = "function(key, values) { "+

"var result = { price: 0};"+"values.forEach(function(value) { "+ "result.price += value.price; "+"});" +"return result;"+"}";

String outCollection = "mrout";

MapReduceCommand mr = new MapReduceCommand( coll , map , reduce , outCollection , OutputType.INLINE , cond );

MapReduceOutput mout = coll.mapReduce( mr );for( DBObject dbObj : mout.results() ){

BSONObject vObj = (BSONObject)dbObj.get( "value" );if( vObj.get( "price" ) != null )

price = ((Double) vObj.get( "price" )).intValue();

}

MapReduce Sample

4. MongoDB Best Practices 항상 Replica Set 을 사용하라Replica Set 은 장애시 자동 Failover 를 통해서 HA( 고 가용성 ) 를 지원합니다 . 항상 최신 버전을 유지하라 MySQL 처럼 오래된 패키지는 새 버전이 나오면 오랜 검증으로 적용되지만 NoSQL 같은 경우는 Bug fix 가 많으므로 항상 최신버전을 유지 해주는것이 중요합니다 . MongoDB 는 32Bit 에서 사용하지 마라 32bit 시스템에서는 MongoDB 는 2.5GB 의 데이터 밖에 사용할 수 없습니다 . Storage Engine 이 성능상의 이유로 Memory-Mapped Filed 을 사용하고 , 이로 인해 메모리 어드레싱이 2.5 까지 밖에 사용할 수 없기 때문입니다 . MongoDB 는 Index Size 가 메모리보다 커지면 속도에 큰 저해가 오기 때문에 메모리를 넉넉하게 사용하는게 좋습니다 . ( 포스퀘어는 서버한대당 64G 메모리 사용 ) 기본적으로 Journaling 을 사용하라MongoDB 는 장애 복구나 노드의 안전성을 위해서 Write-Ahread 저널링을 지원합니다 . 데이터 파일의 위치를 확인하라MongoDB 는 기본적으로 /tmp 디렉토리에 저장되는데 /tmp 디렉토리를 주기적으로 OS 에서 삭제하는경우 문제가 될 수 있습니다 . Working Set 은 메모리 사이즈에 적합하게 유지하라Working Set(Index) 을 메모리에 두는 것은 클러스의 영향을 미치는 매우 중요한 요소입니다 . Page Fault 가 증가하는 것을 알면 , 가용 메모리보다 Working Set 의 사이즈가 커진다는 것을 알 수 있는 알 수 있는 매우 좋은 기회입니다 . 가용 메모리보다 Working Set 데이터가 증가하면 두 가지 방법이 있습니다 . MongoDB 의 메모리 사이즈를 증가시키거나 , Sharding 을 하는 것입니다 . MongoDB 의 메모리 사이즈를 증가시키는 것을 먼저 추천합니다 많이 사용한다면 Sale Up 하라 기기의 Load 가 65% 를 넘는다면 , Scaling up 을 고려해야 합니다 . 평균적으로 동작할 때 Load 가 65% 이하여야 합니다 . 복구나 , 수직 Scaling 상황에도 영향을 줍니다 . instance size 를 늘려야 할 필요가 있다면 , AWS 는 Large, Extra Large, high Memory 4XL 순서로 업그레이드를 추천합니다 . Sharding 에 주의하라Sharding 을 적용하는 것은 어플리케이션의 액서스 패턴에 대한 깊은 이해가 필요합니다 . MongoDB 가 어떻게 Sharding 을 하고 정말로 Sharding 이 필요한지에 대해서 시간을 드려서 고민해야됩니다 . 또한 어플리케이션 성능에 영향을 미치기 때문에 좋은 Sharding Key 를 선택하는 것이 중요합니다 . Config 서버는 클러스터의 상태에 중요한 역할을 합니다 . 실제 Sharding 서비스 환경에서는 꼭 3 대의 Config 서버가 필요합니다 . 항상 Config 서버의 데이터를 백업하고 확인하고 절대로 데이터를 지우면 안됩니다 .Config 서버는 경량 프로세스이지만 64bit 장비에서 동작해야 됩니다 . 3 개의 config 서버를 한대에 장비에 넣어서는 안됩니다 .

그래픽적으로 모니터링 하려면 MongoMMS 를 사용하라

http://www.engineyard.com/blog/2011/mongodb-best-practices/