Skip to content

MongoDB

개요

MongoDB는 관계형과 달리 문서(document) 단위로 데이터를 저장하는 NoSQL 데이터베이스예요. 데이터를 테이블의 행이 아니라, 키-값 쌍으로 된 문서(JSON과 비슷한 BSON)로 다뤄요. 그래서 "어떤 필드가 있을지"를 미리 정해 두지 않아도 돼요 — 같은 컬렉션 안의 문서들이 서로 다른 구조를 가질 수 있죠.

이 특징이 우리에게 필요한 이유는 명확해요. 노트나 캔버스 노드처럼 형태가 수시로 바뀌는 콘텐츠는, 필드를 미리 정의해 두면 그때마다 마이그레이션을 해야 해요. 문서형은 그런 부담이 훨씬 적어요.

상태 배지

  • 🔵 적용 — 스키마가 자유로운 문서형 콘텐츠 저장에 도입·적용하고 있어요.

핵심 개념

  • 문서(Document) — 데이터의 기본 단위. 관계형의 행에 해당하지만, 중첩된 객체·배열을 통째로 담을 수 있어요.
  • 컬렉션(Collection) — 문서들의 묶음. 관계형의 테이블에 해당하되, 스키마가 고정되지 않아요 — 같은 컬렉션의 문서라도 필드가 달라도 됩니다.
  • 동적 스키마 — 필드가 없었다가 생겨도, 타입이 바뀌어도 별도 마이그레이션 없이 저장돼요. 이게 문서형의 가장 큰 장점이자, 단점(무결성 보장 부족)이기도 해요.
  • 분산 확장 — 샤딩(데이터를 여러 노드로 나누기)과 레플리카(복제)로 수평 확장을 지원해요.
  • 인덱스 — 관계형처럼 인덱스를 만들어 검색을 빠르게 해요. 컬렉션 안의 특정 필드에 인덱스를 걸 수 있어요.

사용 사례 / 실제 적용

문서형 DB는 관계가 얽혀 있지 않고, 구조가 자주 바뀌는 데이터에 잘 맞아요.

  • 노트·문서 콘텐츠 — 사용자가 만든 콘텐츠는 필드가 수시로 늘어나요. 문서형으로 두면 새 필드가 추가돼도 저장 구조를 바꿀 필요가 없어요.
  • 캔버스 노드 — 캔버스(Canvas)는 요소(node)가 중첩된 구조예요. 문서 전체를 하나의 문서로 담으면 관계형처럼 여러 테이블을 조인할 필요가 없어요.
  • 유연한 메타데이터 — 형태가 제품마다 다른 설정·메타데이터를 문서형에 두면, 스키마 변경 없이 각 제품의 요구를 반영할 수 있어요.

주의할 점도 있어요. 관계형이 보장하는 트랜잭션과 무결성이 필요한 데이터(사용자·구독·권한)는 PostgreSQL로 두는 게 맞아요. MongoDB는 "자유로운 형태의 콘텐츠"라는 특성에 맞는 저장소로 쓰는 거예요.

심화 챕터

MongoDB의 핵심 원리는 아래 챕터에서 공식 문서를 기준으로 더 깊게 다뤄요.

더 알아보기