Database, Collection, Document, Field,

MongoDB, AWS DocumentDB/아키텍처 및 내부 구조

Database, Collection, Document, Field, _id 추가 이해

`O` 2025. 5. 19. 22:10

728x90

이 페이지에서는 MongoDB 를 공부하기 위해 주로 사용되는 용어들인 Database, Collection, Document, Field, _id 에 대하여 다룬다.

이 블로그는 RDBMS 중심으로 관련된 내용으로 기재되었기에 RDBMS 개념에 빗대어 관련된 사항들을 설명한다.

이 페이지는 perplexity 를 통해 필자가 어떤 prompt 를 작성하여 공부하는지를 공유한다. ([] 로 표기)

또한, 검색이외에 추가로 덧붙일 내용은 ※ 로 추가한다.

이전 게시글에서 MongoDB 의 RDBMS 에 대응 되는 개념들을 표로 확인했었다. 이를 다시 본글을 게시전에 올린 후 다시 본글을 작성한다.

[+] 2025.05.13 - [MongoDB, AWS DocumentDB/아키텍처 및 내부 구조] - MongoDB 를 공부하기 위해 필요한 기본 용어 및 데이터 예시

RDBMS	MongoDB
Database	Database
Table	Collection
Row / Tuple	Document
Column	Field
Primary Key	_id

[MongoDB 의 데이터베이스 개념에 대해서 알려줘]

MongoDB에서 데이터베이스(Database)는 관련된 데이터의 컬렉션(Collection)들을 논리적으로 묶어 관리하는 가장 상위 단위다. 하나의 MongoDB 서버(인스턴스)에는 여러 개의 데이터베이스를 생성할 수 있으며, 각 데이터베이스는 서로 독립적으로 동작한다. 데이터베이스는 컬렉션과 도큐먼트(Document)를 포함하는 계층 구조의 최상위에 위치한다.

MongoDB의 데이터베이스 구조는 다음과 같다.

Database > Collection > Document > Field
데이터베이스 안에는 여러 개의 컬렉션이 존재하고, 각 컬렉션은 여러 개의 도큐먼트(문서)를 포함한다. 도큐먼트는 key-value 쌍의 필드로 구성된다.

MongoDB 데이터베이스의 주요 특징은 아래와 같다.

문서 지향적
MongoDB는 데이터를 테이블이 아닌 JSON 또는 BSON 형태의 도큐먼트로 저장한다. 이 도큐먼트들은 컬렉션에 저장되며, 컬렉션은 데이터베이스에 포함된다.
스키마리스(Schema-less)
데이터베이스 내의 컬렉션은 스키마가 고정되어 있지 않으므로, 도큐먼트마다 구조가 달라도 저장할 수 있다.
확장성과 유연성
데이터베이스 단위로 분산 저장(샤딩) 및 복제(Replication)가 가능하여 대용량 데이터 처리와 확장에 용이하다.
독립성
각 데이터베이스는 이름, 사용자, 접근 권한, 저장 경로 등이 분리되어 있어 서로 영향을 주지 않는다.

MongoDB는 기본적으로 admin, local, config와 같은 시스템 데이터베이스를 제공하며, 사용자는 필요에 따라 새로운 데이터베이스를 자유롭게 생성할 수 있다.

정리하면, MongoDB의 데이터베이스는 관련된 데이터 집합을 논리적으로 구분하고, 그 안에 컬렉션과 도큐먼트가 계층적으로 포함되는 구조를 가진다. 데이터베이스 단위로 관리와 확장이 가능하며, 유연한 데이터 모델링과 대규모 데이터 처리가 용이하다는 장점이 있다.

[MongoDB 에서 특별한 데이터베이스를 알려줘]

MongoDB에는 일반 데이터베이스와 달리 특별한 용도로 예약된 데이터베이스가 존재한다. 주요 특별 데이터베이스는 다음과 같다.

