몽고디비교육1일차

Introduction to MongoDB
몽고디비 사용자 교육 1일차

2몽고디비 사용자 교육
http://university.mongodb.com

3몽고디비 사용자 교육
모든 자료는 몽고디비 docs 를 참고 하였습니다.
http://docs.mongodb.org/

순서
1. 개요
2. 몽고디비 데이터 모델
3. 몽고디비 쿼리
4. 배포 아키텍쳐
5. 디자인 철학
6. QnA
4

1. 개요
6
MongoDB는 고성능, 고가용성, 쉬운 확장성을 제공하는 문서 데이터베이스.
Document Database
High Performance
High Availability
Easy Scalability
- 다큐먼트는 프로그래밍 하기 좋은 데이터 타입입니다
- 내장 다큐먼트와 배열은 join 의 필요성을 낮춰 줍니다.
- 동적 스키마는 다형성을 더 쉽게 합니다.
- 내장형태(Embedding)문서 형태는 읽기와 쓰기를 빠르게 합니다.
- 인덱스는 문서와 배열에 포함된 키를 포함 할 수 있습니다.
- 감사 없는 빠른 쓰기
- 자동 failover 와 복제 서버 구성이 가능
- 자동 샤딩은 컬렉션 데이터를 전체 장비에 배포합니다.
- 결국 일관성있는 데이터 읽기가 복제된 서버들에서도 가능합니다.

7

8
일단 미리 준비된 몽고디비에 접속 하겠습니다.
화면은 robomongo 라는 몽고디비 클라
이언트라는 도구(무료)를 화면 캡쳐 하였
습니다.
다운로드 : http://www.robomongo.org/

9
몽고디비 서버는 여러개의 데이터베이스를 가질수 있습니다.
데이터 베이스 목록 입니다

10
데이터베이스는 여러개의 컬렉션을 가질수 있습니다.
- test 데이터베이스의 컬렉션 (book,room,users) 입니다.
- Oracle , Mysql 의 테이블과 비교 될 수 있습니다.

11
컬렉션은 여러개의 다큐먼트를 가질수 있습니다.
- book 이라는 이름의 컬렉션의 데이터들 입니다.
- 현재는 2개가 들어 있습니다.
- 각각의 데이터는 다큐먼트(document) 라고 불립니다.
- 다큐먼트는 RDBMS 내의 튜플 또는 레코드와 비교 됩니다.

12
다큐먼트는 여러개의 key,value 로 구성 되어 있습니다.
- key 들입니다. (_id,name,price,company)
- RDB 테이블의 컬럼과 비교 됩니다.
- field 라고도 불립니다.

13
다큐먼트는 여러개의 key,value 로 구성 되어 있습니다.
- value 값들입니다. 각 key 들의 값입니다.
- RDB 테이블의 컬럼 값과 비교 됩니다.

14
다큐먼트안에 정보 저장을 자유롭게 할수 있습니다 - 같은 key 다른 형태
Object !!
String

15
다큐먼트안에 정보 저장을 자유롭게 할수 있습니다 - 같은 컬렉션 다른 포멧
유일하게 보유
Schemaless !!
어플리케이션이 튜플(다큐먼트)의 속성및 구조를 결정합니다.

16
정리
1. 몽고디비 서버는 여러개의 데이터베이스를 가질수 있습니다.
2. 데이터베이스는 여러개의 컬렉션을 가질수 있습니다.
3. 컬렉션은 여러개의 다큐먼트를 가질수 있습니다.
4. 다큐먼트는 여러개의 key,value 로 구성 되어 있습니다.
5. 다큐먼트안에 정보 저장을 자유롭게 할수 있습니다
- 같은 key를 가지고 있지만 다큐먼트 별로 다른 형태의 자료일수 있습니다.
- 같은 컬렉션내에 있지만 구조가 다를수도 있습니다.
즉, 모두 같은 필드 같은 속성임을 강요 하지 않습니다

18
SQL 이 없는 몽고디비 질의는?
SQL VS NATIVE VS METEOR

