1.
소개디지캡 솔루션 2팀싞대용 2011년 7월 27일 수요일 솔루션 2팀 싞대용 dyshin@digicaps.com

2.
Contents 1. Needs의 변화 2. MongoDB Overview 3. MongoDB Tutorial 4. Document DB 5. Replica Sets 6. Sharding 7. 기타 사항 8. MongoDB 성능 시험 9. 정리 2

3.
1. Needs의 변화 3

4.
1.1 Needs Data에 대한 시각• Object – 이제는 Object로 생각함 – Object개념의 시스템 설계 – RDBMS를 사용하기 위해서 별도의 데이터 베이스 설계. – ORM 등장• XML, JSON등 Flexible 데이터 – RDBMS는 XML등에 최적화 되어 있지 않음 4

5.
1.2 기업들의 요구 사항• 급격한 데이터 증가 수용• Downtime없는 DB• 지리적 DB분산• 모든 것에 대한 솔루션이 필요. 5

6.
1.3 CAP 이론 6

7.
1.4 NoSQL! - Google BigTable• Google BigTable “Bigtable is a distributed storage system for managing structured data that is designed to scale to a very large size: petabytes of data across thousands of commodity Server” – 컬럼 기반 데이터 저장소 – 분산 홖경에서의 대용량 데이터 처리 7

8.
1.4 NoSQL! - Amazon Dynamo• Requirements – Simple query model – Scale out – Eventual consistency – Decentralized – Low latency• P2P key-value store – Object versioning – Consistent hashing – membership & failure detection – Quorum reads 8

9.
1.4 NoSQL! - Yahoo PNUTS• Requirements – Scale out – Geo-replication – High availability – Relaxed consistency – Low latency• Simplified relational data model – Flexible schema – No Referential Integrity – No joins, aggregation, Transaction – Updates/deletes only by Primary Key – “Multiget” (retrieve many records by PKs) 9

10.
1.4 NoSQL! - Apache Cassandra• Requirements – High availability – Eventual consistency – Incremental scalability – Optimistic replication• Developed by Facebook – Facebook에서는 새로 개발중 – BigTable, Amazon Dynamo기반• P2P 속성• 컬럼 기반 10

11.
1.5 NoSQL Needs• Low response time• Scalability• High Availability and Fault Tolerance• Flexible schemas• Distribution• Low cost로!!!• Consistency, Integrity, Transaction 포기 11

12.
Contents Overview 1. Needs의 변화 2. MongoDB Overview 3. MongoDB Tutorial 4. Document DB 5. Replica Sets 6. Sharding 7. 기타 사항 8. MongoDB 성능 시험 9. 정리 12

13.
2.1 MongoDB? Replica Sets Eventual Consistency Sharding 13

14.
2.1 MongoDB?• NoSQL – Document Base Database ( JSON ) – Schema Less – Full Index supported• Memory Mapped File DB Engine• Focus on Performace• Open Source – Powered By 10 Gen• AGPL License – 서버 소프트웨어 용 GPL라이선스 14

15.
2.1 Memcache와 RDBMS의 사이 15

16.
2.2 적용 사례들 16

17.
2.3 적용 사례 - Yottaa• Yottaa – Web Site Performance 분석 서비스• 요구사항 – 데이터가 급격히 증가, Scalable 필수 – 인프라 관리 인원이 없음, 쉬욲 관리 필수 – 수시로 바뀌는 요구 사항에 맞출 수 있어야 함 – 100% 클라우드 시스템에 올릴 수 있어야 함 http://www.slideshare.net/jrosoff/scaling-rails-yottaa 17

18.
2.3 Yottaa 기존 18

19.
2.3 Yottaa Master – Slave 구조 19

20.
2.3 Yottaa Master – Master 구조 20

21.
2.3 Yotta 최종 적용 21

22.
2.4 시스템 구성 Replica Sets Shards Mongos Configure Client 22

23.
2.4.1 Replica Sets Slave ArbiterClient Master• Master – Read, Write를 수행• Slave – Master로서 oplog를 젂송 받아 replication 수행 – Client의 Read Operation만 처리 – Read Scale ability 증가 (Slave Ok 옵션 시) – Master down시 투표를 통해23Master가 됨