admin
MongoDB의 루트(root) 데이터베이스다.
이 데이터베이스에 추가된 사용자는 전체 MongoDB 인스턴스 내 모든 데이터베이스에 대해 모든 권한을 가진다.
서버 전역에 걸친 관리 명령어(예: 사용자 관리, 서버 설정 등)는 admin 데이터베이스에서만 실행할 수 있다5.
local
각 MongoDB 인스턴스(서버)마다 고유하게 존재하는 데이터베이스다.
복제 세트 환경에서도 local 데이터베이스는 복제되지 않는다.
이곳에는 해당 인스턴스의 메타데이터, 운영 로그, 복제 관련 정보 등이 저장된다.
예를 들어, oplog(operations log)도 local 데이터베이스에 저장된다.
config
샤딩(Sharding) 환경에서만 사용되는 내부 데이터베이스다.
샤딩된 클러스터의 메타데이터(샤드 정보, 분할 키, 클러스터 구성 등)를 저장한다.
config 데이터베이스는 내부적으로만 사용되며, 일반 애플리케이션에서 데이터를 직접 저장하거나 수정해서는 안 된다.
이 데이터베이스의 스키마나 구조는 MongoDB 버전에 따라 변경될 수 있다.

이 외에도 일반적으로는 사용자 정의 데이터베이스를 만들어 사용하지만, 위 세 가지(admin, local, config)는 MongoDB 시스템 운영과 관리에 필수적인 특별한 데이터베이스다.

[MongoDB 의 Collection 개념에 대해서 알려줘]

MongoDB에서 컬렉션(Collection)은 도큐먼트(Document)의 그룹을 의미하며, 관계형 데이터베이스(RDBMS)의 테이블(Table)과 유사한 개념이다. 컬렉션은 단일 데이터베이스 내에 존재하며, 일반적으로 유사하거나 관련된 목적의 데이터를 저장하는 데 사용한다.

컬렉션의 주요 특징은 다음과 같다.

스키마의 자유로움
컬렉션은 스키마를 강제하지 않는다. 즉, 컬렉션 내부의 도큐먼트들은 서로 다른 필드와 구조를 가질 수 있다. 이는 RDBMS의 테이블과 달리, 데이터 구조가 유연하게 변할 수 있음을 의미한다.
데이터 그룹화
컬렉션은 보통 비슷한 목적이나 주제를 가진 도큐먼트들을 함께 저장한다. 예를 들어, 사용자 정보, 상품 정보, 주문 정보 등 각각의 데이터 유형을 별도의 컬렉션으로 관리할 수 있다.
RDBMS와의 비교
RDBMS의 Table = MongoDB의 Collection, Row = Document, Column = Field로 대응된다.
동적 생성
컬렉션은 명시적으로 생성할 수도 있고, 도큐먼트를 처음 삽입할 때 자동으로 생성되기도 한다.
관리의 유연성
컬렉션은 필요에 따라 생성, 삭제, 이름 변경 등이 자유롭게 가능하다. 또한, 컬렉션마다 인덱스, 옵션, 용량 등을 별도로 관리할 수 있다.

예를 들어, 쇼핑몰 데이터베이스에서 "users", "products", "orders"와 같은 컬렉션을 만들고, 각각의 컬렉션에 관련 도큐먼트들을 저장할 수 있다. 각 도큐먼트는 이름, 가격, 수량 등 다양한 필드를 가질 수 있으며, 컬렉션 내 도큐먼트마다 필드 구조가 달라도 무방하다.

정리하면, MongoDB의 컬렉션은 다양한 구조의 도큐먼트들을 유연하게 저장하고 관리할 수 있는 논리적 데이터 그룹으로, 데이터베이스 내에서 데이터를 분류하고 조직하는 핵심 단위다.

[Collection 에서 schema 의 제한이 없는 이점이 있음에도 실제 DB 설계에서 Collection 분리가 중요한 이유]

MongoDB는 컬렉션 스키마에 제한이 없다는, 즉 동적 스키마(schemaless) 특성을 가지고 있다. 이로 인해 하나의 컬렉션에 서로 다른 구조의 도큐먼트를 자유롭게 저장할 수 있다는 장점이 있지만, 실제 DB 설계에서는 컬렉션 분리가 매우 중요하다. 그 이유는 다음과 같다.