19
INSERT
SQL INSERT
insert into book (name ,price ,company )
values ("미티어 코딩공작소” , 30000 , "길벗” )
db.book.insert({name : "미티어 코딩공작소” ,price : 30000 ,company : "길벗"});
MONGO NATIVE INSERT
/* Declare meteor collection */
Book = new Mongo.Collection(“book”);
/* How to use */
Book.insert({name : "미티어 코딩공작소” ,price : 30000 ,company : "길벗"});
METEOR API

20
SELECT VS FIND
SQL SELECT
select name, price, company from book where name = “미티어 코딩공작소”;
db.book.find( {name : "미티어 코딩공작소”} , { name : 1, price : 1, company : 1} );
MONGO NATIVE FIND
METEOR API
Book.find({name : "미티어 코딩공작소”} , fields : {name : 1 price : 1, company : 1});

21
UPDATE
SQL UPDATE
update book set price = 35000 where name = “미티어 코딩공작소”
db.book.update({name : "미티어 코딩공작소”} , {$set {price : 35000} );
MONGO NATIVE UPDATE
Book.update({name : "미티어 코딩공작소”} , {$set {price : 35000} );
METEOR API

22
DELETE vs REMOVE
SQL UPDATE
delete from book where price > 20000
db.book.remove({ price : { $gt : 14 } });
MONGO NATIVE UPDATE
Book.remove({ price : { $gt : 14 } });
METEOR API

4. 배포 아키텍쳐
레플리카세트(복제)와 샤드(분할)
23

4. 배포 아키텍쳐 – 레플리카(복제)세트
24
레플리카 세트란? – 다수 서버간 데이터 동기화 프로세스
1. 목적
- 데이터의 여분을 복제 함으로써 단일서버의 위험성을 방지 합니다.
- 하드웨어 에러의 경우에도 정지 없는 서비스를 가능하게 합니다.
- 여러 카피의 데이터는 재난복구, 리포팅, 백업등의 용도로 유용합니다.
2. 몽고디비의 복제
- 복제세트란 mongod 인스턴스의 그룹으로서 같은 데이터를 유지 합니다.
- Primary는 어플리케이션으로 부터의 모든 write 작업을 허용 합니다.
- 복제를 위하여 Primary 는 oplog 라는 로그를 남기고 Secondary 가 해당
로그를 통하여 데이터를 동기화 합니다.
3. 비동기 , 자동 failover
- 복제는 비동기로 이루어 지며 , 장애시 적절한 서버를 찾아 Primary 로 선
출 하여 무정지 시스템을 구현 합니다.

25
레플리카 세트의 요소 - Primary
유일한 맴버
- Primary 는 복제세트 내에 유일한 맴버로 모든 write 를 책임집니다.
oplog 발생 : 오퍼레이션 로그 기록
- Primary 는 insert , update , remove 의 모든 결과를 oplog 에 기록합니다.
- 기록된 결과는 반영된 다큐먼트의 갯수 만큼 쌓이게 됩니다.
- system 데이터베이스에 oplog.rs 라는 capped 컬렉션에 쌓습니다.
투표를 통한 선택
- 복제세트 내에 있는 모든 맴버들은 1개의 투표권을 가지며 서로간의
heartbeat 을 통하여 상대 맴버의 존재 유무를 판단하며 Primary 가 응답
하지 않을경우 Secondary 중 다른 맴버를 Primary 로 선택합니다.

26
레플리카 세트의 요소 - Secondary
“Priority 0” 맴버
- 복제세트 내에서 결코 Primary 가 되지 않는 Secondary 입니다.
- 오로지 read 만 가능한 맴버로서, 투표권을 가집니다.
지연복제 맴버 (“Priority 0” 필수)
- 동기화 기간을 조정할 수 있습니다.
- ETL 의 원본으로서 사용 할수 있습니다.
* 복제를 전송 용도로 사용
“hidden” 맴버
- 어플리케이션에서 감지 되지 않는 맴버입니다.
- 백업이나 리포팅 전용으로 사용합니다.
Arbiter
- 투표만 가능한 맴버
- 다수의 데이터 센터일 경우 유용

4. 배포 아키텍쳐 - 샤드
27
샤드란 무엇인가?
컬렉션은 다큐먼트들의 집합입니다.
이 집합은 기본적으로 한개의 디비 인
스턴스가 관리 합니다.
또한, 필요에 따라 몇 개의 인스턴스를 추
가하여 여러개의 인스턴스가 공동 관리
하도록 할 수 있습니다. 이것을 샤드라고
합니다.
이때 컬렉션의 다큐먼트들은 샤드키에 의
하여 여러 샤드들이 관리 할수 있게 됩니
다. 즉, 각각의 인스턴스(샤드)들은 컬렉
션의 부분집합을 관리합니다.

28
샤드키란?
컬렉션을 샤딩 하기 위해서는 샤드키가 필요합니다.
1. 샤드키는 인덱스 필드이거나 인덱싱된 복합 필드여야 합
니다. 또한,
2. 모든 다큐먼트들이 필수로 가지고 있어야 하는 필드 입니
다.
그림은 범주(Range) 기반
의 샤드키 입니다.
그림은 해시(Hash) 기반
의 샤드키 입니다.

29
샤드의 요소
샤드 : 몽고디비 인스턴스로서 각 샤드는
컬렉션의 부분집합을 관리 합니다. 운영
환경에서 각샤드는 레플리카셋이어야 합
니다.
컨피스서버 : 몽고디비 인스턴스로서 메
타데이터를 관리합니다. 운영환경에서는
3개의 인스턴스로 구성합니다.
라우터 : 또는 라우팅 인스턴스라고
하며 어플리케이션에서 데이터를
다루는 접점입니다. 관리 목적이외
에는 직접 샤드에 접속 하지 않습니
다.

30
Shard
(mongod)
Shard
(mongod)
Shard
(mongod)
Shard
(mongod)
Shard
(mongod)
Shard
(mongod)
Shard
(mongod)
Shard
(mongod)
Router
(mongos)
Router
(mongos)
Config
(mongod)
Config
(mongod)
Config
(mongod)
Shard
(mongod)
Shard
(mongod)
Shard
(mongod)
Shard
(mongod)
Router
(mongos)
Arbiter
Ideal Architecture
4. 배포 아키텍쳐 - 구성 예
Arbiter
Driver
Application

MongoDB wasn’t designed in a lab. We built MongoDB from our own experien
ces building large scale, high availability, robust systems. We didn’t start from
scratch, we really tried to figure out what was broken, and tackle that.
So the way I think about MongoDB is that if you take MySql, and change the d
ata model from relational to document based, you get a lot of great features: e
mbedded docs for speed, manageability, agile development with schema-less
databases, easier horizontal scalability because joins aren’t as important.
There are lots of things that work great in relational databases: indexes, dyna
mic queries and updates to name a few, and we haven’t changed much there.
For example, the way you design your indexes in MongoDB should be exactly t
he way you do it in MySql or Oracle, you just have the option of indexing an e
mbedded field.
—Eliot Horowitz, MongoDB CTO and Co-founder

몽고디비는 연구소에서 만들어 지지 않았습니다. 대규모, 고가용성, 강력한 시스템
을 구축한 우리의 자신의 경험을 기반으로 몽고디비를 만들었습니다.
우리는 문제 대처만을 위해 노력 하지 않았습니다. 처음부터 다시 시작하고, 정말 고
장이 있었는지 알아 내기 위해 노력했습니다.
제가 생각하는 몽고디비는 이렇습니다. 만약 mysql 을 사용하는 사용자가, 데이터모
델을 관계형에서 다큐먼트기반으로 변경하고자 한다면 , 괜찮은 많은 특징들이 있습
니다. 속도를 위한 내장 다큐먼트, 스키마리스 디비를 기반으로한 애자일 개발방법,
join 이 중요 하지 않기 때문에 할수 있는 수평적 확장등이 있습니다.
관계형 데이터 베이스세상에도 훌륭한 것들이 많습니다. 인덱스, 동적 질의, 최소의
수정등. 이런것들은 몽고디비도 수용 하고 있습니다. 예를 들어, 몽고디비로 인덱스
를 구성한다면 그 방법은 mysql 이나 oracle 과 같습니다. 내장 필드에 대한 인덱싱
만 좀더 생각해 주면 됩니다.
-엘리엇 호로비츠, MongoDB의 CTO이자 공동 설립
자

몽고디비교육1일차

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à 몽고디비교육1일차

Similaire à 몽고디비교육1일차 (20)

Plus de seung-hyun Park

Plus de seung-hyun Park (8)

Dernier

Dernier (6)

몽고디비교육1일차