24.
2.4.2 Replica Sets• 목적 – Data Redundancy 증가 – Failover• 구성 – 최소 2대의 Data 저장용 MongDB Daemon와 1대의 Arbiter – Shard 구성 시 데이터 저장소 단위 가 됨 – Master에서 Read, Write, Slave는 Read만 가능• Master, Slave 갂 data Consistency – 기본: Strict Consistency – 옵션: n개의 노드 갂 Eventual Consistency – Eventual Consistency에서는 Master down시 Sync되지 않은 데 이터, Operation은 유실 – getLastError를 이용하여 유실 방지 24

25.
2.4.3 mongos • Sharding Router – Scale Out 수행 – Write Scalability 증가 – Client에게는 단일 mongod로 보이 며 client의 요청을 shard에 젂달 – Shard갂 Data를 분산 25

26.
Contents Tutorial 1. Needs의 변화 2. MongoDB Overview 3. MongoDB Tutorial 4. Document DB 5. Replica Sets 6. Sharding 7. 기타 사항 8. MongoDB 성능 시험 9. 정리 26

27.
3.1 설치1. 디렉토리 준비# mkdir /svc/mongodb/opt /svc/mongodb/server /svc/mongodb/data -p# cd /svc/mongodb/opt2. 다욲로드, 설치# wget http://www.mongodb.org/dr/fastdl.mongodb.org/linux/mongodb-linux-x86_64-1.8.2.tgz/download# tar xvfz mongodb-linux-x86_64-1.8.2.tgz -C /svc/mongodb/server3. 실행# cd /svc/mongodb/server/mongodb-linux-x86_64-1.8.2# export PATH=$PATH:/svc/mongodb/server/mongodb-linux-x86_64-1.8.2/bin# mongod --dbpath /svc/mongodb/data/Tue Jul 26 01:12:35 [initandlisten] MongoDB starting : pid=2750 port=27017 dbpath=/svc/mongodb/data/ 64-bitTue Jul 26 01:12:35 [initandlisten] db version v1.8.2, pdfile version 4.5Tue Jul 26 01:12:35 [initandlisten] git version: 433bbaa14aaba6860da15bd4de8edf600f56501bTue Jul 26 01:12:35 [initandlisten] build sys info: Linux bs-linux64.10gen.cc 2.6.21.7-2.ec2.v1.2.fc8xen #1 SMP Fri Nov 20 17:48:28 EST 2009 x86_64 BOOST_LIB_VERSION=1_41Tue Jul 26 01:12:35 [initandlisten] waiting for connections on port 27017Tue Jul 26 01:12:35 [websvr] web admin interface listening on port 28017 27

28.
3.1 monogdb 관리자 화면• 관리자 접속 28

29.
3.2 CRUD - 접속 및 DB생성[root@mongo205 ~]# mongoMongoDB shell version: 1.8.2connecting to: test> use MeTV #데이터 베이스 사용switched to db MeTV> db.purchase.count(); #테이블(Collection) 사용0 29

30.
3.2 CRUD - 명령들Insert db.[collection].insert ( 내용 );Select db.[collection].find( 조건 );Update db.[collection].find( 조건, 내용 );Delete db.[collection].remove( 조건 ); 30

31.
3.2 Insert , Select>use MeTVswitched to db MeTV> db.test.insert( { message:hello world!} );>> db.test.find();{ "_id" : ObjectId("4e2da0f3a051ab4638e3c72b"), "message" : "hello world!" }> db.test.count();1> 31

32.
3.3 update, remove>db.test.update( {message:hello world!}, {message:stop it} );>db.test.find();{ "_id" : ObjectId("4e2da100a051ab4638e3c72c"), "message" : "stop it" }> db.test.remove( { "_id" : ObjectId("4e2da100a051ab4638e3c72c") } );> db.test.count();0> 32

33.
Contents Document DB 1. Needs의 변화 2. MongoDB Overview 3. MongoDB Tutorial 4. Document DB 5. Replica Sets 6. Sharding 7. 기타 사항 8. MongoDB 성능 시험 9. 정리 33

34.
4.1. 블로그 데이터 모델링 posts comments tags posts_tags PK id PK idPK id PK id title FK1 post_id slug author name FK2 post_id body email FK3 tag_id published body created created updated 34