관리의 용이성
다양한 구조의 도큐먼트가 하나의 컬렉션에 섞여 있으면 데이터 관리가 어려워진다. 특정 유형의 데이터를 추출할 때마다 복잡한 필터링이 필요하고, 데이터 구조 파악이 힘들어진다. 컬렉션을 목적과 구조에 따라 분리하면 관리가 훨씬 쉬워진다.
조회 성능 향상
필요한 데이터가 한 컬렉션에 모여 있으면, 쿼리 시 불필요한 도큐먼트까지 탐색할 필요가 없어 속도가 빨라진다. 컬렉션의 데이터 구조가 거의 동일하게 유지되므로 효율적으로 인덱싱할 수 있고, 조회 성능이 크게 향상된다.
데이터 일관성 및 확장성
데이터 구조가 일관되게 유지되면, 데이터의 무결성이나 확장성 측면에서 유리하다. 예를 들어, 대용량 데이터가 한 도큐먼트에 배열로 저장될 경우 MongoDB의 도큐먼트 최대 크기(16MB)를 초과할 수 있는데, 컬렉션을 분리하면 이런 문제를 예방할 수 있다. 또한, 분리된 컬렉션마다 별도의 인덱스를 적용하거나 관리할 수 있어 확장성이 높아진다.
성능 및 유지보수 최적화
컬렉션 분리를 통해 각 컬렉션의 특성에 맞는 인덱스 설계와 쿼리 최적화를 할 수 있다. 데이터가 커지거나 구조가 복잡해질수록 컬렉션 분리는 유지보수와 성능 관리에 매우 중요하다.
데이터 중복 및 혼란 방지
동적 스키마의 자유로움 때문에 데이터 중복이나 불필요한 정보가 섞일 위험이 있다. 컬렉션을 분리하면 데이터 중복을 줄이고, 데이터의 명확한 구분이 가능해진다.

요약하면, MongoDB의 스키마 제한이 없는 유연성은 데이터 모델링에 큰 장점이지만, 실제 운영 환경에서는 데이터의 구조, 목적, 액세스 패턴에 따라 컬렉션을 분리하는 것이 데이터 관리, 성능, 확장성, 유지보수 측면에서 필수적이다. 이는 데이터베이스의 효율적 운영과 장기적 안정성을 위해 반드시 고려해야 할 설계 원칙이다.

[MongoDB 의 SubCollection 에 대해서 알려줘]

MongoDB에서 SubCollection(서브 컬렉션)은 컬렉션 이름에 마침표(.)를 사용하여 계층적으로 컬렉션을 체계화하는 네이밍 방식이다. 예를 들어, coffee.mocha, coffee.americano와 같이 컬렉션명을 지정하면 논리적으로 coffee라는 상위 그룹 아래에 mocha, americano라는 하위 컬렉션이 있는 것처럼 구분할 수 있다.

서브 컬렉션의 주요 특징은 다음과 같다.

네임스페이스 체계화
마침표(.)를 이용해 컬렉션 이름을 계층적으로 구분함으로써, 대규모 프로젝트에서 데이터 구조를 논리적으로 정리하고 관리하기 쉽다. 예를 들어, blog.posts, blog.comments, blog.authors와 같이 사용할 수 있다.
실제 계층 구조 없음
서브 컬렉션은 단순히 네이밍 규칙일 뿐, coffee와 coffee.mocha 컬렉션 사이에 실제 데이터 상의 부모-자식 관계나 종속성이 존재하지 않는다. coffee 컬렉션이 없어도 coffee.mocha 컬렉션은 독립적으로 존재할 수 있다.
관리 및 접근 편의성
서브 컬렉션 네이밍은 컬렉션을 논리적으로 그룹화하여 관리와 접근성을 높여준다. 특히, 관련 데이터들을 명확하게 분류하고자 할 때 유용하다.
특정 기능에서 활용
GridFS와 같이 큰 파일을 저장할 때, 콘텐츠 데이터와 메타데이터를 구분하여 저장하기 위해 서브 컬렉션 네이밍을 활용하기도 한다.

예시:

blog.posts: 블로그 게시글 데이터를 저장하는 컬렉션
blog.comments: 블로그 댓글 데이터를 저장하는 컬렉션
shop.orders: 쇼핑몰 주문 데이터를 저장하는 컬렉션

