Brain283. 참조 (Reference) 패턴
핵심 인사이트 (3줄 요약)
- 본질: 참조 패턴(Reference Pattern)은 연관 데이터를 별도의 도큐먼트에 저장하고, 도큐먼트 간 참조(Reference)/링크(Link)를 통해 관계를 표현하는 방식이다. 관계형 데이터베이스의 외래 키(Foreign Key)와 유사하다.
- 가치: 도큐먼트 크기를 관리하고, 데이터 중복을 피하며, N:M 관계와 대규모 배열을 효과적으로 모델링할 수 있다.
- 융합: NoSQL 모델링 전략, 임베디드 패턴, 몽고DB "$lookup", 정규화/역정규화와 밀접하게 연관된다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
개념 정의
참조 패턴(Reference Pattern)은 NoSQL 문서 데이터베이스에서 임베디드 도큐먼트 패턴을 적용하기 어려운 경우에 사용하는 모델링 기법이다. 연관된 데이터를 별도의 도큐먼트에 저장하고, 도큐먼트 간의 참조 관계를 ID(보통 ObjectId 또는 다른 도큐먼트의 고유 식별자)를 통해 표현한다. 관계형 데이터베이스의 외래 키(Foreign Key) 개념과 유사하지만, 참조 무결성(Referential Integrity) 제약이 자동 적용되지 않는다는 점이 다르다.
필요성
모든 데이터를 임베디드하면 도큐먼트 크기가 과도하게 커질 수 있다. MongoDB는 도큐먼트 크기를 16MB로 제한하고 있어, 대규모 배열이나 N:M 관계를 임베디드로 처리하기 어렵다. 또한 임베디드된 데이터가 자주 변경되면 여러 곳의 중복 데이터를 모두 업데이트해야 하는 오버헤드가 발생한다. 이러한 상황에서 참조 패턴은 도큐먼트 크기를 관리하고 데이터 중복을 피할 수 있는 대안이 된다.
배경
문서 데이터베이스에서 참조 패턴은 관계형 데이터베이스의 정규화(Normalization) 설계와 유사한 접근 방식이다. 그러나 관계형 DB와 달리 참조 무결성이 자동 enforcement되지 않으므로, 애플리케이션 레벨에서 참조 무결성을管理해야 한다. 몽고DB의 "$lookup"聚合 연산자를 사용하면 참조된 다른 컬렉션의 데이터를 조인할 수 있지만, 분산 환경에서는 성능 overhead가 발생한다.
비유
참조 패턴은大型서점의 도서 目次に 비유할 수 있다. 각 도서에는 저자 ID만記載되어 있고, 실제 저자 정보는 별도의 저자 目次の카드에 있다. 도서를 빌릴 때 서가의 해당 위치로 가서 도서 카드를 보고, 저자 정보가 필요하면 저자目次の drawer를 별도로 방문한다. 임베디드 패턴은 도서 안에 저자 사진과 약력을 모두印刷해두는 방식이다.
📢 섹션 요약: 참조 패턴은 도큐먼트 간 ID 참조를 통해 관계를 표현하는 방식으로, 도큐먼트 크기 관리와 데이터 중복 방지가 필요한 경우에 적합한 NoSQL 모델링 기법이다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
참조 패턴 구조
┌─────────────────────────────────────────────────────────────────────────────┐
│ 참조 패턴 (Reference Pattern) 구조 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ [MongoDB 참조 패턴 예시] │
│ │
│ ┌─────────────────────┐ │
│ │ Authors 컬렉션 │ ← 저자 정보 (자주 변하지 않음) │
│ │─────────────────────│ │
│ │ { │ │
│ │ "_id": "A001", │ │
│ │ "name": "홍길동", │ │
│ │ "bio": "소설가", │ │
│ │ "birth_year": 1960│ │
│ │ } │ │
│ └──────────┬──────────┘ │
│ │ _id │
│ │ 참조 │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ Books 컬렉션 │ ← 도서 정보 (도큐먼트당 도서 1권) │
│ │─────────────────────│ │
│ │ { │ │
│ │ "_id": "B001", │ │
│ │ "title": "국산व्य",│ │
│ │ "author_id": │ ← 참조 (Authors._id 참조) │
│ │ ObjectId("A001")│ │
│ │ "genre": "소설", │ │
│ │ "price": 15000, │ │
│ │ "published_year": │ │
│ │ 2020 │ │
│ │ } │ │
│ └─────────────────────┘ │
│ │
│ ※ 참조 무결성은 애플리케이션 레벨에서 관리해야 함 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
임베디드 vs 참조 패턴 비교
┌─────────────────────────────────────────────────────────────────────────────┐
│ 임베디드 패턴 vs 참조 패턴 비교 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────┬─────────────────────────┬─────────────────────────┐ │
│ │ │ 임베디드 패턴 │ 참조 패턴 │ │
│ ├──────────────────┼─────────────────────────┼─────────────────────────┤ │
│ │ 읽기 성능 │ ★★★★★ (최적) │ ★★★☆☆ (조인 필요) │ │
│ │ 쓰기 성능 │ ★★★☆☆ (중복 갱신) │ ★★★★☆ (단일 갱신) │ │
│ │ 도큐먼트 크기 │ 클 수 있음 │ 작게 유지 │ │
│ │ 데이터 중복 │ 발생 (역정규화) │ 발생 안 함 (정규화) │ │
│ │ 원자적 갱신 │ 단일 도큐먼트 내 가능 │ 여러 도큐먼트에 걸쳐 복잡 │ │
│ │ N:M 관계 │ 부적합 │ 적합 │ │
│ │ 참조 무결성 │ 자동 보장 (내부) │ 애플리케이션 관리 필요 │ │
│ │ 적합场景 │ 1:1, 1:N, 읽기 heavy │ N:M,频繁 변경, 대용량 │ │
│ └──────────────────┴─────────────────────────┴─────────────────────────┘ │
│ │
│ [결정 트리: 언제 어떤 패턴을 사용해야 하는가?] │
│ │
│ ┌─────────────────────────────────────┐ │
│ │ 데이터建模 시작 │ │
│ └──────────────────┬──────────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────┐ │
│ │ 1:N 관계인가? │ │
│ └────────┬──────────┘ │
│ YES │ NO │
│ │ │ │ │
│ ▼ │ │ │
│ ┌──────────────┐ │ │ │
│ │ 배열 크기 │ │ │ │
│ │ 100개 이하? │ │ │ │
│ └──────┬───────┘ │ │ │
│ YES │ NO │ │ │
│ │ │ │ │ │ │
│ ▼ │ └─────┼──────┘ │
│ ┌──────────┐│ │ ┌───────────────────┐ │
│ │ 임베디드 ││ │ │ N:M 관계이거나 │ │
│ │ 패턴 ││ │ │频繁 변경数据的? │ │
│ └──────────┘│ │ └────────┬──────────┘ │
│ │ │ YES │ NO │
│ │ │ │ │ │ │
│ │ │ ▼ │ │ │
│ │ │ ┌──────────┐│ │ │
│ │ │ │ 참조 ││ │ │
│ │ │ │ 패턴 ││ │ │
│ │ │ └─────────┘│ │ │
│ │ │ │ ▼ │
│ │ │ │ ┌──────────┐ │
│ │ │ │ │ 임베디드 │ │
│ │ │ │ │ 패턴 │ │
│ │ │ │ └─────────┘ │
│ │ │ │ │
│ └─────────┴───────────────┴──→ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
MongoDB "$lookup"을 이용한 참조 조인
┌─────────────────────────────────────────────────────────────────────────────┐
│ MongoDB $lookup 참조 조인 예시 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ db.books.aggregate([ │
│ { │
│ $lookup: { │
│ from: "authors", ← 참조할 컬렉션 │
│ localField: "author_id", ← 현재 컬렉션의 필드 │
│ foreignField: "_id", ← 참조 컬렉션의 필드 │
│ as: "author_detail" ← 결과로 담을 배열 필드명 │
│ } │
│ }, │
│ { │
│ $unwind: "$author_detail" ← 배열을 객체로 풀기 │
│ }, │
│ { │
│ $project: { │
│ title: 1, │
│ genre: 1, │
│ "author_detail.name": 1, │
│ "author_detail.bio": 1 │
│ } │
│ } │
│ ]) │
│ │
│ [결과] │
│ { │
│ "_id": "B001", │
│ "title": "국산व्य", │
│ "genre": "소설", │
│ "author_detail": { │
│ "_id": "A001", │
│ "name": "홍길동", │
│ "bio": "소설가" │
│ } │
│ } │
│ │
│ ※ 분산 환경에서는 $lookup이 성능 overhead를 유발할 수 있음 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 임베디드 패턴과 참조 패턴은 트레이드오프(Trade-off) 관계에 있다. 임베디드 패턴은 읽기 성능에 최적화되어 있지만 쓰기 시 중복 데이터 갱신 overhead가 있고, 도큐먼트 크기 제한에 직면할 수 있다. 참조 패턴은 데이터 중복을 피하고 도큐먼트 크기를 관리할 수 있지만, 조인 연산이 필요하다. 설계 시에는 쿼리 패턴, 데이터 크기, 변경 빈도를 종합적으로 고려해야 한다.
📢 섹션 요약: 참조 패턴은 도큐먼트 간 ID 참조를 통해 관계를 표현하며, N:M 관계와 대규모 데이터를 처리하는 데 적합하다. 단, 조인 overhead와 애플리케이션 레벨의 참조 무결성 관리가 필요하다.
Ⅲ. 결론
참조 패턴은 NoSQL 문서 데이터베이스에서 임베디드 패턴의 한계를 보완하는 모델링 기법이다. 도큐먼트 간 ID 참조를 통해 관계를 표현하므로 도큐먼트 크기를 관리하고 데이터 중복을 피할 수 있다. 그러나 관계형 데이터베이스와 달리 참조 무결성이 자동 적용되지 않아 애플리케이션 레벨에서管理해야 하며, 조인 연산("$lookup")으로 인한 성능 overhead도 고려해야 한다. 따라서 쿼리 패턴, 데이터 크기, 변경 빈도를 종합적으로 분석하여 임베디드 패턴과 참조 패턴 중 적합한 것을 선택하거나, 하이브리드로 사용하는 것이 필요하다.
📢 섹션 요약: 참조 패턴은 도큐먼트 크기 관리와 데이터 중복 회피가 필요한 경우에 유용하지만, 조인 overhead와 참조 무결성 관리 부담이 있으므로 신중한 선택이 필요하다.
핵심 인사이트 ASCII 다이어그램 (Concept Map)
┌─────────────────────────────────────────────────────────────────────────────┐
│ Reference Pattern Concept Map │
│ │
│ ┌─────────────────────────────────┐ │
│ │ Reference Pattern │ │
│ │ (참조 패턴) │ │
│ └───────────────┬─────────────────┘ │
│ │ │
│ ┌────────────────────┼────────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ N:M Relation │ │ Large Array │ │ Data Size │ │
│ │ (N:M 관계) │ │ (대규모 배열) │ │ Management │ │
│ │ │ │ │ │ (크기 관리) │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ └────────────────────┼────────────────────┘ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ $lookup Join │ │
│ │ + App-level Ref │ │
│ │ Integrity │ │
│ │ (조인 + 참조무결성관리) │ │
│ └─────────────────────┘ │
│ │
│ Trade-off: 읽기性能 ↓ | 쓰기性能 ↑ | 중복 ↓ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
참고
- 참조 패턴은 임베디드 패턴의 한계를 보완하는 기법이다.
- 도큐먼트 간 ID 참조를 통해 관계를 표현한다.
- MongoDB "$lookup"을利用하여 조인을 수행할 수 있다.
- 참조 무결성은 애플리케이션 레벨에서管理해야 한다.
- N:M 관계와 대규모 배열 처리에 적합하다.
- 읽기 성능보다는 쓰기 성능과 데이터 일관성이 중요한 경우에 선택한다.