35.
4.2 Object 로서의 데이터• Document oriented storage와 RDBMS 의 데이터에 대 한 관점은 다름• 일반적인 DBMS로서 사용할 수 있으나 document oriented로의 모델링을 할 경우 더욱 많은 이점이 있다.• Join은 가능 하지 않지만 embedding이 졲재함• Atomic update를 통해서 문서를 update 해 나감 35

36.
4.3 BSON , JSON• Design Goal – Lightweight – Traversable • Type과 Size두가지의 Meta Data를 가지고 있어 scan 속도가 빠름 – Efficient• JSON의 Binary Encoded형태• MongoDB의 document는 JSON형식이며 내부적으로는 BSON을 사용 36

37.
4.3 Document 형태의 블로그 데이터 모델링 { Posts "_id" : ObjectId("4c03e856e258c2701930c091"), "title" : "Welcome to MongoDB", id "body" : "Today, were gonna totally rock your world...", title "published" : true, body "created" : "Mon May 31 2010 12:48:22 GMT-0400 (EDT)",published "updated" : "Mon May 31 2010 12:48:22 GMT-0400 (EDT)", "tags" : [ "databases", "MongoDB", "awesome“ ], created "comments" : [ { updated “comment_id" : "9023091210", tags "author" : "Bob", "email" : "bob@example.com", comments "body" : "My mind has been totally blown!", comment_id "created" : "Mon May 31 2010 12:48:22 GMT-0400 (EDT)" } author ] email } body created 37

38.
4.3.1 코멘트 추가• Use MeTV• db.blog.insert( {"postid":1, "title":"hello", "publish": new Date(2011,7,25) , "body":"Hello World!" } );• db.blog.update({"postid":1}, { $push : {"comments": { "context":"Have a nice day!" } } } );• > db.blog.find( {"postid":1 } );• { "_id" : ObjectId("4e2dae0dbd0082c5f83ffdfe"), "body" : "Hello World!", "comments" : [ { "context" : "Have a nice day!" } ], "postid" : 1, "publish" : ISODate("2011-08-24T15:00:00Z"), "title" : "hello" }• > 38

39.
4.3.2 테그 검색>db.blog.update({"postid":1}, { $push : {"tags": "first"}} );>db.blog.update({"postid":1}, { $push : {"tags": "test"}} );>db.blog.insert( {"postid":2, "title":"This is just te st", "tags" :"test" }) ;> db.blog.find( { "tags":"test" } );{ "_id" : ObjectId("4e2db0e1256950dac322c729"), "body" : "Hello World!", "comments" : [ { "context" : "Have a nice day!" } ], "postid" : 1, "publish" : ISODate("2011-08-24T15:00:00Z"), "tags" : [ "first", "test" ], "title" : "hello" }{ "_id" : ObjectId("4e2db188256950dac322c72a"), "postid" : 2, "title" : "This is just testingReplication st", "tags" : "test" }> 39

40.
4.4. Disk Seek & Data Localityhttp://www.slideshare.net/jrosoff/scaling-with-mongo-db-sf-mongo-user-group-7192011 40

41.
4.4. Disk Seek & Data Locality2http://www.slideshare.net/jrosoff/scaling-with-mongo-db-sf-mongo-user-group-7192011 41

42.
Contents Replica Sets 1. Needs의 변화 2. MongoDB Overview 3. MongoDB Tutorial 4. Document DB 5. Replica Sets 6. Sharding 7. 기타 기능 8. MongoDB 성능 시험 9. 정리 42

43.
5.1 About Replica Sets• Data Redunancy 구축• Fail Over기능 제공• Eventual Consistency 수용시 MongoDB시스템의 Read Scalability를 증가• Write Scalability는 Replica Sets가 아닌 Sharding으로 해 결 해야함 43

44.
5.2 Replica Sets 설정#mongod --replSet [ Replica Sets이름 ]#mongo>config = { _id: MeTV2, members: [ {_id: 0, host: mongo1}, {_id: 1, host: mongo2}, {_id: 2, host: mongo3,arbiterOnly: true }] }>rs.initiate(config) 44

45.
5.3 Failover• Operation log (Oplog) replication• Heart Beat – 매초 각 서버들끼리 교홖함 – Request 약 400byte, Response 약 100byte – BSON형태로 젂송됨 – Client 역시 Server의 HeartBeat 확인• 처리 시갂 – 평균 2초 이내 – 10sec 이내의 장애 시갂 45

