어딘가에서 자료를 가져와서 짜집기 한 것입니다^^;

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

2. MongoDB Best Practices
항상 Replica Set을 사용하라
Replica Set은 장애시 자동 Failover를 통해서 HA( 고 가용성)
를 지원한다.
항상 최신 버전을 유지하라
MySQL 처럼 오래된 패키지는 새 버전이 나오면 오랜 검증으로
적용되지만 NoSQL 같은 경우는 Bug fix가 많으므로 항상 최신
버전을 유지 해주는것이 중요다.
항상 최신 버전의 문서를 봐라
웹이나 책에 있는 내용은 이전 버전에 관한 것으로 현재 버전과
틀린 내용이 꽤 있다. 문서를 볼 때는 언제 만들어졌는지 정확
한지 잘 확인 해야 한다.
http://www.engineyard.com/blog/2011/mongodb-best-practices/

3. MongoDB Best Practices
MongoDB는 32Bit 에서 사용하지 마라
32bit 시스템에서는 MongoDB는 2.5GB 의 데이터 밖에 사용할
수 없다. Storage Engine이 성능상의 이유로 Memory-Mapped
Filed을 사용하고, 이로 인해 메모리 어드레싱이 2.5 까지 밖에
사용할 수 없기 때문. MongoDB는 Index Size 가 메모리보다
커지면 속도에 큰 저해가 오기 때문에 메모리를 넉넉하게 사용
하는게 좋다. (포스퀘어는 서버한대당 64G 메모리 사용 )
기본적으로 Journaling을 사용하라
MongoDB는 장애 복구나 노드의 안전성을 위해서 WriteAhread 저널링을 지원한다.
http://www.engineyard.com/blog/2011/mongodb-best-practices/

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

5. 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/

6. 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/

7. 문서 설계
RDBMS와 달리 NoSQL에서는 정규화는 추천 되지 않는다.
데이터를 분할하지 않고 문서로 보존하는 쪽이 데이터가 같은
장소에 보존 되어 서버간 통신 횟수도 줄여준다.
문서 설계가 가장 중요하고, 가장 힘들다.
문서 설계에서는 'modifier 오퍼레이션'과 '데이터 배열에 의한
유지'를 유효하게 사용할 수 있는 설계로 변경한다.
또 이미지 바이너리 데이터의 캐시를 MongoDB에 하여 데이터
획득과 캐시 획득을 한번에 하도록 한다.

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

9. 데이터 크기를 최소화 한다
구조화된 데이터 보다 압축된 데이터를 사용하는 것이 좋다
다만 데이터 분석이 까다로워진다.

10. 필드 수가 너무 많지 않도록 한다
2만개 이상의 필드를 가지면 find()에 걸리는 시간은 5초 이상...
데이터 크기 뿐만이 아닌 BSON Parse에 걸리는 시간도 고려한
다.

11. 갱신 빈도를 최대한 줄인다
마스터 정보는 서버에서 캐시 한다.
유저 조작을 모아서 한번에 처리한다(5초에 1번)

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

13. 앞에 만들었던 INDEX를 이용하
고 있다.
실행 계획의 예측 실행 시간이
빨라졌다!!

14. 성능 저하를 일으키는 동작
 데이터 접근
- 물리 메모리가 아닌 가상 메모리를 사용하면 느려진다.
 인덱스
락
- 락의 단위는 데이터베이스, 읽기는 복수 접근 가능
 져널
- 안정성은 높아지지만 디스크 접근이 발생하므로 처리 성능
이 감소
 문서 재배치

15. 처리 성능을 올리는 방법
1. 서버의 물리 메모리를 많이 준비한다.
2. 빠른 속도를 가진 디스크를 사용한다.
3. 인덱스를 잘 건다.
4. 락이 걸리지 않도록 문서 설계와 질의문을 만든다.
5. 문서에 필요한 필드를 처음부터 만들어 놓는다.
- 문서 재배치가 일어나지 않도록 기본 값을 미리 만든다.
6. 저널의 쓰기 횟수를 줄인다.
- --journalCommitInterval 옵션을 지정하여 쓰기 간격을 넓
게 한다. (또는 --nojournal 옵션으로 사용 안한다)