MongoDB 데이터 모델링 모범 사례

MongoDB의 유연한 데이터 모델을 사용하면 데이터 일관성 과 무결성을 보장하면서 성능과 적응성 간의 전략적인 균형을 맞출 수 있습니다. 스키마 계획 에 대한 일반적인 지침 외에도 다음 권장사항 고려 하여 데이터 모델 최적화 하고 애플리케이션 사용 사례 에 가장 적합한 스키마 설계 패턴 결정 합니다 .

스키마를 조기에 계획하고 반복하기

스키마 를 계획하고 설계하는 것은 애플리케이션 개발 프로세스 초기에 수행하는 것이 가장 좋습니다. 올바른 데이터 모델링 방법으로 애플리케이션 시작하면 애플리케이션 성장에 따른 성능 문제를 방지하는 데 도움이 됩니다. 데이터 모델링 권장사항 조기에 적절하게 따르면 더 나은 성능을 달성하고 향후 애플리케이션 더 쉽게 확장하다 할 수 있습니다.

참고

애플리케이션 과 최적화의 중요성에 따라 최적화에 시간을 들이기 전에 기본 기능을 다루는 간단하고 작동하는 데이터 모델 설정하는 데 우선순위를 둘 수 있습니다.

데이터 모델 수정

애플리케이션 의 요구 사항이 변경되면 스키마 를 반복적으로 설계하고 스키마 해야 합니다. MongoDB는 다운타임 없이 스키마 를 원활하게 수정할 수 있는 방법을 제공합니다. 그러나 프로덕션에서 사용되는 대규모 스키마를 수정하는 것은 여전히 어려울 수 있습니다.

다음 예를 고려하십시오.

코스 및 해당 강의에 대한 정보를 저장하는 온라인 사용자 학습 플랫폼의 백엔드 구축해야 합니다. 처음에는 플랫폼이 각 코스에 대해 다음 기본 정보만 저장 하면 됩니다.

코스 제목
강사
설명
각 코스 문서 내에 하위 문서의 배열 로 포함된 수업입니다. 현재 각 강의 하위 문서에는 제목, 설명 및 프레젠테이션 슬라이드만 포함되어 있습니다.

플랫폼이 발전함에 따라 각 과정에는 동영상, 퀴즈, 과제, 외부 리소스 링크와 같은 추가 학습 및 테스트 형식이 필요합니다. 각 코스 문서 에 이 새로운 데이터를 모두 포함하면 데이터 모델 너무 복잡해질 수 있습니다.

대신 별도의 lessons 컬렉션 만드는 것이 좋습니다. 이렇게 하면 course lessons 참조 ID를 사용하여 및 컬렉션을 연결할 수 있습니다. 참고 자료를 사용하면 각 강의에 다양한 콘텐츠 유형을 포함할 수 있고 향후 형식 변경에 더욱 유연하게 대처할 수 있습니다.

Duplicate Data

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

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

데이터가 중복되면 읽기 성능에 이점이 생깁니다. 데이터를 복제하면 여러 컬렉션에서 조인(join)을 수행할 필요가 없으므로 애플리케이션 성능을 향상할 수 있습니다.
중복된 데이터를 업데이트해야 하는 빈도입니다. 자주 사용하지 않는 업데이트를 처리하다 데 필요한 예비 로직은 읽기 작업에서 조인(조인)을 수행하는 것보다 비용이 적게 듭니다. 그러나 중복 데이터를 자주 업데이트하면 과도한 워크로드와 성능 문제가 발생할 수 있습니다.

다음 표에는 스키마 에 존재할 수 있는 다양한 유형의 중복 데이터가 나열되어 있습니다.

