문서 메뉴

문서 홈애플리케이션 개발MongoDB 매뉴얼

데이터 모델링

이 페이지의 내용

  • 사용 사례
  • 스키마 디자인: 관계형 데이터베이스와 문서 데이터베이스의 차이점
  • 스키마 계획하기
  • 관련 데이터 연결
  • 포함된 데이터
  • 참조
  • 추가 데이터 모델링 고려 사항
  • 데이터 중복 및 일관성
  • 인덱싱
  • 하드웨어 제약 조건
  • 단일 문서 원자성
  • 자세히 알아보기

데이터 모델링은 데이터베이스 내의 조직과 관련 엔터티 간의 링크를 나타냅니다. MongoDB의 데이터에는 유연한 스키마 모델이 있으며, 이는 다음을 의미합니다.

  • 단일 컬렉션 내의문서들은 동일한 필드 설정을 가질 필요는 없습니다.

  • 필드의 데이터 유형은 컬렉션내의 문서마다 다를 수 있습니다.

일반적으로 한 컬렉션의 문서들은 비슷한 구조를 공유합니다. 데이터 모델의 일관성을 보장하기 위해 스키마 유효성 검사 규칙을 만들 수 있습니다.

유연한 데이터 모델을 사용하면 애플리케이션의 요구 사항에 맞게 데이터를 구성할 수 있습니다. MongoDB는 문서 데이터베이스이므로 객체 및 배열 필드에 관련 데이터를 포함할 수 있습니다.

유연한 스키마는 다음 시나리오에서 유용합니다.

  • 회사에서는 각 직원이 어느 부서에서 근무하는지 추적합니다. employee 컬렉션 내에 부서 정보를 포함하여 단일 쿼리로 관련 정보를 반환할 수 있습니다.

  • 전자상거래 애플리케이션에서는 제품을 표시할 때 최신 리뷰 5개를 표시합니다. 최신 리뷰는 제품 데이터와 동일한 컬렉션에 저장하고, 이전 리뷰는 자주 액세스하지 않으므로 별도의 컬렉션에 저장할 수 있습니다.

  • 의류 매장에서는 제품 카탈로그를 위한 단일 페이지 애플리케이션을 만들어야 합니다. 제품마다 속성이 다르므로 서로 다른 문서 필드를 사용합니다. 그러나 모든 제품을 동일한 컬렉션에 저장할 수 있습니다.

MongoDB와 같은 문서 데이터베이스의 스키마를 설계할 때는 관계형 데이터베이스와의 몇 가지 중요한 차이점을 고려해야 합니다.

관계형 데이터베이스 동작
문서 데이터베이스 동작
데이터를 삽입하기 전에 테이블의 스키마를 결정해야 합니다.
스키마는 애플리케이션의 요구 사항이 변경됨에 따라 시간이 지남에 따라 변경될 수 있습니다.
애플리케이션에 필요한 데이터를 반환하려면 서로 다른 여러 테이블의 데이터를 취합해야 하는 경우가 종종 있습니다.
유연한 데이터 모델을 사용하면 애플리케이션이 데이터를 반환하는 방식에 맞게 데이터를 저장하고 조인을 피할 수 있습니다. 여러 컬렉션 사이의 조인을 피하면 성능이 향상되고 배포 작업의 워크로드가 줄어듭니다.

데이터 모델이 논리적 구조를 갖추고 최적의 성능을 달성하도록 하려면 데이터베이스를 프로덕션 규모로 사용하기 전에 스키마를 계획하십시오. 데이터 모델을 결정하려면 다음의 스키마 설계 프로세스를 사용하십시오.

  1. 애플리케이션의 워크로드를 파악합니다.

  2. 컬렉션에 있는 객체 간의 관계를 매핑합니다.

  3. 디자인 패턴을 적용합니다.

MongoDB에서 데이터 모델을 설계할 때는 문서의 구조와 애플리케이션에서 관련 엔티티의 데이터를 사용하는 방식을 고려하십시오.

관련 데이터를 연결하려면 다음 중 하나를 실시할 수 있습니다.

  • 하나의 문서에 관련 데이터를 삽입합니다.

  • 관련 데이터를 별도의 컬렉션에 저장하고 참조를 사용하여 데이터에 액세스합니다.

포함된 문서는 관련 데이터를 단일 문서 구조에 저장합니다. 문서에는 배열과 관련 데이터가 있는 하위 문서가 포함될 수 있습니다. 이러한 비정규화된 데이터 모델을 통해 애플리케이션은 한 번의 데이터베이스 작업으로 관련 데이터를 검색할 수 있습니다.

모든 관련 정보가 포함된 필드가 내장된 데이터 모델입니다.

MongoDB의 많은 사용 사례에서 비정규화된 데이터 모델이 최적입니다.

