Mongo DB - Mongo DB Intro(2)

Mongo DB - Mongo DB Intro(2)

Mongo DB - Mongo DB Intro(1)

http://cogandkim.tistory.com/9

MongoDB는 매우 강력하면서도 진입 장벽이 낮다.

✦  MongoDB 데이터의 기본 단위는 문서인데, 관계형 DB의 행과 유사하다. (하지만, 더 많은 자료형이 있음)

✦ 같은 맥락에서 콜렉션(collection)은 스키마(schema)가 없는 테이블(table)

✦ 단일 인스턴스(instance)는 여러 독립적인 DB를 호스팅할 수 있고, DB는 자체적인 콜렉션들과 권한을 가짐

✦ 모든 문서는 문서 콜렉션 내에서 고유한 특수 키인 “_id”를 가진다.

✦ 인스턴스 관리와 데이터 조작에 유용한, 단순하지만 강력한 자바스크립트(javascript) 셸을 지원

2.1 문서 document

정렬된 키와 연결된 값의 집합으로 이루어진 문서

대부분의 언어는 맵(map), 해쉬(hash), 딕셔너리(dictionary) 와 같은 문서를 자연스럽게

표현할 수 있는 자료 구조를 가지고 있다.

document

javascript에서 문서를 객체로 표현한 예

{“greeting” : “Hi, Sexy!”}

greeting 이라는 키 값에 “Hi, Sexy!”라는 값을 가짐

대부분의 문서는 이보다 더 복잡한 다중 키/값 쌍을 가진다.

{“greeting” : “Hi, Sexy!”, “sex” : “man”, “age” : 26}

위에서 보듯, 문서의 값은 단지 blob 형이 아니다.

값은 데이터 형 중 하나 여야만 한다.(또는 내장 문서가 되기도 함)

문서의 키는 문자열이다.

UTF-8 문자도 사용 가능하다.

단, 키는 \0(null 문자)를 포함하지 않는다. 이 문자는 키의 끝을 나타내는데 사용된다.

.(dot) $(dollar) 문자는 몇 가지 특별한 속성을 가지고 있어, 특정 상황에만 사용해야 된다.

이 문자들은 보통 예약어로 취급해야 하며, 부적절 사용 시 드라이버에서 경고 발생

MongoDB는 데이터 형과 대소문자를 구별한다.

{“data” : 3} {“data” : “3”} -> 다름

{“data” : 3} {“Data” : “3”} -> 다름

MongoDB의 문서에서 가장 중요한 점은 키가 중복될 수 없다는 것

{“greeting” : “Hello, Sexy!”, “greeting” : “Hello, MongoDB”} 올바르지 않음(x)

문서의 키/값 쌍은 정렬되어 있다.

대부분의 경우 문서에서 키의 순서는 중요하지 않으며, 스키마를 그러한 키의 순서에 의존적으로 설계할 필요는 없음

(MongoDB는 재배열)

{“x”:1, “y”:2} {“y”:2, ”x”:1} 서로 다르다.

일부 프로그래밍 언어(Python, Perl, Ruby)는 순서를 전혀 유지하지 않는다.

2.2 콜렉션 collection

콜렉션(collection)은 문서의 모음이다. 관계형 DB의 행이라면 콜렉션(collection)은 table로 볼 수 있음.

1. 동적 스키마(dynamic schema)

콜렉션은 동적 스키마를 가진다.

이는 하나의 콜렉션 내 문서들이 모든 다른 구조를 가질 수 있다는 것이다.

예를 들어 다음 문서들을 하나의 콜렉션에 같이 저장할 수 있다.

{“greeting” : “Hello, Sexy!”}

{“age” : 26}

문서들의 값의 데이터 형과 키 값 마저 달라도 함께 저장 가능하다.

다른 구조의 문서라도 같은 콜렉션에 저장할 수 있는데, 별도의 콜렉션이 필요한 이유

같은 콜렉션에 다른 종류의 문서를 저장하는 것은 개발자와 관리자에게 매우 힘듬. 개발자들은 각 쿼리(query)가 특정 종류의 문서를 반환거나 그렇지 않다면 쿼리를 수행한 다른 구조의 문서들을 다룰 수 있는 지 확실히 해야 한다.

콜렉션 별로 목록을 뽑는 것이 한 콜렉션 내 특정 데이터형 별로 쿼리해서 목록을 뽑는 것보다 훨씬 빠르다.

