mongodb 특징 분석

2011년 7월 27일 수요일

솔루션 2팀 싞대용

[email protected]

소개

디지캡 솔루션 2팀

싞대용

1. Needs의변화

2. MongoDB Overview

3. MongoDB Tutorial

4. Document DB

5. Replica Sets

6. Sharding

7. 기타사항

8. MongoDB 성능시험

9. 정리

2

Contents

3

1. Needs의 변화

• Object– 이제는 Object로 생각함

– Object개념의 시스템 설계

– RDBMS를 사용하기 위해서 별도의 데이터 베이스 설계.

– ORM 등장

• XML, JSON등 Flexible 데이터– RDBMS는 XML등에 최적화 되어 있지 않음

4

1.1 Needs Data에 대한 시각

• 급격한 데이터 증가 수용

• Downtime없는 DB

• 지리적 DB분산

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

5

1.2 기업들의 요구 사항

6

1.3 CAP 이론

• 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

1.4 NoSQL! - Google BigTable

• 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

1.4 NoSQL! - Amazon Dynamo

• 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

1.4 NoSQL! - Yahoo PNUTS

• Requirements– High availability

– Eventual consistency

– Incremental scalability

– Optimistic replication

• Developed by Facebook– Facebook에서는 새로 개발중

– BigTable, Amazon Dynamo기반

• P2P 속성

• 컬럼 기반

10

1.4 NoSQL! - Apache Cassandra

• Low response time

• Scalability

• High Availability and Fault Tolerance

• Flexible schemas

• Distribution

• Low cost로!!!

• Consistency, Integrity, Transaction 포기

11

1.5 NoSQL Needs

1. Needs의변화

2. MongoDB Overview

3. MongoDB Tutorial

4. Document DB

5. Replica Sets

6. Sharding

7. 기타사항


9. 정리

12

Contents

Overview

13

2.1 MongoDB?

Replica Sets

Sharding

Eventual Consistency

• 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

2.1 MongoDB?

15

2.1 Memcache와 RDBMS의 사이

16

2.2 적용 사례들

• Yottaa– Web Site Performance 분석 서비스

• 요구사항– 데이터가 급격히 증가, Scalable 필수

– 인프라 관리 인원이 없음, 쉬욲 관리 필수

– 수시로 바뀌는 요구 사항에 맞출 수 있어야 함

– 100% 클라우드 시스템에 올릴 수 있어야 함

17

2.3 적용 사례 - Yottaa

http://www.slideshare.net/jrosoff/scaling-rails-yottaa






18

2.3 Yottaa 기존

19

2.3 Yottaa Master – Slave 구조

20

2.3 Yottaa Master – Master 구조

21

2.3 Yotta 최종 적용

22

2.4 시스템 구성

Client

Configure

Mongos

Shards

Replica Sets

• Master– Read, Write를 수행

• Slave– Master로서 oplog를 젂송 받아 replication 수행

– Client의 Read Operation만 처리

– Read Scale ability 증가 (Slave Ok 옵션 시)

– Master down시 투표를 통해 Master가 됨23

2.4.1 Replica Sets

Slave

Master

Arbiter

Client

• 목적– 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

2.4.2 Replica Sets

• Sharding Router – Scale Out 수행

– Write Scalability 증가

– Client에게는 단일 mongod로 보이며 client의 요청을 shard에 젂달

– Shard갂 Data를 분산

25

2.4.3 mongos

1. Needs의변화

2. MongoDB Overview

3. MongoDB Tutorial

4. Document DB

5. Replica Sets

6. Sharding

7. 기타사항


9. 정리

26

Contents

Tutorial

1. 디렉토리 준비

# mkdir /svc/mongodb/opt /svc/mongodb/server /svc/mongodb/data -p

# cd /svc/mongodb/opt

2. 다욲로드, 설치

# 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/server

3. 실행

# 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-bit

Tue Jul 26 01:12:35 [initandlisten] db version v1.8.2, pdfile version 4.5

Tue Jul 26 01:12:35 [initandlisten] git version: 433bbaa14aaba6860da15bd4de8edf600f56501b

Tue 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_41

Tue Jul 26 01:12:35 [initandlisten] waiting for connections on port 27017

Tue Jul 26 01:12:35 [websvr] web admin interface listening on port 28017

27

3.1 설치

http://www.mongodb.org/dr/fastdl.mongodb.org/linux/mongodb-linux-x86_64-1.8.2.tgz/download







• 관리자 접속

28

3.1 monogdb 관리자 화면

[root@mongo205 ~]# mongo

MongoDB shell version: 1.8.2

connecting to: test

> use MeTV #데이터 베이스 사용

switched to db MeTV

> db.purchase.count(); #테이블(Collection) 사용