중복 데이터 유형	설명	예시
불변	절대 변경되지 않는 데이터입니다. 변경할 수 없는 데이터는 데이터 복제에 적합한 후보입니다.	사용자 계정이 생성된 날짜입니다.
임시	시간이 지남에 따라 변경될 수 있지만 데이터의 과거 가치를 보존하는 것이 중요한 데이터입니다.	주문 당시 고객의 주소 . 고객이 새 주소 로 이사하는 경우 이전 주문이 배송된 곳에 기록된 주소에는 영향을 미치지 않습니다.
부실 상태에 민감	모든 데이터의 일관적인 을 보장하기 위해 자주 업데이트해야 하는 데이터입니다. 애플리케이션은 트랜잭션 또는 트리거를 사용하여 모든 항목을 업데이트 할 수 있습니다.	특정 제품의 주식 품목 수로, 고객이 제품을 주문할 때마다 업데이트해야 합니다.
부실 상태에 민감하지 않음	더 오랜 기간 동안 보존될 수 있는 데이터입니다. 애플리케이션은 배경 작업 사용하여 허용 가능한 비활성 상태와 업데이트 비용 기준으로 데이터의 모든 발생을 주기적으로 업데이트 수 있습니다.	고객을 위한 추천 제품 목록으로, 시스템에 새 제품이 추가될 때마다 다시 계산할 필요가 없습니다.

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

관련 데이터를 복제하는 것이 데이터 모델 최적화하는 데 어떻게 도움이 되는지에 대한 예시는 중복 데이터 처리를 참조하세요.

데이터 일관성 시행

스키마 에서 데이터를 중복하는 경우 여러 컬렉션에서 데이터를 일관적인 유지하는 방법을 결정해야 합니다. 예시 를 들어, 전자상거래 플랫폼은 제품 주식 의 실시간 상태를 제공하기 위해 지속적으로 최신 데이터를 필요로 합니다. 반면에 소셜 미디어 분석 과 같이 장기적인 전략 결정을 위해 데이터를 처리하다 애플리케이션은 약간 오래된 데이터 읽기를 허용할 수 있습니다.

다음 방법 중 하나를 사용하여 애플리케이션 에서 데이터 일관성 시행하다 할 수 있습니다.

각 데이터 일관성 시행 방법, 사용 사례 및 성능 장단점에 대해 자세히 학습 보려면 데이터 일관성을 참조하세요.

유효성 검사 규칙으로 스키마 적용

스키마 유효성 검사 요구 사항은 사용자가 애플리케이션 사용하는 방식에 따라 달라집니다. MongoDB의 유연한 스키마 사용하면 특히 개발 초기 단계에서 데이터 모델 쉽게 발전시킬 수 있습니다. 그러나 데이터 모델 안정화되면 스키마 유효성 검사 데이터가 의도한 대로 표시되는지 확인하는 데 유용한 방법이 될 수 있습니다. 스키마 유효성 검사 데이터 구성 방법을 잘 알고 있는 기존 애플리케이션 에 가장 유용합니다.

참고

스키마 유효성 검사 규칙도 유연하므로 애플리케이션 에서 요구하지 않는 한 문서 의 모든 필드 포괄할 필요가 없습니다.

다음 시나리오에서 스키마 유효성 검사를 사용할 수 있습니다:

events 컬렉션 의 경우 start_date 필드 문자열이 아닌 날짜로만 저장되어 연결 애플리케이션이 예기치 않은 유형을 사용하지 않도록 합니다.
store 컬렉션 의 경우 accepted_credit_cards 필드 ["Visa", "MasterCard", "American Express"]와 같이 저장 에서 허용하는 크레딧 카드 목록에 속하는지 확인합니다. 이 유효성 검사 사용자가 지원되지 않는 크레딧 카드 금액을 입력하는 것을 방지합니다.
학생 컬렉션 의 경우 gpa 필드 항상 양수 부동 점 숫자인지 확인합니다. 이 유효성 검사 데이터 입력 중 오류를 방지합니다.

자세한 학습 은 스키마 유효성 검사 참조하세요.

자주 쿼리되는 필드 인덱스

데이터 모델 설계할 때는 데이터에 액세스 하고 저장 방법을 고려하세요. 특정 필드를 자주 쿼리, 필터하다, 정렬 또는 조인하는 경우 해당 필드에 인덱스를 만드는 것이 좋습니다. 인덱스를 사용하여 MongoDB 다음을 수행할 수 있습니다.

쿼리 결과를 더 빠르게 반환
결과를 보다 효율적으로 정렬
$lookup 및 $group 작업 최적화
CPU 및 I/O 사용량 감소

애플리케이션 성장하면배포서버의 인덱스 사용을 모니터 인덱스가 관련 쿼리를 계속 지원 확인합니다.

인덱스를 생성할 때는 다음과 같은 인덱스 동작을 고려하세요.

