MongoDB, 이렇게 쓰세요Server Side Architecture Group Seminar

Feb, 2014 한대희

• 이음소시어스 개발자

• 서버 + 웹 개발 3년차

• nyamx2@gmail.com

• twitter @daeheehan

MongoDB란?• 10gen에서 만든 오픈소스 document database

• JSON-based storage

• 다양한 형태의 Index 지원

• 설치 & 도입 간편

• Replication & Auto Sharding

• High Performance & Strong Consistency

Document-oriented• Database (Database) - Collection (Table) - Document (Row) - Key (Column)

• Schemaless (<= 16MB/doc)

• Document = JSON (internally BSON)

• Query = JSON

_id• BSON ObjectID (Default)

• Primary Key

• 자체적으로 시간 순서 정렬

• 시간의 흐름에 따라 데이터가 쌓이는 식의 어플리케이션에 효율적

Replica Set• Primary-Secondary Replication

• Write only on Primary

• Async Duplication (Write Concern = 1)

Replica Set• Primary 장애시 Fail-over

Sharding• Vertical Scaling with Sharding

• Shard Key 설정 가능

왜 MongoDB를 선택했나?• 방대한 매칭 데이터 = 이음의 Bottleneck

• 1일 1매칭 (+a) x 100만 회원 x 365일 = ??

!

• Hey - 글로벌 데이팅 서비스

• 더 많은 회원 (10x 예상)

• 더 많은 매칭 (하루 3개의 매칭 + 추가 구매 가능)

• RDBMS로는 한계가 있지 않을까?

• Scalable하다는 MongoDB를 써보자!

왜 MongoDB를 선택했나?

MongoDB Apache HBase

설치, 운영 간편 Hadoop Cluster 필요

RDBMS 수준의 Index 지원 Index 관련 지원 빈약

Ruby ORM (Mongoid) 존재 Ruby gem은 있으나, low-level

Configuration

• Amazon EC2 (Marketplace에 있는 AMI 사용)

• m1.large x 2 (Replica Set) + t1.micro (Arbiter)(m1.large : 2 Core x 2 vCPU, 7.5GB)

• EBS with Provisioned I/O (1000 IOPS) - Page Fault 시 빠른 로딩을 위해!

• Total Cost ~= $700 / month

Monitoring• NewRelic (Lite)

- 기존 사용, 익숙해서 도입

- 간편, 똑똑, 무료

• MMS (https://mms.mongodb.com) - 훨씬 더 MongoDB에 특화된 모니터링

- Incremental Backup - 연간 사용료 $50이하 = 무료

Performance Comparison• vs MySQL (w/o index)

• Retrieving 5000/50000 from 10 million records

• Retrieving 5000/50000/500000 from 200 million records

!

!

!

• http://www.moredevs.ro/mysql-vs-mongodb-performance-benchmark/

1st 2nd

Read 0.3x 1.3 - 2x (w/o cache)

Write ~3x 2 - 3x

Query Language

• 모든 Query가 BSON (JSON) Object

• RDBMS에 비하면 불편 (특히 group by - aggregate)

• 오타와 타입에 매우 민감

Update & Delete• Document Growth가 일어나는 Update - 성능 저하

Update & Delete

• Document Growth -> Record Relocation -> Fragment

• Offline Repair만 가능

• Array Push, Field 추가 시 주의

• Padding Factor

Transaction• 하나의 Document - Atomic Operation 가능

• 여러 Document or 여러 Collection - 불가능

• Two-phase Commit 사용

!

• Operation의 순서가 바뀌어도 상관없도록 설계하거나,

• Atomic operation에 의존하지 않도록 설계해야 함

DB-level Lock• Database Level Lock

• 1 read & 1 write lock / database

• Write Lock > Read Lock

• 많은 데이터를 Insert 하는 도중 Read 불가능

• 오랜 시간이 걸리는 Read 쿼리는 수행 시간동안 Write를 Block

• Yield on Page Fault from 2.2

Relationship in MongoDB

• Embedding vs Referencing

• Embedding : 관련된 데이터를 하나의 문서에 몰아넣기

• Referencing : 관련된 데이터를 다른 collection으로 빼기

• 둘 다 그닥…

Embedding

• Simple

• High Performance

• No selective select

• Document Growth!!

• Danger of Duplication

Danger of Duplication

• So WET! (Update가 끔찍해짐)

• 바뀌지 않는 정보 (ex. ID) 만을 저장하면…

{! _id: ObjectId(...),! … : …,! author: {! id: ObjectId(...),! name: 'Rick'! },! text: 'This is so bogus ... '!}

{! _id: ObjectId(…),! name: ‘Rick’!}

{! _id: ObjectId(...),! … : …,! author: {! id: ObjectId(...),! name: 'Rick'! },! text: ‘Jenkins!!!’!}

Articles

Users

{! _id: ObjectId(…),! name: ‘Jack’!}

Referencing• RDBMS의 foreign key와 유사하나, 정합성 X

• MongoDB에서는 Join이 없음

• Application Level Join 필요 (귀찮고 느림)

• Document Growth는 마찬가지…

결론적으로…

• RDBMS와 비슷해서 선택했으나

• NoSQL로서의 특성이 훨씬 강함

• Scalability가 중요한 상황까지 도달하지도 않았음

• 성공적인 도입이라 말하기엔 좀…

• NoSQL은 NoSQL처럼, RDBMS는 RDBMS처럼

그럼 어디에 좋은가• 레코드간의 관계가 (거의) 없고

• 데이터가 순차적으로 증가하고

• 빠른 operation 속도와

• Scale-out이 필요한 어플리케이션

• 부담 없이 쓰기에 좋은 것이 MongoDB 최고의 장점!

• ex) 로그 프로세싱 (JSON 포맷, 속도), 채팅

!

• MySQL이 Scale-out이 안되니까 MongoDB를 사용하자?

굳이 MongoDB를 써야 하는가?• Join이 필요없는가?

• 잦은 Update나 Delete가 있진 않은가?

• Schemaless한 자료구조가 필요한가?

• Scalable Write가 필요한가?

• Sharding이 필요한가? (# of rows >= billion)

• MongoDB만으로 충분한가?

!

• 정말로?

감사합니다.