문서 임베딩의 장단점에 대해 자세히 알아보려면 포함된 데이터 모델을 참조하세요.

참조는 한 문서에서 다른 문서로 연결되는 링크(참조라고 함)를 포함하여 데이터 간의 관계를 저장합니다. 예를 들어 orders 컬렉션의 customerId 필드는 customers 컬렉션의 문서에 대한 참조를 나타냅니다.

애플리케이션은 이러한 참고를 확인하여 관련 데이터에 액세스할 수 있습니다. 대체로 정규화된 데이터 모델입니다.

링크 문서에 대한 참조를 사용하여 데이터 모델을 연결합니다. ``contact`` 문서와 ``access`` 문서 모두 ``user`` 문서에 대한 참조를 포함하고 있습니다.

참조 사용의 장단점에 대해 자세히 알아보려면 참조를 참조하세요.

다음 요소는 데이터 모델을 계획하는 방식에 영향을 줄 수 있습니다.

단일 문서에 관련 데이터를 포함할 경우, 두 컬렉션 간에 데이터가 중복될 수 있습니다. 데이터를 복제하면 모델에서 엔티티를 논리적으로 분리하면서 애플리케이션에서 여러 엔티티에 대한 관련 정보를 한 번의 쿼리로 쿼리할 수 있습니다.

예를 들어, 한 products 컬렉션은 제품 문서에 가장 최근 리뷰 5개를 저장합니다. 해당 리뷰는 모든 제품 리뷰가 포함된 reviews 컬렉션에도 저장됩니다. 새 리뷰가 작성되면 다음과 같은 쓰기가 발생합니다.

  • reviews 컬렉션에 리뷰가 삽입됩니다.

  • products 컬렉션의 최근 리뷰 배열이 $pop$push으로 업데이트됩니다.

중복된 데이터를 자주 업데이트하지 않는 경우 두 컬렉션의 일관성을 유지하기 위해 최소한의 추가 작업만 하면 됩니다. 그러나 중복된 데이터가 자주 업데이트되는 경우에는 참조 를 사용하여 관련 데이터를 연결하는 것이 더 나은 방법일 수 있습니다.

데이터를 복제하기 전에 다음 요소를 고려하세요.

  • 중복된 데이터를 업데이트해야 하는 빈도.

  • 데이터가 중복되면 읽기 성능에 이점이 생깁니다.

자세히 알아보려면 중복 데이터 처리를 참조하세요.

애플리케이션에서 자주 실행되는 쿼리의 성능을 개선하려면 자주 쿼리되는 필드에 인덱스를 생성합니다. 애플리케이션이 성장하면 배포서버의 인덱스 사용을 모니터링하여 인덱스가 관련 쿼리를 계속 지원하는지 확인합니다.

스키마를 설계하는 경우 배포 하드웨어, 특히 사용 가능한 RAM의 양을 고려합니다. 문서가 클수록 RAM을 더 많이 사용하므로 응용 프로그램이 디스크에서 읽고 성능이 저하될 수 있습니다. 가능하다면 쿼리에서 관련 필드만 반환되도록 스키마를 설계하십시오. 이렇게 하면 애플리케이션의 작업 집합이 불필요하게 커지는 것을 방지할 수 있습니다.

MongoDB에서 쓰기 작업은 단일 문서 내에 포함된 여러 문서를 수정하는 경우에도 단일 문서 수준에서 원자적으로 이루어집니다. 즉, 업데이트 작업이 여러 하위 문서에 영향을 미치는 경우 해당 하위 문서가 모두 업데이트되거나 작업이 완전히 실패하여 업데이트가 발생하지 않습니다.

데이터가 포함된 비정규화된 데이터 모델은 여러 문서와 컬렉션을 정규화하는 대신 모든 관련 데이터를 단일 문서에 결합합니다. 이 데이터 모델은 작업이 여러 문서에 영향을 주는 정규화된 모델과 달리 원자성 작업을 허용합니다.

자세한 내용은 원자성을 참조하십시오.

  • MongoDB University의 M320 데이터 모델링 과정에서 문서를 구조화하고 스키마를 정의하는 방법을 알아보세요.

  • MongoDB를 사용한 데이터 모델링에 대한 자세한 내용은 MongoDB 애플리케이션 현대화 가이드 를 다운로드하세요.

    다음과 같은 리소스가 다운로드에 포함됩니다.

    • MongoDB를 사용한 데이터 모델링 방법론에 대한 프레젠테이션

    • RDBMS 데이터 모델에서 MongoDB로 마이그레이션하기 위한 모범 사례와 고려 사항을 다룬 백서

    • RDBMS에 해당하는 MongoDB 스키마 참조

    • 애플리케이션 현대화 스코어카드

← 트랜잭션 및 작업