일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- No SQL
- c++
- 빅 데이터
- 빅 데이타
- R
- 김양재 목사님
- Artificial Intelligence
- 몽고디비
- 통계
- 빅데이타
- 김양재 목사
- nodeJS
- 데이터 과학
- 빅데이터
- WebGL
- 인공지능
- MongoDB
- Big Data
- 주일설교
- 딥러닝
- data science
- 우리들교회
- node.js
- 확률
- openCV
- 김양재
- probability
- Deep learning
- Machine Learning
- Statistics
- Today
- Total
Scientific Computing & Data Science
[MongoDB] Capped Collections 본문
by Geol Choi |
지금까지는 데이터가 추가되거나 삭제될 때 저장 사이즈가 동적으로 변하는 컬렉션에 대하여 다루어 왔다.
MongoDB는 저장 사이즈가 고정된 다른 유형의 컬렉션을 제공하는데, 이 컬렉션을 "Capped Collections"라고 한다. 가장 큰 특징 중 하나는 "aging-out"으로써, Capped collections는 도큐먼트가 저장되는 순서 그대로 저장되며 만약 저장소("queue"라고 함)가 가득 차 있을 경우 가장 오래된 도큐먼트를 삭제하고 새로운 도큐먼트를 저장한다.
따라서, 저장소의 모양을 다음과 같이 형상화 할 수 있다:
[그림 1] 새로운 도큐먼트는 queue의 맨 마지막에 들어온다.
[그림 2] queue가 가득차게 되면, 최고(最古)의 도큐먼트는 최신(最新)의 도큐먼트로 대체된다.
Capped Collections에 대해 수행할 수 없는 연산이 두 가지 있다:
- 도큐먼트를 삭제할 수 없다. 단, 도큐먼트가 삭제되는 경우는 "aging-out"에 의해서이다.
- 도큐먼트를 위치를 이동시키는 "update" 연산을 수행할 수 없다. 일반적으로 "update"는 도큐먼트의 사이즈를 증가시킨다.
위의 두가지 연산 기능을 막음으로써 Capped Collections는 도큐먼트가 들어오는 순서와 저장 순서를 일치시킬 수 있다.
이외에도 "보통의" 컬렉션과 다른 점은, 기본적으로 할당되는 Index가 Capped Collections에는 할당되지 않는다는 점이다. 즉, "_id"가 존재하지 않는다.
특성 및 사용예
Capped Collections의 몇 가지 대표적인 특성을 정리하면 다음과 같다:
- 도큐먼트의 삽입(Insertion) 속도가 매우 빠르다.
- 전체 저장소(Queue) 크기를 지정하고 사용하므로 추가적인 공간이 요구되지 않는다.
- 서버가 새로 입력되는 도큐먼트를 저장할 공간을 탐색할 필요가 없다. 왜냐하면, 새로 입력되는 도큐먼트는 언제나 queue의 맨 마지막에 위치하게 되기 때문이다.
- 도큐먼트의 삽입 속도도 매우 빠르지만, 도큐먼트를 불러내는 속도도 매우 빠르다.
- "find" 연산은 항상 도큐먼트 삽입 순서에 따라 결과를 반환한다.
Capped collections의 용도는 주로 로깅(Logging)에 있다. 왜냐하면 "Aging-out" 및 삽입 순서에 따른 정렬은 이러한 로깅 기능에 적합하기 때문이다. 이를 증명하는 것이, 초반에 Capped Collections가 개발되는 우선적 목적은, 내부 "대체 로그"(replication log, MongoDB의 패일오버(Failover)에 따른 다른 DB서버로 대체)인 "oplog"(이 곳을 참고)에 사용하는 것이었다.
따라서, 이러한 특수목적에 맞춰 설계된 만큼 이러한 목적에 필요없는 기능을 제거하여 속도를 높인 것이라고 생각하면 된다.
apped Collections를 생성하기 위한 명령은 "createCollection"이며, 이 명령의 프로토타입은 다음과 같다:
> db.createCollection(name, {capped: <Boolean>, autoIndexId: <Boolean>, size: <number>, max <number>} )
파라미터를 살펴보면 다음과 같다:
파라미터 |
타입 |
설명 |
name |
string |
생성할 도큐먼트의 이름 |
options |
document |
컬렉션의 옵션 부여 |
"options"에는 다음과 같은 필드들이 존재한다.
필드 |
타입 |
설명 |
capped |
boolean |
capped이면 "true"를 아니면 "false"를 할당 |
autoIndexId |
boolean |
capped이면 "true"를, 그 외에는 "false"를 할당 |
size |
number |
저장 공간의 크기 지정 |
max |
number |
저장할 도큐먼트의 최대 개수 지정 |
이들 중, "size" 필드는 반드시 명시되어야 하며, "max"는 옵션이지만 명시될 경우 "size"도 반드시 명시되어야 한다.
예를 들어, 전체 저장 공간 10,000 바이트, 최대 도큐먼트 수 50개의 "my_collection"이라는 이름의 Capped Collection을 생성하려면:
> db.createCollection("my_collection", {capped: true, size: 10000, max: 50})
{ "ok" : 1 }
과 같이 입력한다.
일반적인 컬렉션을 Capped Collection으로 변환할 수 있는데 이에 대한 명령어는 "convertToCapped"이며 다음과 같이 사용한다:
> db.runCommand({convertToCapped: "my_collection", size: 10000})
{ "ok" : 1 }
위와 같이 Capped Collection으로 변환할 때 반드시 "size"가 명시되어야 함을 명심해야 한다.
소팅하기
Capped Collections의 도큐먼트 소팅(Sorting)은 매우 제약적이다. 즉, 기본 순서는 들어온 순서에 따르며, 다른 옵션으로는 단지 이를 역순으로 바꿀 수 있는 것 뿐이다.
들어온 순서에 따른 소팅은:
> db.my_collection.find().sort({"$natural" : 1})
이며, 역순으로의 소팅은:
> db.my_collection.find().sort({"$natural" : -1})
과 같이 입력한다.
'Data Science > MongoDB' 카테고리의 다른 글
[MongoDB] Database References (0) | 2014.03.10 |
---|---|
[MongoDB] GridFS (0) | 2014.03.06 |
[MongoDB] Advanced Topics / DB Commands 정리 (0) | 2014.03.04 |
[MongoDB] Aggregation / Map Reduce (0) | 2014.03.02 |
[MongoDB] Aggregation / The Basic (0) | 2014.02.16 |