Your SlideShare is downloading. ×
Mongodb 특징 분석
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Mongodb 특징 분석

14,264

Published on

Published in: Technology
1 Comment
25 Likes
Statistics
Notes
No Downloads
Views
Total Views
14,264
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
449
Comments
1
Likes
25
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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

×