[MongoDB] 애플리케이션 설계

9.1 스키마 설계 고려 사항

제약 사항

• 도큐먼트 최대 크기 16Mbyte
• 디스크에서 전체 도큐먼트를 읽고 쓴다
• 갱신은 전체 도큐먼트를 다시 쓰며, 원자성 갱신은 도큐먼트 단위로 실행

쿼리 및 쓰기의 접근 패턴

• 쿼리 수를 최소화하고, 함께 쿼리되는 데이터가 동일한 도큐먼트에 저장되도록 설계
• 쿼리에 사용되지 않는 데이터는 다른 컬렉션에 넣어야 한다.
• 자주 사용하지 않는 데이터도 다른 컬렉션으로 넣는다.

관계 유형

• 요구 사항 측면과 도큐먼트 간 관계 측면 고려하여 도큐먼트를 내장하거나 참조할 방법을 결정
• 쿼리하지 않고 도큐먼트를 참조하는 방법을 파악해야 하며,
• 관계가 변경될 때 갱신되는 도큐먼트 개수를 알아야함.

카디널리티

• 일대일, 일대다, 다대다 인지 고려
• 도큐먼트 간에 데이터를 비정규화해야 할지, 도큐먼트를 내장할지, 참조할지 결정하는데 도움

9.1.1 스키마 설계 패턴

다형성 패턴 Polymorphic Pattern

• 컬렉션 내 모든 도큐먼트가 유사하지만 동일하지 않은 구조를 가질 때 적합
• 공통 쿼리를 지원하는 도큐먼트에서 공통 필드를 식별하는 것이 포함

속성 패턴 Attribute Pattern

• 정렬하거나 쿼리하려는 도큐먼트에 필드의 서브셋이 있는 경우
• 정렬하려는 필드가 도큐먼트의 서브셋에만 존재하는 경우
• 두 조건이 모두 해당하는 경우에 적합

버킷 패턴 Bucket Pattern

• 데이터가 일정 기간 동안 스트림으로 유입되는 시계열 데이터에 적합

이상치 패턴 Outlier Pattern

• 도큐먼트의 쿼리가 애플리케이션의 정상적인 패턴을 벗어날 때 사용
• 인기도가 중요한 상황을 위해 설계된 고급 스키마 패턴

계산된 패턴 Computed Pattern

• 데이터를 자주 계산해야 할 때나 데이터 접근 패턴이 읽기 집약적일 때 사용
• 주요 도쿠먼트가 주기적으로 갱신되는 백그라운드에서 계산을 수행하도록 권장

서브셋 패턴 Subset Pattern

• 장비의 램 용량을 초과하는 작업 셋이 있을 때 사용
• 사용하지 않는 정보를 많이 포함하는 대용량 도큐먼트 때문에 발생
• 서브셋 패턴은 자주 사용하는 데이터와 자주 사용하지 않는 데이터를 두 개의 개별 컬렉션으로 분할

확장된 참조 패턴 Extended Reference Pattern

• 각각 고유한 컬렉션이 있는 여러 논리 엔티티가 있고, 특정 기능을 위해 엔티티들을 모을 때 사용
• 데이터를 중복시키는 대신 정보를 조합하는데 필요한 쿼리 수를 줄인다
• 자주 사용하는 정보로 서브 도큐먼트의 배열 생성, 추가적인 정보는 실제 도큐먼트를 참조하는 방식

근사 패턴 Approximation Pattern

• 리소스가 많이 드는 계산이 필요하지만 높은 정확도가 반드시 필요하지 않은 상황에 유용
• 이미지나 게시글의 추천 수, 페이지 조회 수

트리 패턴 Tree Pattern

• 쿼리가 많고 구조적으로 주로 계층적인 데이터가 있을 때 적용
• 함께 쿼리되는 데이터를 한데 저장하는 방식

사전 할당 패턴 Preallocation Pattern

• MMAP 스토리지 엔진과 함께 사용
• 빈 구조를 사전 할당
• 예약 정보를 매일 관리하는 시스템에서 예약 가능 여부와 현재 예약상태를 추적하는데 적용