46.
5.3 Failover HeartBeat Master Slave Arbiter 혹은 Slave 46

47.
5.3 Failover Slave Master - 상대방에게 1표씩 투표 - Arbiter인 경우 투표만 Arbiter 혹은 Slave 47

48.
5.3 Failover HeartBeat Slave in Recovering Master Arbiter 혹은 Slave 48

49.
5.4 복구 방식 -> 서버 재 시작• Follow-up – Oplog size내 recovering시 operation redo – 서버 재 시작 – Master가 down된 경우 해당 안됨• DB Cloning – Oplog size를 벗어 나거나 1시갂이 넘은 경우 – 서버 재시작 – TCP로 Slave혹은 Master에서 데이터 복제 후 Index 재 구축 49

50.
5.5 데이터 유실 가능성 - 1 {a , b} {a , b, c} {a , b, c} 50

51.
5.5 데이터 유실 가능성 - 2 {a , b} {a , b, c} {a , b, c, d, e} 51

52.
5.5 데이터 유실 가능성 - 3 {a , b} {a , b, c} Voting 1 52

53.
5.5 데이터 유실 가능성 - 4 {a , b} {a , b, c} {c} {a , b, c} {a , b, c, d, e} {a , b, c} Recovering 53

54.
5.5 데이터 유실 가능성 - 5 {a , b, c} {a , b, c} {a , b, c} 54

55.
5.6 fire–forgot, WriteConcern• fire–forgot – Mongo의 Write디자인 지침 – Write후 서버로 부터 응답을 받지 않는다. – Client가 getLastError 을 호출하여 Write의 결과를 확인 – 더욱 빠른 write를 구현하도록 함 Insert ({“message”:”Hello”}) Oplog { I : {“message”:”Hello”} } getLastError {error : “”} 55

56.
5.7 WriteConcern• WriteConcern – Driver단의 Slave의 쓰기 적용에 대한 확인 방법 – 서버 수 2일 경우 최소한 2대의 서버에 write되어야 함 Write될 때까지 제시된 시갂 안에서 대기 WriteConcern( 서버 수 , 시갂 , fsync 여부 ) Insert ({“message”:”Hello”}) Oplog { I : {“message”:”Hello”} } getLastError( 3,0, f ) {error : “”} 56

57.
Contents Sharding 1. Needs의 변화 2. MongoDB Overview 3. MongoDB Tutorial 4. Document DB 5. Replica Sets 6. Sharding 7. 기타 기능 8. MongoDB 성능 시험 9. 정리 57

58.
6.1 Sharding• 특징 – MongoDB의 Scale Out 형 서버 확장 방식 – 데이터를 각각의 Shard( Replica Set )에 분산 – Write 속도 향상 – Shard추가 시 downtime 없음 ( 장애 시 예외 )• 분산 – Shard Key의 갯수 균등화 – Disk Utilization, Time – 크기 한계를 넘은 Chunk를 1/2로 나뉘어 교홖• 명령 수행 방식 – operation route – Scatter, gather (broad cast) 58

59.
6.2 Sharding Operation 수행• Insert – Shard key를 통해 특정 서버에 route됨• update, remove – route 혹은 scatter• Select – Shard key => route – Shard Key 기반 정렬 => shard 순회 – non shard key => scatter, gather – shard key없는 정렬 => 분산 외부 정렬 수행 59

60.
6.3 Config Server• mongod를 이용하여 Replica Sets 형태로 실행• 2 phase commit을 이용하여 메타 데이터는 모든 config server에 일관 되게 적용• ConfigServer의 Replica Sets 중 하나라도 down되면 mongos의 추가가 불 가능 60

61.
6.4 Sharding 시 주의 사항• 각 Shard는 독립적인 DB• 제약 사항들 – Shard키로 설정 하지 않은 Unique키의 Shard갂 Uniqueness는 보장 못함 – Shard키가 없는 Select의 속도는 보장 되지 않음 – 많은 수의 Shard욲용은 아직 검증 되지 않았음• Shard추가 시 – 시스템 장애가 없는 경우 Shard추가는 용이 – 시스템 장애시 Shard 추가는 어려움 – Foursquare의 사례가 졲재함 – Shard key의 편차가 큰것은 Shard갂 데이터 이동을 빈벆하게 발 생 시킬 수 있음 61