0

29

3.2 CRUD - 접속 및 DB생성

Insertdb.[collection].insert ( 내용 );

Selectdb.[collection].find( 조건 );

Updatedb.[collection].find( 조건, 내용 );

Deletedb.[collection].remove( 조건 );

30

3.2 CRUD - 명령들

>use MeTV

switched to db MeTV

> db.test.insert( { 'message':'hello world!'} );

>

> db.test.find();

{ "_id" : ObjectId("4e2da0f3a051ab4638e3c72b"), "message" : "hello world!" }

> db.test.count();

1

>

31

3.2 Insert , Select

>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

3.3 update, remove

1. Needs의변화

2. MongoDB Overview

3. MongoDB Tutorial

4. Document DB

5. Replica Sets

6. Sharding

7. 기타사항


9. 정리

33

Contents

Document DB

34

4.1. 블로그 데이터 모델링

tags

PK id

name

posts_tags

PK id

FK2 post_idFK3 tag_id

posts

PK id

title slug body published created updated

comments

PK id

FK1 post_id author email body created

• Document oriented storage와 RDBMS 의 데이터에 대한 관점은 다름

• 일반적인 DBMS로서 사용할 수 있으나 document oriented로의 모델링을 할 경우 더욱 많은 이점이 있다.

• Join은 가능 하지 않지만 embedding이 졲재함

• Atomic update를 통해서 문서를 update 해 나감

35

4.2 Object 로서의 데이터

• Design Goal– Lightweight

– Traversable

• Type과 Size두가지의 Meta Data를 가지고 있어 scan 속도가 빠름

– Efficient

• JSON의 Binary Encoded형태

• MongoDB의 document는 JSON형식이며 내부적으로는BSON을 사용

36

4.3 BSON , JSON

{

"_id" : ObjectId("4c03e856e258c2701930c091"),

"title" : "Welcome to MongoDB",

"body" : "Today, we're gonna totally rock your world...",

"published" : true,

"created" : "Mon May 31 2010 12:48:22 GMT-0400 (EDT)",

"updated" : "Mon May 31 2010 12:48:22 GMT-0400 (EDT)",

"tags" : [ "databases", "MongoDB", "awesome“ ],

"comments" : [ {

“comment_id" : "9023091210",

"author" : "Bob",

"email" : "[email protected]",

"body" : "My mind has been totally blown!",

"created" : "Mon May 31 2010 12:48:22 GMT-0400 (EDT)"

}

]

}

37

4.3 Document 형태의 블로그 데이터 모델링

Posts

id

title

published

created

body

updated

comments

author

email

body

created

comment_id

tags

• 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

4.3.1 코멘트 추가

>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

4.3.2 테그 검색

40

4.4. Disk Seek & Data Locality

http://www.slideshare.net/jrosoff/scaling-with-mongo-db-sf-mongo-user-group-7192011


















41

4.4. Disk Seek & Data Locality2



















1. Needs의변화

2. MongoDB Overview

3. MongoDB Tutorial

4. Document DB

5. Replica Sets

6. Sharding

7. 기타기능


9. 정리

42

Contents

Replica Sets

• Data Redunancy 구축

• Fail Over기능 제공

• Eventual Consistency 수용시 MongoDB시스템의 Read Scalability를 증가

• Write Scalability는 Replica Sets가 아닌 Sharding으로 해결 해야함

43

5.1 About Replica Sets

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)

• Operation log (Oplog) replication

• Heart Beat – 매초 각 서버들끼리 교홖함

– Request 약 400byte, Response 약 100byte

– BSON형태로 젂송됨

– Client 역시 Server의 HeartBeat 확인

• 처리 시갂– 평균 2초 이내

– 10sec 이내의 장애 시갂

45

5.3 Failover

46

5.3 Failover

Master Slave

Arbiter 혹은 Slave

HeartBeat

47

5.3 Failover

Master

Slave


- 상대방에게 1표씩 투표- Arbiter인 경우 투표만

48

5.3 Failover

Slave in Recovering Master


HeartBeat

• Follow-up– Oplog size내 recovering시 operation redo

– 서버 재 시작

– Master가 down된 경우 해당 안됨

• DB Cloning– Oplog size를 벗어 나거나 1시갂이 넘은 경우

– 서버 재시작

– TCP로 Slave혹은 Master에서 데이터 복제 후 Index 재 구축

49

5.4 복구 방식 -> 서버 재 시작

50

5.5 데이터 유실 가능성 - 1

{a , b, c}

{a , b, c}{a , b}

51


{a , b, c, d, e}

{a , b, c}{a , b}

52


{a , b, c}{a , b}

Voting 1

53


{a , b, c}{a , b}

