MongoDB 개발 포인트

티쓰리엔터테인먼트 모바일 1 팀공통 기술 개발팀최흥배 과장

MongoDB Best Practices

항상 Replica Set 을 사용하라Replica Set 은 장애시 자동 Failover 를 통해서 HA( 고 가용성 ) 를 지원한다 .

항상 최신 버전을 유지하라 MySQL 처럼 오래된 패키지는 새 버전이 나오면 오랜 검증으로 적용되지만 NoSQL 같은 경우는 Bug fix 가 많으므로 항상 최신버전을 유지 해주는것이 중요다 .

항상 최신 버전의 문서를 봐라 웹이나 책에 있는 내용은 이전 버전에 관한 것으로 현재 버전과 틀린 내용이 꽤 있다 . 문서를 볼 때는 언제 만들어졌는지 정확한지 잘 확인 해야 한다 .

http://www.engineyard.com/blog/2011/mongodb-best-practices/

MongoDB Best Practices

MongoDB 는 32Bit 에서 사용하지 마라 32bit 시스템에서는 MongoDB 는 2.5GB 의 데이터 밖에 사용할 수 없다 . Storage Engine 이 성능상의 이유로 Mem-ory-Mapped Filed 을 사용하고 , 이로 인해 메모리 어드레싱이 2.5 까지 밖에 사용할 수 없기 때문 . MongoDB 는 Index Size 가 메모리보다 커지면 속도에 큰 저해가 오기 때문에 메모리를 넉넉하게 사용하는게 좋다 . ( 포스퀘어는 서버한대당 64G 메모리 사용 )

기본적으로 Journaling 을 사용하라MongoDB 는 장애 복구나 노드의 안전성을 위해서 Write-Ahread 저널링을 지원한다 .

http://www.engineyard.com/blog/2011/mongodb-best-practices/

MongoDB Best Practices

데이터 파일의 위치를 확인하라MongoDB 는 기본적으로 /tmp 디렉토리에 저장되는데 /tmp디렉토리를 주기적으로 OS 에서 삭제하는경우 문제가 될 수 있다 . Working Set 은 메모리 사이즈에 적합하게 유지하라Working Set(Index) 을 메모리에 두는 것은 클러스의 영향을 미치는 매우 중요한 요소이다 . Page Fault 가 증가하는 것을 알면 , 가용 메모리보다 Working Set 의 사이즈가 커진다는 것을 알 수 있는 매우 좋은 기회이다 . 가용 메모리보다 Working Set 데이터가 증가하면 두 가지 방법이 있다 . MongoDB 의 메모리 사이즈를 증가시키거나 , Sharding 을 하는 것 . Mon-goDB 의 메모리 사이즈를 증가시키는 것을 먼저 추천 !!!

http://www.engineyard.com/blog/2011/mongodb-best-practices/

MongoDB Best Practices

많이 사용한다면 Sale Up 하라 기기의 Load 가 65% 를 넘는다면 , Scaling up 을 고려해야 한다 . 평균적으로 동작할 때 Load 가 65% 이하여야 한다 . 복구나 , 수직 Scaling 상황에도 영향을 준다 . instance size를 늘려야 할 필요가 있다면 , AWS 는 Large, Extra Large, high Memory 4XL 순서로 업그레이드를 추천 . 그래픽적으로 모니터링 하려면 MongoMMS 를 사용하라

http://www.engineyard.com/blog/2011/mongodb-best-practices/

MongoDB Best Practices

Sharding 에 주의하라MongoDB 가 어떻게 Sharding 을 하고 정말로 Sharding 이 필요한지에 대해서 시간을 드려서 고민해야 한다 . 또 어플리케이션 성능에 영향을 미치기 때문에 좋은 Sharding Key를 선택하는 것이 중요하다 .

Config 서버는 클러스터의 상태에 중요한 역할을 한다 . 실제 Sharding 서비스 환경에서는 꼭 3 대의 Config 서버가 필요하다 . 항상 Config 서버의 데이터를 백업하고 확인하고 절대로 데이터를 지우면 안 된다 .Config 서버는 경량 프로세스이지만 64bit 장비에서 동작해야 한다 . 3 개의 config 서버를 한대에 장비에 넣어서는 안 된다 .

http://www.engineyard.com/blog/2011/mongodb-best-practices/

문서 설계RDBMS 와 달리 NoSQL 에서는 정규화는 추천 되지 않는다 .

데이터를 분할하지 않고 문서로 보존하는 쪽이 데이터가 같은 장소에 보존 되어 서버간 통신 횟수도 줄여준다 .

문서 설계가 가장 중요하고 , 가장 힘들다 .

문서 설계에서는 'modifier 오퍼레이션 ' 과 ' 데이터 배열에 의한 유지 ' 를 유효하게 사용할 수 있는 설계로 변경한다 .

또 이미지 바이너리 데이터의 캐시를 MongoDB 에 하여 데이터 획득과 캐시 획득을 한번에 하도록 한다 .

트랜잭션이 필요 없는 데이터 구조트랜잭션 처리에 취약하므로 유저 정보 등은 1 개의 문서로 보호해서 일괄 갱신 하도록 한다 .

데이터 크기를 최소화 한다구조화된 데이터 보다 압축된 데이터를 사용하는 것이 좋다

다만 데이터 분석이 까다로워진다 .

필드 수가 너무 많지 않도록 한다2 만개 이상의 필드를 가지면 find() 에 걸리는 시간은 5 초 이상 ...

데이터 크기 뿐만이 아닌 BSON Parse 에 걸리는 시간도 고려한다 .

갱신 빈도를 최대한 줄인다마스터 정보는 서버에서 캐시 한다 .

유저 조작을 모아서 한번에 처리한다 (5 초에 1 번 )

쿼리 튜닝explain 을 사용하여 상태를 본다

앞에 만들었던 INDEX 를 이용하고 있다 .

실행 계획의 예측 실행 시간이 빨라졌다 !!

성능 저하를 일으키는 동작데이터 접근

- 물리 메모리가 아닌 가상 메모리를 사용하면 느려진다 .

인덱스

락- 락의 단위는 데이터베이스 , 읽기는 복수 접근 가능

져널- 안정성은 높아지지만 디스크 접근이 발생하므로 처리 성능이 감소

문서 재배치

처리 성능을 올리는 방법1. 서버의 물리 메모리를 많이 준비한다 .

2. 빠른 속도를 가진 디스크를 사용한다 .

3. 인덱스를 잘 건다 .

4. 락이 걸리지 않도록 문서 설계와 질의문을 만든다 .

5. 문서에 필요한 필드를 처음부터 만들어 놓는다 .- 문서 재배치가 일어나지 않도록 기본 값을 미리 만든다 .

6. 저널의 쓰기 횟수를 줄인다 .- --journalCommitInterval 옵션을 지정하여 쓰기 간격을 넓게 한다 . ( 또는 --nojournal 옵션으로 사용 안한다 )