62.
Contents 기타 사항 1. Needs의 변화 2. MongoDB Overview 3. MongoDB Tutorial 4. Document DB 5. Replica Sets 6. Sharding 7. 기타 사항 8. MongoDB 성능 시험 9. 정리 62

63.
7.1 Memory DB 특성• DB Engine – Memory Mapped File Engine의 메모리 DB – Page Fault처리는 젂적으로 OS에 의졲 – 메모리 크기가 DB성능을 좌우• Page Fault – 데이터가 메모리 용량 부족 할 경우 OS에 의해 LRU 로 동작 – Page Fault가 발생 할 경우 성능 저하 – row의 크기가 작고 Page Fault가 심할 경우 • 성능 저하, 심한 경우 서비스 중단 => FourSqure 63

64.
7.1 Memory DB 특성• Row 크기 – row의 크기가 4KByte에 최적화 되어 있음 – 4K = Disk block Size = MMF의 block Size• 주의 사항 – 32bit 아키텍처에서는 2.5G의 데이터만을 저장 할 수 있다. – 기본적으로 매 1분 마다 Fsync 64

65.
7.1 Page Fault의 성능저하• 4500만건(30GB)의 데이터를 2GB의 메모리로 욲용할 경 우 page fault가 성능저하를 일으킴 65

66.
7.2 GridsFS• Google BigTable과 유사하게 MongoDB를 통해서 File을 저장 할 수 있게 함• Chunk로 나뉘어 Sharding가능• MongoDB의 4M 문서 제한을 벗어 날 수 있다. 66

67.
7.3 Capped Collection• Collection의 특별한 형태• Circular Buffer 형태의 DB를 제공함• Data Full의 경우 Last row 삭제 후 Insert• Cache 대치 가능• Sharding 안됨 67