도큐먼트 버전 관리 패턴 Document Versioning Pattern

• 도큐먼트의 이전 버전을 유지하는 메커니즘
• 각 도큐먼트에 부가 필드를 추가, 도큐먼트의 모든 수정 사항을 포함하는 추가 컬렉션 필요
• 각 도큐먼트의 개정은 횟수 제한, 버전 관리가 필요한 도큐먼트가 적음
• 쿼리는 각 도큐먼트의 현재 버전에서 먼저 수행

9.2 정규화 vs. 비정규화

• 정규화는 컬렉션 간의 참조를 이용해 데이터를 여러 컬렉션으로 나누는 작업
  • 데이터는 하나의 컬렉션에 들어 있고, 데이터를 변경하려면 한 도큐먼트만 갱신
  • 쓰기가 빠름
• 비정규화는 모든 데이터를 하나의 도큐먼트에 내장
  • 여러 도큐먼트가 최종 데이터 사본에 대한 참조.
  • 정보가 변경되면 여러 도큐먼트가 갱신돼야 하지만, 하나의 쿼리로 관련된 모든 데이터를 가져올 수 있음
  • 읽기가 빠름

9.2.1 데이터 표현 예제

확장 참조 패턴

//Users
{
  _id: ObjectId("user1"),
  name: "John Doe",
  email: "john.doe@example.com"
}
//Posts
{
  _id: ObjectId("post1"),
  title: "Introduction to MongoDB",
  content: "MongoDB is a flexible and scalable NoSQL database.",
  author: {		//내장
    userId: ObjectId("user1"),		//참조
    name: "John Doe"
  }
}

내장 방식이 좋은 경우	참조 방식이 좋은 경우
작은 서브 도큐먼트	큰 서브 도큐먼트
주기적으로 변하지 않는 데이터	자주 변하는 데이터
결과적인 일관성이 허용될 때	즉각적인 일관성이 필요할 때
증가량이 적은 도큐먼트	증가량이 많은 도큐먼트
두 번째 쿼리를 수행하는 데 자주 필요한 데이터	결과에서 자주 제외되는 데이터
빠른 읽기	빠른 쓰기

9.2.2 카디널리티

• '다수'라는 개념을 '많음'과 '적음'이라는 범주로 나눠 개념상 이해
• '적음' 관계는 내장이 더 적합, '많음' 관계는 참조가 더 적합

9.3 데이터 조작을 위한 최적화

9.3.1 오래된 데이터 제거

• 제한 컬렉션 사용
• TTL 컬렉션 사용
• 여러 개의 컬렉션 사용

9.4 데이터베이스와 컬렉션 구상

• 스키마가 유사한 도큐먼트는 같은 컬렉션에 보관
• 컬렉션에서는 락과 저장을 중요하게 고려
• 데이터베이스 내 모든 항목이 품질, 비슷한 접근 패턴, 비슷한 트래픽 수준을 갖는 것이 좋음

9.5 일관성 관리

• 서버는 각 연결에 대한 요청 큐를 보관
• 각 연결은 데이터베이스에 대해 일관적인 관점을 가지며 자신의 쓰기를 항상 읽을 수 있음

9.6 스키마 마이그레이션

• 스키마를 애플리케이션의 요구에 맞춰 변화시키는 방법 → 코드를 복잡하게 만든다
• 각 도큐먼트에 "version" 필드를 추가 → 구 버전에 대한 지원이 필요
• 스키마가 변경될 때 모든 데이터를 마이그레이션 → 모든 도큐먼트가 성공적으로 갱신됐는지 확인

9.7 스키마 관리

• 유효성 검사는 기존 도큐먼트가 수정되기 전에는 확인하지 않으며 컬렉션별로 구성

9.8 몽고 DB를 사용하지 않는 경우

• 다양한 유형의 데이터를 여러 차원에 걸쳐 조인하는 작업
• 몽고 DB를 지원하지 않는 도구를 사용할 때