1 / 20

2012. 08. 28 Austin

MongoDB Tutorial. 2012. 08. 28 Austin. 목차. NoSQL ? Data 의 변화 MongoDB MongoDB Best Practices. 1. NoSQL?. NoSQL 주요 특징 Schema free Replication Simple API No Relation / No Join Big Data Store NoSQL 의 종류 Document Store MongoDB , CouchDB , Jackrabbit , Lotus Notes..

hetal
Download Presentation

2012. 08. 28 Austin

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MongoDB Tutorial 2012. 08. 28 Austin

  2. 목차 NoSQL ? Data 의 변화 MongoDB MongoDB Best Practices

  3. 1. NoSQL? • NoSQL 주요 특징 • Schema free • Replication • Simple API • No Relation / No Join • Big 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….

  4. 2. Data의 변화 <과거 : MB,GB 단위의 데이터 > <현재 : TB,PB 단위의 데이터 >

  5. 2.1 서비스 기업들의 Needs 변화 • 서비스 기업들의 Needs 변화 • 급격한 데이터 증가 • Downtime 없는 DB ( 자동 Switch System 요구 ) • 지리적 분산 DB ( IDC 센터 분할 요구 ) • 이 모든 것에 대한 솔루션이 필요 함

  6. 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

  7. 3.1MongoDB 특징 • Document-oriented storage • Full Index Support • Replication & High Availability • Auto-Sharding • Querying • Fast In-Place Updates • Map/Reduce • GridFS • Commercial Support

  8. 3.1.1 MongoDB 설치 • 다운로드http://www.mongodb.org/downloads • 압축 해제 • tar xvfz mongodb-linux-x86_64-2.2.0.tgz –C /usr/local/mongodb • 실행 • 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=MOBILE02 • Wed Sep 5 21:05:49 [initandlisten] db version v2.2.0-rc0, pdfile version 4.5 • Wed Sep 5 21:05:49 [initandlisten] git version: 33dc8445316479bbaa062db00f179fa5c39bbddb • Wed 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_49 • Wed 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/lo • gs/mongod.log", oplogSize: 1024, port: 27018, replSet: "tapad", rest: "true" } • Wed Sep 5 21:05:50 [initandlisten] journal dir=/raid/mongo/db/journal • Wed Sep 5 21:05:50 [initandlisten] recover : no journal files present, no recovery needed • Wed Sep 5 21:05:50 [initandlisten] waiting for connections on port 27018 • Wed Sep 5 21:05:50 [websvr] admin web console waiting for connections on port 28018 • 설정 관련 옵션 • http://www.mongodb.org/display/DOCS/File+Based+Configuration

  9. 3.1.2 MongoDB 접속 및 DB 생성 [root@MOBILE02 mongodb]# ./bin/mongo localhost:27018 MongoDB shell version: 2.2.0 Connecting to: 127.0.0.1:27018/test >use TestMongo #데이터 베이스 선택 switched to db TestMongo db.testcollection.count() #Collection 카운트 Insert db.[collection].insert ( 내용); Select db.[collection].find( 조건); Update db.[collection].find( 조건, 내용); Delete db.[collection].remove( 조건); http://www.mongodb.org/display/DOCS/SQL+to+Mongo+Mapping+Chart

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

  11. 3.2.2 Replica Set Write Primary Read Driver Secondary Asynchronous Replication (oplog로 복제) Read Secondary Read

  12. 3.2.3 Replication & Failover Step 2 ( Member3 Fault ) Step 1 ( Service Start ) Member1 SECONDARY Member1 PRIMARY Vote Member3 PRIMARY Member3 PRIMARY Member2 SECONDARY Member2 SECONDARY Step 3 ( Member3 Repair & Attach ) Member1 PRIMARY Member3 SECONARY Member2 SECONDARY

  13. 3.2.4 Replica Set – App View Mongos Mongod (master) Write Read Mongod (slave) Read Driver Mongod (slave) Read

  14. 3.2.4 Replica Set – App View Mongos Mongod (master) Write Read Mongod (master) Read Driver Mongod (slave) Read

  15. 3.3.1 Sharding • 특징 • MongoDB의 Scale Out 형 서버 확장 방식 • 데이터를 각각의 Shard에 분산 • Write 속도 향상 • Shard 추가 시 downtime 없음 • 분산 • Shard Key의 개수 균등화 • Disk Utilization , Time • 크기 한계를 넘은 Chunk를 1/2로나누어 교환 • 명령 수행 방식 • Operation route • Scatter , gather

  16. 3.3.1 Sharding

  17. 3.3.2 Server Layout shard1 shard2 shard3 mongod mongod mongod mongod mongod mongod Replica Set mongod mongod mongod config config config mongos mongos mongos LVS Keepalived App Server App Server App Server

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

  19. 3.5.1 MongoDB - Map Reduce MongoDB 에서 map/reduce 는 데이터를 배치로 처리하거나 집계연산(aggregation operation)에 유용합니다. 추구하고자 하는 것은 Hadoop과 같은 어떤것을 사용하여 한 컬렉션의 모든 입력 값들을 가지고 어떤 컬렉션에 결과를 출력하는 것입니다. SQL 에서 GROUP BY 를 사용했을지도 모를 상황에서, map/reduce 는 mongodb에서 적합한 방법입니다. http://www.mongodb.org/display/DOCS/MapReduce • MapReduce Sample DBCollectioncoll = db.getCollection( collectionName ); BasicDBObjectcond = 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"; MapReduceCommandmr = new MapReduceCommand( coll , map , reduce , outCollection , OutputType.INLINE , cond ); MapReduceOutputmout = coll.mapReduce( mr ); for( DBObjectdbObj : mout.results() ){ BSONObjectvObj = (BSONObject)dbObj.get( "value" ); if( vObj.get( "price" ) != null ) price = ((Double) vObj.get( "price" )).intValue(); }

  20. 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/

More Related