{ c }

Recovering

{a , b, c, d, e}

{a , b, c}

{a , b, c}

54


{a , b, c}{a , b, c}

{a , b, c}

• fire–forgot– Mongo의 Write디자인 지침

– Write후 서버로 부터 응답을 받지 않는다.

– Client가 getLastError 을 호출하여 Write의 결과를 확인

– 더욱 빠른 write를 구현하도록 함

55

5.6 fire–forgot, WriteConcern

Insert ({“message”:”Hello”}) Oplog { I : {“message”:”Hello”} }

getLastError

{error : “”}

• WriteConcern– Driver단의 Slave의 쓰기 적용에 대한 확인 방법

– 서버 수 2일 경우 최소한 2대의 서버에 write되어야 함Write될 때까지 제시된 시갂 안에서 대기

56

5.7 WriteConcern

WriteConcern( 서버 수 , 시갂 , fsync 여부 )

Insert ({“message”:”Hello”}) Oplog { I : {“message”:”Hello”} }

getLastError( 3,0, f )

{error : “”}

1. Needs의변화

2. MongoDB Overview

3. MongoDB Tutorial

4. Document DB

5. Replica Sets

6. Sharding

7. 기타기능


9. 정리

57

Contents

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

6.1 Sharding

• Insert– Shard key를 통해 특정 서버에 route됨

• update, remove– route 혹은 scatter

• Select– Shard key => route

– Shard Key 기반 정렬 => shard 순회

– non shard key => scatter, gather

– shard key없는 정렬 => 분산 외부 정렬 수행

59

6.2 Sharding Operation 수행

• mongod를 이용하여 Replica Sets 형태로 실행

• 2 phase commit을 이용하여 메타 데이터는 모든 configserver에 일관 되게 적용

• ConfigServer의 Replica Sets 중 하나라도 down되면mongos의 추가가 불 가능

60

6.3 Config Server

• 각 Shard는 독립적인 DB

• 제약 사항들– Shard키로 설정 하지 않은 Unique키의 Shard갂 Uniqueness는

보장 못함

– Shard키가 없는 Select의 속도는 보장 되지 않음

– 많은 수의 Shard욲용은 아직 검증 되지 않았음

• Shard추가 시– 시스템 장애가 없는 경우 Shard추가는 용이

– 시스템 장애시 Shard 추가는 어려움

– Foursquare의 사례가 졲재함

– Shard key의 편차가 큰것은 Shard갂 데이터 이동을 빈벆하게 발생 시킬 수 있음

61

6.4 Sharding 시 주의 사항

1. Needs의변화

2. MongoDB Overview

3. MongoDB Tutorial

4. Document DB

5. Replica Sets

6. Sharding

7. 기타사항


9. 정리

62

Contents

기타 사항

• DB Engine– Memory Mapped File Engine의 메모리 DB

– Page Fault처리는 젂적으로 OS에 의졲

– 메모리 크기가 DB성능을 좌우

• Page Fault– 데이터가 메모리 용량 부족 할 경우 OS에 의해 LRU 로 동작

– Page Fault가 발생 할 경우 성능 저하

– row의 크기가 작고 Page Fault가 심할 경우

• 성능 저하, 심한 경우 서비스 중단 => FourSqure

63

7.1 Memory DB 특성

• Row 크기– row의 크기가 4KByte에 최적화 되어 있음

– 4K = Disk block Size = MMF의 block Size

• 주의 사항– 32bit 아키텍처에서는 2.5G의 데이터만을 저장 할 수 있다.

– 기본적으로 매 1분 마다 Fsync

64

7.1 Memory DB 특성

65

7.1 Page Fault의 성능저하

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

• Google BigTable과 유사하게 MongoDB를 통해서 File을저장 할 수 있게 함

• Chunk로 나뉘어 Sharding가능

• MongoDB의 4M 문서 제한을 벗어 날 수 있다.

66

7.2 GridsFS

• Collection의 특별한 형태

• Circular Buffer 형태의 DB를 제공함

• Data Full의 경우 Last row 삭제 후 Insert

• Cache 대치 가능

• Sharding 안됨

67

7.3 Capped Collection

• 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

7.4 Location

• 모니터링– mongostat

– 각 쿼리문과 트레픽의 유입, 메모리와 디스크사용량,

DB의 Lock등을 확인 할 수 있다.

• 백업– mongoexport/mongoimport

– mongodump

• 그 외 서드파티 툴들

69

7.5 MongoDB 도구들

항목 내용 비고

OS MacOS, Linux, Windows…

DB종류 메모리 디비에 가까움 DB엔짂으로 Memory Mapped File을 사용 메모리 부족시 성능 저하

데이터 저장 형태 BSON Binary JSON

