MongoDB 는 Document DB - JSON 기반의 Document 기반 데이터 관리
빅데이터 초리 속도 향상을 위해 JOIN을 지원하지 않음
- Long, Object, String, 32bit Integer, 64bit Integer, Object Id, javascript, Array, Boolean, Date, Timestamp, Symbol, ...
- JSON { 'id' : '01', 'language' : 'java', ... , key : value}
Database > Collections > Extents > Data Records > Documents
RDBMS
확실한 규격 - 포맷이 있어서 데이터 간의 관계를 표현함
| 고객 | 고객거주아파트 | 아파트 |
|---|---|---|
| 고객번호 pk | 고객번호 fk | 아파트 동번호 pk |
| 이름 | 아파트번호 fk | 세대수 |
| 주소 | 관리주체 | |
| 전화번호 |
NoSQL
Document - column의 개념이 없음 - document 하나가 하나의 Row(Recode)
| 고객번호 | 이름 | 주소 |
|---|---|---|
| 홍길동 | 서울시 구로 | |
| 아파트 동번호 | 세대 수 | |
| 302동 | 1123세대 |
Pros
- Schema-less
- 다양한 형태의 데이터 저장 가능 > 데이터 모델의 유연한 변화 가능
- R / W 성능 우수
- Scaled Out 구조
- 대용량 데이터 저장 가능
- 장비 확장이 간단함
- 사용 방법이 쉽고, 개발이 편리함
- 데이터를 신속하게 처리 가능
- 시스템 확장 및 장애 대응 가능
Cons
- 데이터 업데이트 중 장애 발생 시, 데이터 손실 가능
- 많은 인덱스 사용 시, 충분한 메모리 확보가 필요
- 데이터 공간 소모가 RDBMS에 비해 많음 - 비효율적인 key 중복 입력이 존재
- 복잡한
JOIN사용 시 성능 제약이 존재 - Transactions 지원이 RDBMS 대비 미약
- 제공되는 MapReduce 작업이 Hadoop에 비해 성능이 떨어짐
- 분산 시스템이기 때문에 데이터 유실 가능성 존재
- Create
- Read
- Update
- Delete
- 다수 인덱스 설정 가능
- 복합 인덱스 지원
- 빠른 검색 지원
- 도큐먼트 저장 데이터와 중복 저장 문제
- 메모리가 부족한 시스템에서는 검색 속도 저하 문제
- Master - Slave 구조 구성
- 데이터 복사본을 Slave에 배치
- Master 장애에 따른 데이터 손실 없이 Slave 데이터 사용 가능
- Master 장애 발생 시, Slave에서 Master 선출 가능 - 중단 없는 서비스 가능
- 복제 시스템 사이에 마스터 장애 발생을 능동적으로 발생하고 스스로 처리함 - 운영자, 개발자의 개입 없이 가능
- 데이터 손실을 최소화하기 위한 저널링 지원 - MongoDB의 데이터 변화에 다른 모든 연산에 대한 로그 적재
- 대용량 데이터 저장 방법
- 소프트웨어 적으로 데이터베이스를 분산시켜 처리
- 방식
- 디비 저장 테이블을 테이블 단위로 분리
- 디비 저장 테이블 자체를 분할
- 전통적 분할 3계층 구조 지원
- 응용 계층 - 중개자를 통해 모든 데이터 입출력 처리의 제약사항 존재
- 중개자 계층, 데이터 계층 (실 저장 공간 - Shards)
- 응용 계층은 추상화된 한 개의 데이터베이스가 존재하는 것처럼 운용
- 전체적으로 데이터가 얼마나 많은 서버에 분산되어있는지 알 필요가 없음
-
대용량 데이터를 안전하고 빠르게 처리하는 방법
- 데이터 분산하여 연산하고 다시 합치는 기술
- 맵과 리듀스 단계로 나누어 처리하며, 사용자 임의 코딩이 가능
-
한대 이상의 하드웨어를 활용한 분산 프로그래밍 모델
- 분산을 통해 분할된 조각으로 처리한 다음, 다시 모아서 훨씬 짧은 시간에 계산을 완료
-
대용량 파일에 대한 로그 분석, 색인 구축 검색 등에 활용
-
일괄 처리 방식으로 전체 데이터셋을 분석할 필요가 있는 문제에 적