🐒 MongoDB

• NoSQL DB 중 Document DB
  • Document DB : Key/Value DB의 확장된 형태(기본적으로는  Key/Value DB)
  • 저장되는 Value의 데이터 타입 = Document 타입
  • Document : XML,JSON,YAML과 같이 구조화된 데이터 타입 (복잡한 계층 구조를 표현할 수 있음)

NoSQL 데이터 모델링

NoSQL 데이터 모델링을 위해선 아래 2가지 사항을 잘 기억해야 함

1) 객체 모델 지향 → 쿼리 결과 지향 모델링

RDBMS : 도메인 모델 → [테이블 → 쿼리]

1. 저장하고자 하는 도메인 모델 분석
2. 개체간의 관계 식별
3. 테이블 추출
4. 테이블을 이용한 쿼리 구현, 결과 생성

NoSQL : 도메인 모델 → [쿼리 → 테이블]

1. 저장하고자 하는 도메인 모델 분석
2. 필요한 쿼리 결과 정의
3. 해당 쿼리 결과를 얻기 위한 데이터 모델 디자인
4. NoSQL은 RDMS와는 달리 복잡한 쿼리 기능이 없기 때문에 필요한 쿼리 결과를 먼저 설정한 후 그에 맞게 데이터 모델을 디자인해야 한다.

❗️NoSQL DB 모델링을 하는 경우,
테이블을 구상하기 전 어떤 쿼리 결과를 얻을지를 먼저 정의해야 한다는 것이 중요하다.

2) 정규화(Normalization) → 비정규화(Denormalization)

RDBMS : 데이터의 일관성, 도메인 모델과의 일치성 추구 → 데이터 모델 정규화

(특히 같은 데이터가 두 개 이상의 테이블에 중복되게 저장하는 것 제거)

NoSQL

• 쿼리의 효율성을 위해 데이터를 정규화하지 않음
• 의도적으로 중복된 데이터를 저장하는 등 비정규화된 데이터 모델 설계 방식 지향

Document DB 모델링

1) 임베디드 형식(Embedded)

항목	내용
설명	임베디드 방식은 강의정보처럼 동일한 데이터를 각 학생 도큐먼트에 저장하여 구조를 단순화하는 반정 규화 모델임 - 조회 성능이 좋고, 도큐먼트에 포함된 관련 데이터를 모두 업데이트할 수 있음 - 데이터 관리가 직관적이고 쿼리가 단순함
문제점	- 데이터 중복은 도큐먼트 구조를 단순화하고 조회 성능을 향상하나 데이터 불일치가 발생할 수 있음 - 도큐먼트에 포함하는 데이터가 증가할수록 도큐먼트의 크기도 증가하여 디스크 I/O 시 성능 저하 발생 및 도큐먼트의 최대 크기를 초과 시 저장이 불가능할 수 있음 - 데이터의 관계가 복잡하거나 계층 구조를 갖는 업무는 관리가 어려움
권장 업무	- 조회 성능이 중요하고 데이터 중복에 따른 데이터 불일치 문제가 발생하지 않는 업무 - 업데이트가 과도하게 발생하지 않는 업무

2) 레퍼런스 형식(Reference)

항목	내용
설명	- 데이터가 중복되지 않도록 업무 성격별로 컬렉션을 분리 후 참조하므로 데이터 불일치가 발생하지 않는 정규화 모델임 - 적절한 업무 단위의 컬렉션으로 데이터가 분리되어 임베디드 방식 대비 도큐먼트의 크기가 작음 - 업무 요건 추가 및 변경으로 인한 도큐먼트 구조에 미치는 영향이 적음
문제점	- 참조가 많은 도큐먼트 또는 대규모 도큐먼트를 조회하는 경우 애플리케이션에서 2차 쿼리로 인한 처리량 증가로 조회 성능이 저하될 수 있음 - 데이터 중복에 의한 데이터 일관성 문제는 해소되나 참조 정보를 정확하게 관리하지 않는 경우 참조 정보 소실에 의한 데이터 정합성 문제가 발생할 수 있음
권장 업무	- 조회 성능보다는 데이터 무결성이 중요한 업무 - 임베디드 방식으로 사용 시 디스크 I/O 성능에 문제가 예상되는 업무 - 데이터의 관계가 복잡하거나 계층 구조를 갖는 업무

• 레퍼런스 형식 - 세부

항목	내용
자식 참조	- 부모 도큐먼트에서 관계를 갖는 자식 도큐먼트의 식별자를 참조키로 저장하는 방식임 - 부모 도큐먼트와 관계를 갖는 자식 도큐먼트를 쉽게 찾을 수 있으며 참조 정보가 부모 도큐먼트에만 존재하므로 관리가 편리함 - 부모 도큐먼트에 업데이트가 집중되어 성능 문제가 발생할 수 있으며 자식 도큐먼트가 많은 경우 도큐먼트의 최대 크기를 초과할 수 있음 - 부모 도큐먼트에 발생하는 부하 및 크기 증가를 고려하여 자식 도큐먼트가 적게 생성되는 업무에 적합함
부모 참조	- 자식 도큐먼트에서 관계를 갖는 부모 도큐먼트의 식별자를 참조키로 저장하는 방식임 - 자식 도큐먼트에서 부모 도큐먼트를 쉽게 찾을 수 있으며 자식 도큐먼트의 추가 및 삭제로 인한 부모 도큐먼트의 업데이트가 없음 - 부모 도큐먼트와 관계를 갖는 모든 자식 도큐먼트 조회 시 소요시간이 증가할 수 있음 - 이력 또는 로그 데이터와 같이 자식 도큐먼트가 많이 생성되는 업무에 적합함
상호 참조	- 관계를 갖는 부모 도큐먼트와 자식 도큐먼트가 각각 서로의 식별자를 참조키로 저장하는 방식임 - 부모 도큐먼트에서 자식 도큐먼트를 찾거나 자식 도큐먼트에서 부모 도큐먼트를 쉽게 찾을 수 있으나 다른 방식에 비해 참조 정보 관리가 어려움 - 부모 도큐먼트와 자식 도큐먼트 모두 업데이트가 과도하게 발생할 수 있으며 참조 정보 관리 부주의 시 데이터 정합성 문제가 쉽게 발생할 수 있음 - 데이터 변경이 적고 부모 도큐먼트와 자식 도큐먼트가 서로를 빈번하게 참조하는 업무에 적합함