정리하면, MongoDB의 SubCollection은 컬렉션을 계층적으로 체계화하기 위한 네이밍 규칙이며, 실제 계층적 데이터 구조를 의미하지 않는다. 데이터의 논리적 분류와 관리 편의성을 위해 자유롭게 활용할 수 있다.

[MongoDB 의 Document 개념을 알려줘]

MongoDB에서 Document(도큐먼트)는 데이터를 저장하는 기본 단위다. 도큐먼트는 JSON(JavaScript Object Notation) 형태와 유사하지만, 실제로는 BSON(Binary JSON) 포맷으로 저장된다. 각 도큐먼트는 키-값 쌍(key-value pair)으로 구성되어 있으며, 하나의 도큐먼트는 하나의 레코드(행, row)에 해당한다고 볼 수 있다.

도큐먼트의 주요 특징은 다음과 같다.

유연한 구조
도큐먼트는 필드의 개수, 이름, 데이터 타입이 자유롭다. 같은 컬렉션 내에서도 도큐먼트마다 구조가 달라도 된다.
중첩 구조 지원
값으로 배열(Array)이나 또 다른 도큐먼트(Embedded Document)를 가질 수 있어, 복잡한 데이터 구조를 한 도큐먼트에 담을 수 있다.
고유 식별자
모든 도큐먼트는 _id 필드를 반드시 포함하며, 이를 통해 도큐먼트를 고유하게 식별한다.
BSON 포맷
실제 저장은 BSON(Binary JSON) 포맷으로 이루어진다. BSON은 JSON보다 더 다양한 데이터 타입(날짜, 바이너리 등)을 지원한다.

예시

{
  "_id": ObjectId("5f1d7f3e6b8e2a0017b8e1c2"),
  "name": "홍길동",
  "age": 30,
  "email": "hong@test.com",
  "address": {
    "city": "서울",
    "zipcode": "12345"
  },
  "hobbies": ["독서", "등산"]
}

[MongoDB 의 Field 에 대해서 알려줘]

MongoDB에서 Field(필드)는 도큐먼트(Document) 내에서 데이터를 저장하는 기본 단위로, RDBMS의 컬럼(Column)과 유사한 개념이다. 각 도큐먼트는 여러 개의 필드와 그에 대응하는 값(value) 쌍으로 구성된다. 필드의 이름은 문자열로 지정하며, 값에는 문자열, 숫자, 날짜, 배열, 또 다른 도큐먼트(임베디드 도큐먼트) 등 다양한 데이터 타입을 저장할 수 있다.

MongoDB는 스키마가 고정되어 있지 않기 때문에, 각 도큐먼트마다 필드의 개수, 이름, 데이터 타입이 달라도 무방하다. 즉, 한 컬렉션 내의 도큐먼트들이 서로 다른 필드를 가질 수 있고, 필요에 따라 필드를 자유롭게 추가하거나 제거할 수 있다. 이로 인해 데이터 구조의 유연성이 매우 높아지고, 다양한 형태의 데이터를 손쉽게 저장할 수 있다.

예시를 들면 아래와 같다.

예시

{
  "_id": ObjectId("5f1d7f3e6b8e2a0017b8e1c2"),
  "name": "홍길동",
  "age": 30,
  "email": "hong@test.com",
  "address": {
    "city": "서울",
    "zipcode": "12345"
  },
  "hobbies": ["독서", "등산"]
}

위 예시에서 각 항목(예: name, age, email, address, hobbies)이 모두 필드이며, address는 임베디드 도큐먼트, hobbies는 배열 타입의 필드다.

정리하면, MongoDB의 필드는 도큐먼트 내에서 데이터를 저장하는 핵심 단위로, 다양한 데이터 타입과 구조를 지원하며, 스키마의 제약 없이 자유롭게 추가·제거할 수 있다는 특징을 가진다.

[MongoDB 의 _id 에 대해서 알려줘]

MongoDB에서 _id는 각 도큐먼트를 고유하게 식별하는 필드로, 일종의 Primary Key 역할을 한다. 모든 도큐먼트는 반드시 _id 필드를 가져야 하며, 이 값이 중복되면 동일 컬렉션 내에 저장할 수 없다. _id 값은 기본적으로 ObjectId 타입이 자동 생성되지만, 사용자가 직접 원하는 값으로 지정할 수도 있다.

