참조는 한 문서 contact access 에서 다른 문서로 연결되는 링크(참조라고 함)를 포함하여 데이터 간의 관계를 저장 . 애플리케이션은 이러한 참조를 확인하여 관련 데이터에 액세스 할 수 있습니다. 다음 예시 에서 및 문서에는 user 문서 에 대한 참조가 포함되어 있습니다.
데이터가 여러 컬렉션으로 나뉘고 중복되지 않기 때문에 참조는 정규화된 데이터 모델을 생성합니다.
사용 사례
비정규화된 데이터 모델은 MongoDB 의 대부분의 사용 사례에 작동하지만, 다음과 같은 경우 포함된 데이터 대신 참조를 사용하는 것이 좋습니다.
임베딩으로 인해 데이터 중복이 발생하지만, 중복으로 인한 영향을 능가할 만큼 충분한 읽기 성능 이점을 제공하지 않습니다. 예를 들어 임베디드 데이터가 자주 변경되는 경우입니다.
복잡한 다대다 관계 또는 대규모 계층적 데이터 세트를 표현해야 합니다.
관련 엔터티를 자체적으로 자주 쿼리 해야 합니다.
많은 수의 컬렉션
특정 상황에서는 관련 정보를 단일 컬렉션이 아닌 여러 컬렉션에 저장하도록 선택할 수 있습니다.
다양한 환경 및 애플리케이션에 대한 로그 문서를 저장하는 샘플 컬렉션 logs(을)를 고려해 보세요. logs 컬렉션에는 다음과 같은 형식의 문서가 포함되어 있습니다.
{ log: "dev", ts: ..., info: ... } { log: "debug", ts: ..., info: ...}
총 문서 수가 적으면 문서를 유형별 컬렉션으로 그룹화할 수 있습니다. 로그의 경우 logs_dev 및 logs_debug와 같은 별도의 로그 컬렉션을 유지하는 것이 좋습니다.
일반적으로 컬렉션 수가 많으면 성능 저하가 크지 않으며 성능도 좋습니다. 고유 컬렉션은 처리량이 많은 배치 처리 에 매우 중요합니다.
컬렉션 수가 많은 모델을 사용하는 경우 동작을 살펴보세요.
각 컬렉션에는 몇 킬로바이트의 특정 최소 오버헤드가 있습니다.
인덱싱되지 않은 읽기 작업은 많은 양의 메모리를 사용할 수 있습니다.
각 데이터베이스 에 대해 단일 네임스페이스 파일
<database>.ns(예:)은 해당 데이터베이스 의 모든 메타데이터 저장합니다. 각 인덱스 와 컬렉션 네임스페이스 파일 에 고유한 항목이 있습니다. 구체적인 제한 사항은 네임스페이스 길이 제한을 참조하세요.
정규화된 데이터 모델 쿼리
여러 컬렉션의 정규화된 데이터를 쿼리하기 위해 MongoDB는 다음과 같은 집계 단계를 제공합니다.
정규화된 데이터 모델의 예시는 문서 참조를 통한 일대다 관계 모델링을 참조하세요.
다양한 트리 모델의 예는 트리 구조 모델링을 참조하세요.