각 인덱스에는 최소 8KB의 데이터 공간이 필요합니다.
인덱스를 추가하면 쓰기 작업의 성능에 부정적인 영향을 미칠 수 있습니다. 쓰기 대 읽기 비율이 높은 컬렉션의 경우 각 삽입은 인덱스도 업데이트해야 하므로 비용이 많이 듭니다.
읽기 대 쓰기 비율이 높은 컬렉션은 종종 추가 인덱스의 이점을 누릴 수 있습니다. 인덱스는 인덱싱되지 않은 읽기 작업에는 영향을 주지 않습니다.
활성화되면 각 인덱스는 디스크 공간과 메모리를 소비합니다. 이 사용량은 상당할 수 있으므로 작업 세트 크기가 특히 우려되는 경우 용량 계획을 위해 추적해야 합니다.

인덱스에 대한 자세한 내용은 인덱싱 전략을 참조하세요.

추가 고려 사항

데이터 모델을 개발할 때는 다음 고려 사항과 함께 애플리케이션의 모든 읽기 및 쓰기 작업을 분석합니다.

원자성

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

내장된 문서와 배열을 사용하는 비정규화된 데이터 모델 여러 문서와 컬렉션을 정규화하는 대신 모든 관련 데이터를 단일 문서 에 결합합니다. 이 데이터 모델 작업이 여러 문서와 컬렉션에 영향을 미치는 정규화된 모델과 달리 원자성 작업을 허용합니다. 단일 문서 에 대한 원자적 업데이트를 제공하는 데이터 모델 예시 는 원자 조작을 위한 데이터 모델링을 참조하세요.

관련 데이터 간의 참조를 저장하는 데이터 모델의 경우 애플리케이션은 이러한 관련 데이터를 조회하고 수정하기 위해 별도의 읽기 및 쓰기 작업을 수행해야 합니다.

여러 문서(단일 또는 여러 컬렉션)에 대한 읽기 및 쓰기의 원자성이 필요한 상황의 경우, 복제본 세트 및 샤딩된 클러스터에서의 트랜잭션을 포함한 분산 트랜잭션을 지원합니다.

자세한 내용은 트랜잭션을 참조하세요.

중요

대부분의 경우 분산 트랜잭션은 단일 문서 쓰기에 비해 더 큰 성능 비용이 발생하므로 분산 트랜잭션의 가용성이 효과적인 스키마 설계를 대체할 수는 없습니다. 대부분의 시나리오에서 비정규화된 데이터 모델 (내장된 문서 및 배열) 은 계속해서 데이터 및 사용 사례에 최적일 것입니다. 즉, 대부분의 시나리오에서 데이터를 적절하게 모델링하면 분산 트랜잭션의 필요성이 최소화됩니다.

추가 트랜잭션 사용 고려 사항(예: 런타임 제한 및 oplog 크기 제한)은 프로덕션 고려사항을 참조하세요.

데이터 수명 주기 관리

데이터 수명 주기 관리 데이터 생성 및 저장 부터 보관 및 삭제에 이르기까지 데이터를 관리하는 프로세스 의미합니다. 스키마 비용 효율성, 성능 및 보안을 보장하려면 데이터 모델링 결정을 내릴 때 데이터 수명 주기 관리 고려하세요.

애플리케이션 에서 제한된 기간 동안 데이터베이스 에 일부 데이터를 유지해야 하는 경우 TTL(Time to Live) 또는 TTL 기능 사용하는 것이 좋습니다. 예시 를 들어, TTL 컬렉션은 분 동안 활동이 없으면 세션이 자동으로 만료되도록 설정하다 있는 웹 애플리케이션 에서 사용자 로그인 세션을 관리하는 데 유용할 수 30 있습니다. 즉, MongoDB 지정된 기간이 지나면 세션 문서를 자동으로 삭제하므로 효율적인 쿼리를 위해 세션 컬렉션 작게 유지할 수 있습니다.

또한 애플리케이션이 최근에 삽입된 문서만 사용하는 경우 고정 사이즈 컬렉션을 고려하세요. 고정 사이즈 컬렉션은 삽입된 문서의 선입선출(FIFO) 관리를 제공하고 삽입 순서에 따라 문서를 삽입하고 읽는 작업을 효율적으로 지원합니다.