ObjectId는 12바이트로 구성된 고유한 값이며, 4바이트 타임스탬프, 5바이트 머신 및 프로세스 고유 값, 3바이트 증가 카운터로 이루어진다. 이 구조 덕분에 분산 환경에서도 유일성을 보장할 수 있다. _id 필드는 한 번 생성되면 수정이 불가능하며, 컬렉션 단위로 고유성을 보장한다.

만약 _id 필드를 명시하지 않고 도큐먼트를 삽입하면 MongoDB가 자동으로 ObjectId를 생성해 할당한다. 반대로 _id 값을 명시적으로 지정할 경우, 중복된 값이 있으면 오류가 발생한다. 또한 _id 필드는 기본적으로 Unique Index가 생성되어 있어, 쿼리 성능 향상에도 기여한다.

요약하면, _id는 MongoDB에서 각 도큐먼트를 유일하게 식별하고, 데이터 무결성과 쿼리 성능을 보장하는 필수 필드다. 기본값은 ObjectId이지만, 필요에 따라 다른 데이터 타입도 사용할 수 있다.

[MongoDB 의 위의 사항들에 대한 naming rule 을 알려줘]

데이터베이스 네이밍 규칙

소문자 또는 카멜케이스를 사용하되, 소문자 사용을 권장한다.
영문자(a-z), 숫자(0-9)만 사용한다.
대소문자를 구분한다.
64바이트 미만으로 작성한다.
공백, 널 문자열, 일부 특수문자(예: /, , ., *, <, >, :, ;, ?, $, \0, 공백)는 사용할 수 없다.
가독성을 위해 하이픈(-) 또는 언더스코어(_) 구분자 사용을 권장한다.
운영체제에 따라 금지되는 특수문자가 있으니 주의한다.

컬렉션 네이밍 규칙

소문자 또는 카멜케이스를 사용하되, 소문자 사용을 권장한다.
영문자(a-z), 숫자(0-9)만 사용한다.
대소문자를 구분한다.
120바이트 이하로 작성해야 한다.
$, 공백, 널문자, 일부 특수문자(예: /, , ., *, <, >, :, ;, ?, $, \0, 공백)는 사용할 수 없다.
가독성을 위해 하이픈(-) 또는 언더스코어(_) 구분자 사용을 권장한다.
복수형 사용을 권장한다(ex. products, employees).
컬렉션 이름이 이미 사용 중이면 중복 생성이 불가하다.

도큐먼트 네이밍 규칙

도큐먼트는 컬렉션 내에 저장되는 데이터 단위이므로 별도의 이름이 없다.
도큐먼트 내 필드명에 대한 규칙을 참고한다.

필드(Field) 네이밍 규칙

필드명은 문자열이어야 하며, 널(null) 값이나 공백은 허용되지 않는다.
소문자 또는 카멜케이스를 사용하되, 소문자 사용을 권장한다.
$로 시작할 수 없으며, MongoDB 3.6 이상에서는 .(마침표)와 $를 필드명에 포함할 수 있지만, 특별한 경우가 아니면 피하는 것이 좋다.
필드명에는 공백, 널문자, 일부 특수문자(예: /, , *, <, >, :, ;, ?, $, \0, 공백)는 사용하지 않는다.
가독성을 위해 언더스코어(_)를 사용할 수 있다.
필드명은 명확하고 직관적으로 작성한다.
동적 필드명 사용은 쿼리 복잡도와 성능 저하, 인덱스 문제를 유발할 수 있으므로 주의한다.

_id 네이밍 규칙

_id는 각 도큐먼트의 고유 식별자 필드로, 모든 도큐먼트에 반드시 존재해야 한다.
컬렉션 내에서 유일(unique)해야 하며, 한 번 할당된 _id는 변경할 수 없다.
기본적으로 ObjectId 타입이 자동 할당되지만, 사용자가 임의의 값(문자열, 숫자 등)으로 지정할 수도 있다.
_id 필드는 반드시 "_id"라는 이름을 사용해야 한다.

728x90

저작자표시 비영리 변경금지 (새창열림)