Document Store

함께 읽는 데이터를 문서 1개에 중첩해 담습니다

주문 상세처럼 사용자, 항목 목록, 상태가 한 번에 필요할 때는 저장 구조도 그 조회 단위에 맞추는 편이 빠르게 읽힙니다.

문서 구조

앱이 쓰는 객체 모양이 그대로 저장됩니다

JSON/BSON은 중첩 객체와 배열을 바로 담을 수 있어서 주문 1건의 문맥을 한 문서 안에 유지합니다. 

{
  "_id": "order_001",
  "user": { "id": 1001, "name": "김철수" },
  "items": [
    { "product": "노트북", "qty": 1, "price": 1500000 },
    { "product": "마우스", "qty": 2, "price": 50000 }
  ],
  "status": "shipped",
  "total": 1600000
}
user

주문과 함께 읽는 고객 문맥을 같은 문서 안에 포함합니다.

items[]

반복되는 주문 항목을 배열 그대로 보관해 계층형 데이터를 자연스럽게 표현합니다.

status, total

현재 상태와 요약값을 같은 원자적 단위로 읽어 화면이나 API 응답에 바로 씁니다.

같은 주문 1건 조회

필요한 정보를 만드는 경로가 달라집니다

앱이 원하는 결과: 주문 상세 JSON 1개
RDB
관련 테이블을 조인한 뒤 다시 주문 객체로 조립

정규화에는 유리하지만, 화면에 필요한 묶음을 조회 시점에 다시 만들어야 합니다.

orders -> users -> order_items -> order detail
문서형
컬렉션에서 문서 1개를 읽으면 필요한 구조가 바로 나옴

자주 함께 조회되는 범위를 문서에 모아 조인 단계 없이 바로 사용할 수 있습니다.

orders -> order_001 document -> order detail
언제 잘 맞는가

읽기 중심 경계가 분명한 데이터

중첩 구조가 실제 도메인과 비슷할 때

사용자 프로필, 상품 카탈로그, 주문처럼 객체 안에 하위 정보가 자연스럽게 딸려오는 경우입니다.

함께 바뀌고 함께 읽는 범위가 있을 때

문서 하나가 의미 있는 저장 단위가 되면 저장과 조회 경계가 명확해지고 애플리케이션 코드도 단순해집니다.

정리

Document Store는 관계를 없애는 모델이 아니라, 자주 함께 조회되는 관계를 한 문서 안으로 끌어와 중첩 구조로 저장하는 방식입니다.