하드웨어 제약 조건

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

작은 문서

각 MongoDB 문서에는 일정량의 오버헤드가 포함되어 있습니다. 이 오버헤드는 일반적으로는 중요하지 않지만 컬렉션의 문서에 필드가 한두 개만 있는 경우처럼 모든 문서가 몇 바이트에 불과한 경우에는 중요한 문제가 될 수 있습니다.

이러한 컬렉션에 대한 저장 활용도를 최적화하기 위한 다음 제안 및 전략을 사용해 보세요.

_id 필드를 명시적으로 사용합니다.
MongoDB 클라이언트는 각 문서에 _id 필드를 자동으로 추가하고 _id 필드에 대해 고유한 12바이트 ObjectId를 생성합니다. 또한 MongoDB는 항상 _id 필드를 인덱싱합니다. 작은 문서의 경우 이는 상당한 양의 공간을 차지할 수 있습니다.
저장 사용을 최적화하려면 컬렉션 에 문서를 삽입할 때 _id 필드 의 값을 명시적으로 지정할 수 있습니다. 이 전략을 사용하면 애플리케이션이 문서 의 다른 부분에서 공간을 차지했던 _id 필드 에 값을 저장 수 있습니다.
_id 필드에는 어떤 값이라도 저장할 수 있지만, 이 값은 컬렉션에 있는 문서의 프라이머리 키로 사용되므로 고유하게 식별해야 합니다. 필드 값이 고유하지 않은 경우에는 컬렉션에 충돌이 발생할 수 있기 때문에 프라이머리 키로 사용할 수 없습니다.
더 짧은 필드 이름을 사용합니다.
참고
필드 이름을 줄이면 MongoDB 에서 BSON 크기를 줄일 수 있지만, 전체 문서 모델 수정하여 BSON 크기를 줄이는 것이 더 효과적인 경우가 많습니다. 필드 이름을 줄이면 표현력이 떨어질 수 있으며, 인덱스에는 필드 이름이 포함되지 않은 사전 정의된 구조가 있으므로 인덱스 크기에 영향을 주지 않습니다.
MongoDB는 모든 문서에 모든 필드 이름을 저장합니다. 대부분의 문서에서 이는 문서가 사용하는 공간 중 극히 일부에 불과합니다. 그러나 작은 문서의 경우 필드 이름은 비례적으로 큰 공간을 나타낼 수 있습니다. 다음과 유사한 작은 문서 컬렉션을 사용해 보세요.
```
{ last_name : "Smith", best_score: 3.9 }
```
다음과 같이 last_name 필드를 lname으로 줄이고 best_score 필드를 score로 줄이면 문서당 9바이트를 절약할 수 있습니다.
```
{ lname : "Smith", score : 3.9 }
```
문서를 삽입합니다.
경우에 따라 다른 문서에 문서를 임베드하여 문서별 오버헤드 절약할 수 있습니다.작은 문서가 많은 컬렉션을 참조하세요.

자세히 알아보기

문서를 구조화하고 스키마 를 정의하는 방법에 대해 자세히 학습 MongoDB University의 데이터 모델링 과정을 참조하세요.

돌아가기

데이터 모델링

포함된 데이터

Scenario	연결 메서드
관련 데이터를 함께 유지하면 데이터 모델 과 코드가 더 간단해집니다.	임베딩
엔터티 간에 'has-a' 또는 'contains' 관계 있습니다.	임베딩
애플리케이션 여러 정보를 함께 쿼리합니다.	임베딩
자주 함께 업데이트되는 데이터가 있습니다.	임베딩
동시에 보관해야 하는 데이터가 있습니다.	임베딩
관계 의 하위 쪽은 카디널리티 높습니다.	참조
데이터 중복은 관리 가 너무 복잡하여 선호되지 않습니다.	참조
결합된 데이터 크기는 애플리케이션 에 너무 많은 메모리 또는 전송 대역폭을 차지합니다.	참조
포함된 데이터는 제한 없이 증가합니다.	참조
쓰기 위주의 워크로드 에서는 데이터가 서로 다른 시간에 기록됩니다.	참조
관계 의 자식 쪽의 경우 데이터는 부모 없이 그 자체로 존재할 수 있습니다.	참조