MongoDB 기본(document, collection, _id)

몽고DB는 매우 강력하면서도 진입장벽이 낮다. 몽고DB의 기본 개념에 대해 알아보자.

도큐먼트

몽고DB의 핵심은 정렬된 키와 연결된 값의 집합으로 이뤄진 도큐먼트다. 도큐먼트 표현 방식은 프로그래밍 언어마다 다르지만 자바스크립트 객체로 표현하겠다.

{"name" : "Hello world!"}

 

이 간단한 도큐먼트는 name 키 값과 벨류를 가진다. 대부분의 도큐먼트는 이보다 복잡한 다중 키/값 쌍을 가진다.

또한 몽고DB는 데이터형과 대소문자를 구별하고 중복된 키를 넣을 수 없다. 아래 도큐먼트는 올바른 도큐먼트가 아니다.

{"name" : "123", "name" : "456"}

---

컬렉션

컬렉션은 도큐먼트의 모음이다. 몽고DB의 도큐먼트가 관계형 데이터베이스의 행에 대응된다면 컬렉션은 테이블에 대응된다고 볼 수 있다.

 

동적 컬렉션

컬렉션은 동적 스키마를 가진다. 하나의 컬렉션 내 도큐먼트들이 모두 다른 구조를 가질 수 있다.

예를 들어 다음 도큐먼트들을 하나의 컬렉션에 저장할 수 있다.

{"name":"123"}
{"hello":"world"}

도큐먼트들의 키, 키의 개수, 데이터형의 값은 모두 다르다. 그렇다면 도큐먼트에 별도의 스키마가 없는데 왜 하나 이상의 컬렉션이 필요할까?

- 같은 종류의 데이터를 하나의 컬렉션에 모아두면 데이터 지역성에 좋다. 블로그 게시물 여러 개를 뽑는 경우, 게시물과 저자 정보가 썩인 컬렉션보다 게시물만 들어있는 컬렉션에서 뽑을 때 디스크 탐색 시간이 더 짧다.

- 인덱스를 만들면 도큐먼트는 특정 구조를 가져야한다(고유 인덱스일 경우 특히 더 그렇다). 이러한 인덱스는 컬렉션 별로 정의한다. 같은 유형의 도큐먼트를 하나의 컬렉션에 넣음으로써 컬렉션을 효율적으로 인덱싱할 수 있다.

 

애플리케이션 스키마는 기본적으로 필요하지는 않지만 정의하면 좋다. 몽고DB의 도큐먼트 유효성 검사기능과 객체-도큐먼트 매핑 라이브러리를 이용하는 많은 프로그래밍 언어에서 사용 가능하다.

 

서브 컬렉션

컬렉션의 네임스페이스에 .(마침표) 문자를 사용해 컬렉션을 체계화한다. 예를 들어 블로그 기능이 있는 애플리케이션은 blog.posts와 blog.authors라는 컬렉션을 가질 수 있다. 이는 단지 체계화를 위함이며 아무런 관계는 없다. 서브 컬렉션은 특별한 속성은 없지만 여러 툴에서 지원하므로 유용하다.

---

내장 도큐먼트

도큐먼트는 키에 대한 값이 될 수 있는데 이를 내장 도큐먼트라고 한다. 내장 도큐먼트를 사용하면 데이터를 키/값 쌍의 평면적인 구조보다는 좀 더 자연스러운 방법으로 구성할 수 있다.

 

예를 들어 한사람의 정보를 나타내는 도큐먼트에 그의 주소를 저장하려면 정보를 "address" 내장 도큐먼트로 중첩한다.

{
  "name" : "yoon",
  "address" : {
    "city" : "bundang",
    "street" : "migeum111"
  }
}

이와 같은 방법은 좀 더 자연스럽게 정보를 표현할 수 있지만 많은 데이터 반복이 생길 수 있다는 단점이 있다.

---

_id와 ObjectId

몽고DB에 저장된 모든 도큐먼트는 "_id" 키를 가진다. "_id" 키 값은 어떤 데이터형이어도 상관 없지만 "ObjectId"가 기본이다. 하나의 컬렉션에서 모든 도큐먼트는 고유한 "_id" 값을 가지며, 이 값은 컬렉션 내 모든 도큐먼트가 고유하게 식별되게 한다.

 

ObjectIds

ObjectId는 "_id"의 기본 데이터형이다. ObjectId 클래스는 경량으로 설계됐으면서도 여러 장비에 걸쳐 전역적으로 유일한 방법으로 생성하기도 쉽다. 자동 증가하는 기본 키처럼 전통적인 것이 아닌 ObjectId를 사용하는 주요 이유는 몽고DB의 분산 특성 떄문이다. 여러 서버에 걸쳐 자동으로 증가하는 기본 키를 동기화 하는 작업은 어렵고 시간이 걸린다. 몽고DB는 분산 데이터베이스로 설계됐기 때문에 샤딩된 환경에서 고유 식별자를 생성하는 것이 매우 중요했다. 

 

ObjectId는 12바이트 스토리지를 사용하며 24자리 16진수 문자열 표현이 가능하다. 바이트당 2자리를 사용한다. 여러개의 새로운 ObjectId를 연속으로 생성하면 매번 마지막 숫자 몇개만 바뀐다. 몇 초 간격을 두고 생성하면 중간 숫자 몇개가 바뀐다. 이는 생성되는 방식 때문이다.

 

ObectId의 첫 4바이트는 타임스탬프다. 1970년 1월 1일부터의 시간을 1/1000초 단위로 저장하는 타임스탬프이며 유용한 속성을 제공한다.

  - 타임스탬프는 4바이트 이후 뒤의 값 5바이트~ 묶일 때 초단위의 유일성을 제공한다.

  - 타임스탬프가 맨 처음에 온다는 것은 ObjectId가 대략 입력 순서대로 정렬된다는 의미다. 이는 확실히 보장되지는 않지만 효율적으로 인   덱싱하는 특성이 있다.

 

다음 5바이트는 랜덤 값이다. 최종 3바이트는 서로 다른 시스템에서 충돌하는 ObjectId들을 생성하지 않도록 랜덤 값으로 시작하는 카운터다. ObjectId의 앞 9바이트는 1초 동안 여러 장비와 프로세스에 걸쳐 유일성을 보장한다.

 

마지막 3바이트는 단순히 증분하는 숫자로 1초 내 단일 프로세스의 유일성을 보장한다. 고유한 ObjectId는 프로세스당 1초에 256^3(1677만7216)개까지 생성된다.

 

도큐먼트를 입력할 때 "_id" 키를 명시하지 않으면 키가 자동으로 추가된다. 이는 몽고DB 서버에서 관리할 수 있지만 일반적으로 클라이언트 쪽 드라이버에서 관리한다.

 

 

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=268367408 

[전자책] MongoDB 완벽 가이드