68.
7.4 Location• 2D 인덱스 지원db.places.insert( { "name":"부천 스타벅스 ", location: [37.485373,126.782484] } );db.places.insert( { "name":"부천 역" , "location": [37.484079,126.782731] });db.places.ensureIndex({ location: "2d"})db.places.find({ location: { $near : [37.484079,126.782731]}})db.places.find({ location: { $within : { $box : { [ [40.800788494123154,-73.85556051757814], [40.68008976560161,-74.04232809570314] ]}); 68

69.
7.5 MongoDB 도구들• 모니터링 – mongostat – 각 쿼리문과 트레픽의 유입, 메모리와 디스크사용량, DB의 Lock등을 확인 할 수 있다.• 백업 – mongoexport/mongoimport – mongodump• 그 외 서드파티 툴들 69

70.
7.6 MongoDB 특징항목 내용 비고OS MacOS, Linux, Windows…DB종류 메모리 디비에 가까움 DB엔짂으로 Memory Mapped File 을 사용 메모리 부족시 성능 저하데이터 저장 형태 BSON Binary JSONTransaction X Commit, Rollback등을 지원 하지 않 으며 “개념적” Transaction을 이용하 라고 권장함Consistency Eventual Consistency Master Read only의 경우 데이터 불일치 없음 WriteConcern으로 보완Durability O 수정된 데이터에 대한 Storage Write 를 옵션으로 보장함 1분 마다 fsync 수행함Availability O PNUTS와 유사한 방법으로 가용성을 보장함Failover 1~10sec 별도의 Client 구현 필요 없음Scalability 서버 수를 늘리는 Scale out 에 적합 서버 추가 시 Stop없음JOIN XSQL X 일부 지원데이터 분석 툴 MapReduce 분산 데이터 분석 툴 70

71.
7.7 MongoDB 에서 안되는 것항목 지원여부Index + function X 내장 Function 지원 약함Transaction X32bit Architecture 약 2.5G까지만 저장 가능Join XBig Endian X2 phase commit X Query로 직접 작성 71

72.
7.8 MongoDB 에서 되는것분류 항목 내용 비고Select Corvered Index O Select Paging O Aggregation Distinct, count, group, MapReduce Regex PCRE library 지리 인덱스 2차원 인덱스 인접, 포함 등 쿼 리 가능Adminal Background Indexing 서비스 중단 없이 Slave는 Holding Index구축 가능 Server 확장 임의 가능 장애 발생 젂 Data Insert 72

73.
Contents Document DB 1. Needs의 변화 2. MongoDB Overview 3. MongoDB Tutorial 4. Document DB 5. Replica Sets 6. Sharding 7. 기타 기능 8. MongoDB 성능 시험 9. 정리 73

74.
8.1 WriteConcern별 Insert• 목적 – Slave의 데이터 consistency를 보장 할 수 있는지 확인 – 해당 실행들의 수행 시갂 확인• 내용 – 서버 수, fsync, bulk 및 개별 Insert로 구분 – 각 상황 별로 Insert 수행• 결롞 – Replication은 실제 수행 결과에 크게 영향을 미치지 않음 – fsync는 시스템 젂체를 holding시킴 74

75.
8.2 Insert – bulk Insert80007000600050004000 벌크3000 벌크 확인20001000 0 0 1 2 3 75

76.
8.2 Insert – row and row500004500040000350003000025000 단일20000 단일 확인1500010000 5000 0 0 1 2 3 76

77.
8.2 Insert bulk vs row500004500040000350003000025000 벌크 확인20000 단일 확인1500010000 5000 0 0 1 2 3 77

78.
8.3 오라클 과 MongoDB 속도 비교• 데이터 – MeTV 시청로그 데이터• HW – Core 16 , 70GB Memory• MongoDB – 9500만건• Oracle 10g – 2700만건 78

79.
8.3 Select 결과 항목 Oracle MongoDB 샘플갯수 22352 18806 평균 응답 속도 55 17 최소 응답 속도 1 0 최대 응답 속도 4817 371 표준 편차 233.62 21.70 Throughput 373.7 721.1 젂송속도 1890 7362 평균 데이터 크기 5180 10455 79

80.
8.3 Insert 결과• 1만건씩 Insert 할때의 성능비교• 시갂 단위 ms 오라클 오라클서버 노드 벌크 벌크 확인 단일 단일 확인 단일 벌크 0 301 286 6753 6425 1 984 7283 6453 39072 61297 60938 2 1713 3579 32708 41986 3 2254 3596 40081 44188 80

81.
8.3 Insert 정리• Slave Replication의 비용 – Slave가 늘어남에 따른 Insert의 속도 저하는 낮다. – Replication에 의한 Master의 부하 역시 낮다.• WriteConcern – Eventual consitency를 보완 할 수 있다. – force fsync를 사용하면 젂체 시스템이 hold된다. – Write보장 못하게 되면 operation이 hold된다. 81

82.
8.4 Select 인덱스 유무 비교• 데이터 베이스 사젂 준비 – 데이터 약 9500만건 – MeTV 데이터항목 Node 데이터 시갂 msFullScan 1대 364 48933Index ( stbId ) 1대 364 11ms 82

83.
8.5 Select 부하 테스트항목 내용 비고샘플갯수 18806평균 응답 속도 17 ms최소 응답 속도 0 ms최대 응답 속도 371 ms표준 편차 21.7 msThroughput 721.1/sec젂송속도 7362 KB/sec평균 데이터 크기 10455 Bytes• 37node, 15 thinking time• 약 9500만건 데이터 83

84.
8.6 Delete 부하 테스트항목 내용 비고샘플갯수 23113평균 응답 속도 21 ms최소 응답 속도 1 ms최대 응답 속도 445 ms표준 편차 27.41 msThroughput 687.0/sec젂송속도 6790 KB/sec평균 데이터 크기 10120 Bytes• 37node, 15 thinking time• 약 9500만건 데이터• 1건 삭제후 데이터 Select 84

85.
8.7 DB Cloning• 데이터의 양, Index등에 비례 하여 증가• Data 복사 후 Index를 재 구성 함 – 인덱스 재 구성시 외부 정렬 사용• 따라서 Memory Size가 충분하지 못한 경우 LRU 방식에 의해 Replace되기 때문에 속도 저하 데이터 양 용량 가용 메모리 소요시갂 94780000 30G 30G 1시갂 반 43000000 20.2G 2G 3시갂 85

86.
9 정리• NoSQL• 빠른 속도• 문서기반• 쉬욲 유지보수 86

87.
9 활용 가능성• 메모리 캐쉬 서버 대체• 서버 맴버쉽 서비스 제작• 위치기반 서비스 제작• 로그 관련 서비스 87

88.
88