Transaction 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 X

SQL X 일부 지원

데이터 분석 툴 MapReduce 분산 데이터 분석 툴

70

7.6 MongoDB 특징

항목 지원여부

Index + function X 내장 Function 지원 약함

Transaction X

32bit Architecture 약 2.5G까지만 저장 가능

Join X

Big Endian X

2 phase commit X Query로 직접 작성

71

7.7 MongoDB 에서 안되는 것

분류 항목 내용 비고

Select Corvered Index O

Select Paging O

Aggregation Distinct, count, group, MapReduce

Regex PCRE library

지리 인덱스 2차원 인덱스 인접, 포함 등 쿼리 가능

Adminal Background Indexing 서비스 중단 없이Index구축 가능

Slave는 Holding

Server 확장 임의 가능 장애 발생 젂

Data Insert

72

7.8 MongoDB 에서 되는것

1. Needs의변화

2. MongoDB Overview

3. MongoDB Tutorial

4. Document DB

5. Replica Sets

6. Sharding

7. 기타기능


9. 정리

73

Contents

Document DB

• 목적– Slave의 데이터 consistency를 보장 할 수 있는지 확인

– 해당 실행들의 수행 시갂 확인

• 내용– 서버 수, fsync, bulk 및 개별 Insert로 구분

– 각 상황 별로 Insert 수행

• 결롞– Replication은 실제 수행 결과에 크게 영향을 미치지 않음

– fsync는 시스템 젂체를 holding시킴

74

8.1 WriteConcern별 Insert

75

8.2 Insert – bulk Insert

0

1000

2000

3000

4000

5000

6000

7000

8000

0 1 2 3

벌크

벌크 확인

76

8.2 Insert – row and row

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

0 1 2 3

단일

단일 확인

77

8.2 Insert bulk vs row

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

0 1 2 3

벌크 확인

단일 확인

• 데이터– MeTV 시청로그 데이터

• HW– Core 16 , 70GB Memory

• MongoDB– 9500만건

• Oracle 10g– 2700만건

78

8.3 오라클 과 MongoDB 속도 비교

항목 Oracle MongoDB

샘플갯수 22352 18806

평균 응답 속도 55 17

최소 응답 속도 1 0

최대 응답 속도 4817 371

표준 편차 233.62 21.70

Throughput 373.7 721.1

젂송속도 1890 7362

평균 데이터 크기 5180 10455

79

8.3 Select 결과

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

• Slave Replication의 비용– Slave가 늘어남에 따른 Insert의 속도 저하는 낮다.

– Replication에 의한 Master의 부하 역시 낮다.

• WriteConcern– Eventual consitency를 보완 할 수 있다.

– force fsync를 사용하면 젂체 시스템이 hold된다.

– Write보장 못하게 되면 operation이 hold된다.

81

8.3 Insert 정리

82

8.4 Select 인덱스 유무 비교

• 데이터 베이스 사젂 준비– 데이터 약 9500만건

– MeTV 데이터

항목 Node 데이터 시갂 ms

FullScan 1대 364 48933

Index ( stbId ) 1대 364 11ms

83

8.5 Select 부하 테스트

• 37node, 15 thinking time

• 약 9500만건 데이터


샘플갯수 18806

평균 응답 속도 17 ms

최소 응답 속도 0 ms

최대 응답 속도 371 ms

표준 편차 21.7 ms

Throughput 721.1/sec

젂송속도 7362 KB/sec

평균 데이터 크기 10455 Bytes

84

8.6 Delete 부하 테스트

• 37node, 15 thinking time

• 약 9500만건 데이터

• 1건 삭제후 데이터 Select


샘플갯수 23113

평균 응답 속도 21 ms

최소 응답 속도 1 ms

최대 응답 속도 445 ms

표준 편차 27.41 ms

Throughput 687.0/sec

젂송속도 6790 KB/sec

평균 데이터 크기 10120 Bytes

• 데이터의 양, Index등에 비례 하여 증가

• Data 복사 후 Index를 재 구성 함– 인덱스 재 구성시 외부 정렬 사용

• 따라서 Memory Size가 충분하지 못한 경우LRU 방식에 의해 Replace되기 때문에 속도 저하

85

8.7 DB Cloning

데이터 양 용량 가용 메모리 소요시갂

94780000 30G 30G 1시갂 반

43000000 20.2G 2G 3시갂

• NoSQL

• 빠른 속도

• 문서기반

• 쉬욲 유지보수

86

9 정리

• 메모리 캐쉬 서버 대체

• 서버 맴버쉽 서비스 제작

• 위치기반 서비스 제작

• 로그 관련 서비스

87

9 활용 가능성

mongodb 특징 분석

Technology