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 Arbiter
Client
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/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

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

29. 3.2 CRUD - 접속 및 DB생성
[root@mongo205 ~]# mongo
MongoDB shell version: 1.8.2
connecting 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 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

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 id
PK 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, we're 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 Locality
http://www.slideshare.net/jrosoff/scaling-with-mongo-db-sf-mongo-user-group-7192011
40

41. 4.4. Disk Seek & Data Locality2
http://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 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

71. 7.7 MongoDB 에서 안되는 것
항목 지원여부
Index + function X 내장 Function 지원 약함
Transaction X
32bit Architecture 약 2.5G까지만 저장 가능
Join X
Big Endian X
2 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 Insert
8000
7000
6000
5000
4000 벌크
3000 벌크 확인
2000
1000
0
0 1 2 3
75

76. 8.2 Insert – row and row
50000
45000
40000
35000
30000
25000 단일
20000 단일 확인
15000
10000
5000
0
0 1 2 3
76

77. 8.2 Insert bulk vs row
50000
45000
40000
35000
30000
25000 벌크 확인
20000 단일 확인
15000
10000
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 데이터 시갂 ms
FullScan 1대 364 48933
Index ( stbId ) 1대 364 11ms
82

83. 8.5 Select 부하 테스트
항목 내용 비고
샘플갯수 18806
평균 응답 속도 17 ms
최소 응답 속도 0 ms
최대 응답 속도 371 ms
표준 편차 21.7 ms
Throughput 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 ms
Throughput 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