같은 종류의 데이터를 하나의 콜렉션에 모아 두는 것은 데이터 지역을 위해서도 좋다.

인덱스를 만들게 되면 문서는 특정 구조를 가져야 한다. 이러한 인덱스는 콜렉션별로 정의한다.

이렇게 스키마를 생성하고 같은 종류의 문서를 모아 두는 데 합당한 이유가 있지만, 강제하지는 않는다.

2. 네이밍 naming

콜렉션은 그 이름으로 식별된다. 콜렉션 명은 몇 가지 제약 조건을 제외한 어떠한 UTF-8 문자열도 쓸 수 있다.

빈 문자열(“”)은 유효한 콜렉션명이 아니다.

콜렉션명에는 \0 (null문자)을 쓸 수 없다. 이는 콜렉션 명의 끝을 나타내는 문자이기 때문이다.

sysem.으로 시작하는 콜렉션명은 시스템 콜렉션에서 사용하는 예약어 이므로 사용할 수 없다. system.users 콜렉션은 DB의 사용자 정보를 가지고 있으며, system.namespaces 콜렉션은 DB 내 모든 콜렉션의 정보를 가지고 있다.

사용자가 만든 콜렉션은 그 이름에 예약어인 $(dollar)를 사용할 수 없다. DB가 제공하는 다양한 드라이버들이 시스템에서 생성한 콜렉션에서 $ 문자를 사용하기 때문에 이러한 콜렉션 명을 지원하기는 한다.

3. 서브 콜랙션 Sub-collection

콜렉션을 체계화하는 기존의 방법 중 하나는 서브콜렉션의 네임스페이스 .(dot) 문자를 쓰는 것이다.

human.greeting human.name

이렇게 쓰는 이유는 오직 체계화를 위한 목적이며, 관계는 없다.

비록 서브콜렉션에 특별한 속성들은 없더라도, 여러 MongoDB 툴에서 지원하므로 유용하다.

> 큰 파일들을 저장하는 프로토콜인 GridFS는 콘텐츠 데이터와 별도로 메타데이터를 저장하기 위해 서브콜렉션을 사용한다.

> 대부분의 드라이버는 특정 콜렉션의 서브콜렉션에대한 접근을 지원하는 몇 가지 문법적 편리함을 제공한다.

DB 이름에 알아두어야 할 점은, 실제 DB 이름은 파일 시스템 상에서 파일이 된다는 것이다.

또한 직접 접근할 수는 있지만 특별한 의미를 가지는 예약된 DB 이름도 있다.

2.3 데이터베이스 DB

MongoDB는 콜렉션에 문서를 그룹핑할 뿐만 아니라 DB에 콜렉션을 그룹지어 놓는다.

단일 인스턴스(instance)는 여러 DB를 호스팅 할 수 있으며, 각 DB를 완전히 독립적으로 취급한다.

하나의 DB는 자체 권한을 가지고 있으며, 따로 분리된 파일로 디스크(disk)에 저장한다.

한 애플리케이션의 데이터를 동일한 DB에 저장하는 것은 좋은 원칙이다.

DB를 나누는 방식은 하나의 MongoDB 서버에서 여러 애플리케이션이나 여러 사용자를 위해 데이터를

저장할 때 유용하다.

1. DB Naming

빈 문자열(“”)은 유효한 DB 이름이 아니다.

DB 이름은 다음 문자들을 포함할 수 없다. /,|, ., ‘’, *, >, <, :, |, ?, $, (단일 공간), \0(null)

대소문자를 구분하지 않는 파일 시스템에서도 DB 이름은 대소문자를 구별한다. 가급적 소문자를 쓰도록 한다.

DB 이름은 최대 64 바이트다.

DB 이름 규칙

2. 예약된 DB Name

admin :  이것은 인증의 관점에서 ‘root’ DB이다. 만약 admin DB에 사용자를 추가하면,

해당 사용자는 자동으로 모든 DB에 대한 사용 권한을 상속받는다. 모든 DB 목록을 조회하거나,

서버를 중지하는 등 서버 전역에 걸쳐 실행하는 명령어들을 오직  admin DB에서만 실행 가능하다.

local : 절대로 복제되지 않기 때문에 특정 서버에만 저장하는 콜렉션에 사용된다.

config : MongoDB를 샤딩 설정하는 경우, 내부적으로 샤드 정보를 저장하는데 사용된다.