13. MongoDB 구조 간단 review - 2
mongod
- 데이터를 저장, 관리 (복제 정책 적용 가능)
mongos
- client의 요청 받아 환경 설정 서버의 partitioning
정보를 참고해 적절한 데이터 서버로 요청을 포워딩
Config Server
- sharding에 대한 환경 설정 서버
- partitioning에 대한 정보를 관리
14. 기억할 것!
mongod
- 데이터를 저장
mongos
- client와 mongod 서버 간 라우터 역할
Config Server
- 메타 정보 관리
16. MongoDB 이럴 때 쓰지 마세요!
• 고객이 Oracle이랑 비교할 때(RDBMS와는 태생이 다름)
• 무료라는 이야기 듣고 고객이 들이댈 때
• 재정적으로 여유가 있을 때
• License에 대한 이해가 불충분한 경우
17. MongoDB 이럴 때 쓰세요!
• 유연함과 확장이 필요할 때
• log data, SNS data 등을 적재 및 활용
• 다양한 open source와 연계할 때 (ex. Hadoop, R, Spark)
• 개발 주기가 짧거나 prototype 형 모델을 제시할 때
• 고객이 open source에 대한 이해가 충분할 때
22. Wired Tiger Engine
• 3.0 부터 새롭게 도입
• mongodb 사용시 엔진 선택 가능
(--storageEngine=“wiredTiger”)
• 디폴트 설정시에는 MMAPv1 엔진 사용
• WiredTiger는 64bit & mongodb 3.0 일 때만 사용가능
28. Monitoring
• ~2.4 : mongostat 등의 내부 함수 주로 이용
: 개발자 편의 위주의 tool 존재 (robomongo 등)
• 2.6 : third party tool 의 발전 1
: Enterprise ver. 내에 존재하는 MMS 등장
• 3.0 ~ : third party tool 의 발전 2
: Cloud Manager의 등장
29. Monitoring
• Cloud Manager를 쓴다면 체계적인 관리가 가능하지만,
• 보통 MongoDB 도입 시점부터 높은 투자 성향을 보이지 않으므로,
• 기본적인 third party tool or 내부적인 모니터링 스크립트
구현이 합리적인 선택
• Release가 업데이트 될수록 Enterprise 버전은
“보안”과 “모니터링”을 차별화 품목으로 가져갈 확률이 높음
31. Best Practice (1)
• ~ 2.2 release : log, sns data
(신뢰성 ↓, 발전가능성 ↑)
• 2.4, 2.6 : meta, key data
(신뢰성 ↑, 발전가능성 ↑)
• 3.0 ~ : finance, trading
(신뢰성 ↑, 발전가능성 ↑)
32. Best Practice (2)
• ~ 2.6 release
: 활용 목적보다 활용 기업 또는 서비스에 대한 관심
: 제품에 대한 신뢰도가 엇갈리는 시기
: 이에 따른 reference check가 활발하던 시기
• 3.0 ~
: 충분히 활용 reference가 많아짐에 따라 점차
활용 용도, 활용 방식에 대한 관심 증가
34. What’s new in 3.2
• Data at rest encryption
• Document Validation
• Dynamic lookups in the aggregation framework
• Default Engine changing ( MMAPv1 → WiredTiger)