MONGODB 정리 - NoSQL & mongoDB 주종면

MONGODB 정리

교제 : NoSQL & mongoDB 주종면

1장. : NoSQL 개념.

NoSQL

비관계형 SQL

NoSQL 의 장점

1. 클라우드 환경에 적합.

- 하드웨어 확장에 유연한 대처가 가능

- 분산 처리와 병렬 처리가 가능

2. 유연한 데이터 모델

- 비정형 데이터 구조설계로 설계 비용 감소

- 관계형 데이터베이스의 Relationship과 Join 구조를 Linking과 Embedded로 구현하여 성능이 빠르다 

3. Big Data 처리에 효과적이다

- Memory Mapping 기능을 통해 Read/Write가 빠르다 

- 기존 rdb와 동일하게 데이터 처리가 가능하다.

2장. MongoDB 설치 및 데이터 처리

MongoDB 주요 특징

JSON Type의 데이터 저장 구조

Sharding/Replica 기능 제공 ==> 쓰기와 관련

MapReduce(분산/병렬처리) 기능 제공 ==> 읽기와 관련

CRDU 위주의 다중 트랜잭션 처리 가능하다

Memory Mapping 기술을 기반으로 Big Data 처리 ==> 캐싱 기법을 통해 빠르게 처리.

RDBS 와 MongoDB 구조 비교

RDBS : TABLE > ROW > COLUMN > RelationShip

MONGODB : Collection > BSON Document > BSON Field > Embedded & Linking

BSON (Binary Serial Object Notation)

경량의 데이터 교환 형식인 JSON 타입을 근거로 하며 사람이 읽고 쓰기에 용이하며 기계가 분석하고 생성하기에 용이함.

MongoDB Collection 특징

비정화되어 있기 때문에 Collection 을 만들 때 field를 미리 정하지 않는다. 데이터를 어떻게 넣느냐에 따라 Document 의 Field가 정해진다.

두 가지 Collection 생성 방법.

1. insert를 하면 해당 Collection이 없으면 자동으로 만든다.

2. createCollection

- capped : 지정된 사이즈를 다 쓰면 처음의 영역부터 다시 쓴다.

- None capped : 지정된 사이즈를 다 쓰면 새로운 저장 공간을 만들어서 Collection이 커진다. 

- size : 해당 Collection의 최초 생성 크기

MongoDB 데이터 타입

데이터 field 타입이 18가지가 있다.

Long, Object, String, 32bit Integer, 64bit Integer, Object Id, javascript, Array, Boolean, Date, Timestamp, Symbol, ...

Javascript 함수

비 저장형, 저장형이 있음.

Sequence Number 타입

실제로는 없지만 function을 만들어서 사용 할 수 있다.

MongoDb sequence number example code : 

function seq_no(name) {

    var ret = db.seq_no.findAndModify({

        query: {

            _id: name

        },

        update: {

            $inc: {

                next: 1

            }

        },

        "new": true,

        upsert: true

    });

    return ret.next;

}

MongoDB 연산자 : : $가 앞에 붙는다.

비교 연산자 : cmp, eq, gt, gte, lt, let, ne, in, nin

Boolean 연산자 : or, and, not, nor (주어진 모든 조건이 false 일 때 true)

산술연산자 : add, devide, mod, multiply, subtract

문자 연산자 : strcasecmp, substr, toUpper, toLower

날자 연산자 : dayOfMonth, dayOfWeek, dayOfYear, hour, minute, week 등

다중 표현 연산자 (두 개 이상의 필드를 비교 - 다중 필드를 비교함.) : ifNull, cond: boolean-express, true-case, false-case

변경 연산자 : 업데이트, 추가, 제거 

연결 연산자  : skip, limit, first, last 등.

MongoDB insert, save, update 차이점

- insert : 추가

- save : _id의 값을 기준으로 있으면 update, 없으면 insert 

- update : 특정 필드만 업데이트

MongoDB link 

약한 결합을 가지고 있어서 매번은 아니지만 가끔 참조되는 데이터이기 때문에 Collection 을 분리하고 ObjectId를 field 값으로 넣어준다. RDB의 Join과는 다르다. _id를 가지고 와서 그 것이 index가 걸려 있으므로 한 번 더 쿼리 할 뿐이다.

MongoDB 상속

ex)

CAR : 엔진, Frame, Tire

BUS : 엔진, Frame, Tire, Auto-Door

TAXI : 엔진, Frame, Tire, Lamp, Gas_Tank

이런 데이터라면 공통적으로 엔진, Frame, Tire가 있다.

몽고디비는 상속이 안 된다. 비정형화된 데이터 타입이기 때문에 한 document에 다른 field를 사용해서 표현하면 된다.

ex)

Collection : car

_id	type
0	bus	엔진	Frame	Tire	Auto-Door
1	taxi	엔진	Frame	Tire	Lamp	Gas_Tank

계층형 데이터 구조

어렵네... 이건 잘 안될 듯.

document에 PARENT, ANCESTOR 필드를 추가해서 표현. tree 구조가 복잡하면? 우짤라고?

5장. 논리적 구조 & 물리적 구조

MongoDB 설치를 하면 3가지 공간이 만들어짐

1. 메모리 공간, 

2. 프로세스 영역, 

3. 데이터 관련 영역.

콜렉션을 만들면 .NS, .0, .1 파일들이 생긴다.

ex) SLAES.NS, SALES.0, SALES.1, ...

NS 파일은 NAMESPACE 파일로 메타정보가 들어가고, 실제 데이터는 .0, .1 데이터 파일에 들어가게 된다.

최초 16MB 이며 최대 2GB까지 된다.

복구를 위한 Journal 파일은 최초 1GB 크기로 만들어진다.

MongoDB 논리구조

Database > Collections > Extents > Data Records  > Documents

db.collectionsName.validate() 하면 정보를 볼 수 있다.

MongoDB 메모리 공간

Resident Area{Working Set이라 함.} 와 Virtual Memory Area(Mapped Cache Area, Virtual Area, Journal Area) 로 구성됨.

MongoDB 디스크 공간

Mapped(Data) File에 60s 마다 동기화 함. Journal(Data) File에 100ms 마다 100MB를 백업함.

메모리 공간이 필요하다. 충분한 메모리 공간이 반드시 필요하며 디스크 IO가 빈번하다.

MongoDB 적정 메모리 요구 사항

1. MongoDB는 Memory Mapped File 기법에 의해 데이터 처리하기 때문에 최초 메모리 크기는 생성되 는 Namespace와 Data-File에 맞는 적정한 Mapped Area 크기가 요구된다.

(64 Bit, 최초 Namespace 16MB+첫 번째 Data-File 64MB x 2의 가상 메모리 공간)

메모리 맵 파일 : 메모리 맵 파일을 통해 프로세스의 가상 메모리 주소 공간에 파일을 매핑한 뒤 가상 메모 리 주소에 직접 접근하는 것으로 파일 읽기/쓰기를 대신한다.

2. 사용자의 데이터를 위한 Virtual Memory와 함께 MongoDB 서버를 원활하게 운영하기 위한 Resident Area(Working Set)가 요구된다.

이 공간은 서버에 의해 동적으로 할당되며 PageFault가 발생하면 커진다. - Page Fault : 자주 사용되는 데이터를 Page 단위로 메모리에 올려(Workin Set)서 사용하는데, 필요로한 데이터가 Working Set에 없어서 디스 크 IO가 발생하는 것을 Page Fault라고 한다.

3. Mapped File 크기가 2GB인 경우(최대 크기를 기준으로 본다.) 요구되는 RAM 메모리는 약 10GB~12GB 정도가 요구된다. SYSTEM 메모리가 부족한 경운 Page Fault가 발생하여 성능 저하 현상이 발생할 수 있다.

MongoDB Journaling File

1. 사용자 데이터의 유실을 방지하기 위해 별도의 파일에 저장한다.

- --dbpath 로 정의된 경로의 journal 경로에 생성된다.

- 기본 크기는 1GB(Prealloc.0, Prealloc.1 형태로 저장)

2. Memory Map에 저장하기전에 Journaling File에 먼저 저장한다.

3. 기본적으로 매 100ms 마다 100MB를 저장한다.

- mongod를 구동할 때 --journing[CommitInterval]을 정의할 수 있으며 2ms~300ms 범위에서 정의 할 수 있다.

4. Journal 모드가 요구되는 경우

- Single Node : Data의 무결성을 보장하기 위해서 반드시 필요하다.

- Replica Set : 최소 1 Node에 정의해야 한다.

5. 반드시, 데이터 파일과 분리된 물리적 디스크에 생성해야 디스크가 물리적인 결함이 발생했을 때 복구가 가능하다.

MongoDB Lock 정책.

Global/Database/Collection/Page lock 기능을 제공한다. Document-lock은 아직 적용 안된다.(3.4 버젼)

MongoDB PageFault & LRU 알고리즘

Resident Area(Working Set)에 자주 사용하는 데이터를 올려 놓고 사용한다. LRU 알고리즘에 의해서 한 정적인 공간을 관리한다.

MongoDB GRIDFS(GRID FILE SYSTEM) 기능

OS 상에 있는 바이너리 파일을 포함한 다양한 파일을 MongoDB 내에 저장할 수 있다. 압축하기 때문에 크기를 많이 줄일 수 있다.

MongoDB Extent : 데이터가 저장되는 논리적인 단위.

- 하나의 Extent에 얼마나 적절하게 데이터를 잘 저장하느냐가 읽기/쓰기에 있어 성능을 좌우하는 요소가 된다.

- 처리될 데이터에 비해 너무 작게 만들어지면 새로운 Extent를 활성화 시키는 횟수가 비번해지면서 성능 저하가 올 수 있다.

- 하나의 Data Record는 하나의 Document 정보와 이전/이후 Document 주소가 함께 저장된다. 

- Extent 는 여러개의 Data Records를 가지고 있고, 이전/이후 Extent의 주소를 가지고 있다.

6장. Sharding System : 하나의 콜렉션을 여러개의 샤딩으로 분리.

Sharding의 가장 큰 목적은 파티셔닝을 통한 데이터 분산 처리와 성능 향상을 위한 Load Balancing이다. 빅 데이터의 효율적 관리와 백업 및 복구 전략 수립을 위한 솔루션이기도 한다.

MongoDB 샤딩의 목적

1. 데이터의 분산 저장

- 하나의 서버가 아니라 여러 대의 서버를 통해 분산 처리 하여 빅 데이터를 디스크에 저장할 때 발생하는 Write Scaling 문제에 의한 성능 저하를 방지한다. 

2. 빠른 성능

- 여러 개의 프로세스가 여러 개의 cpu를 통해 작업을 진행했을 때 가장 이상적인 작업이 된다. 

3. 데이터의 백업과 복구 전략의 일환

- 데이터의 분산 저장을 통한 시스템 성능 향상.

MongoDB 샤딩 구축 방법

- 3대의 샤드 서버와 2대의 config 서버.

1. mongod - 샤드 서버 활성화 with port(서버 3대)

2. mongod - config 서버 활성화 with port(서버 2대)

3. config 서버에서 mongos 에 샤드 서버 ip:port 등록 with port

4. mongos에 config server ip:port 등록

5. 중간에 shard 추가가 가능하다.

6. shard key 가 성능에 중요한 영향을 끼친다. 카디널리티가 높지도 낮지도 않은 적당한 field를 선정하는 것이 중요하다. 카디널리티가 낮다는 것은 분산이 넓게 분포한 것을 의미하고, 높다는 것은 분산이 좁다는 것을 의미한다. 예를 들어 사원번호는 카디널리티가 낮고 성별은 높다. 100명 중에 남자가 30명이면 카디널리티는 0.3 이 된다. shard key를 기반으로 데이터를 각 shard에 분산시키므로 적절한 shard key 선정이 중요하다.

MongoDB Chunk(청크)

여러 개의 샤드 서버가 있을 때 하나의 서버에만 데이터가 쌓인다면 쓰기 지연 현상이 발생하는데, 이런 경우를 위해 하나의 서버에 저장되는 데이터들을 여러 개의 논리적 구조로 분할 저장 해 두었다가 일정한 데이터 양 에 도달했을 때 두 번째, 세 번째 서버로 분할 데이터의 일부를 이동 저장하는데 이 분할 단위를 Chunk라고 한다.

Chunk 크기에 따라 다른 서버로 빈번하게 데이터가 전송 될 수도 있고 그렇지 않을 수도 있기 때문에 데 이터의 양에 따라 적절한 튜닝이 필요하다.

7장. Replica & ReplicaSets : 복제기능

실시간으로 원본 데이터를 다른 노드에 복제한다.

MongoDB 복제 방법

1. 마스터 / 슬레이버 방법

관계형 데이터 베이스에서도 볼 수 있는 보편화된 방법

마스터에 데이터가 업데이트 될 때 마다 슬레이브 서버들에게 데이터를 전송해 동기화 한다. 슬레이브가 문제가 생겼을 때는 마스터를 통해 자동 복구되지만 마스터가 문제가 생겼을 때는 메뉴얼한 방법으로 직접 복구해야 한다.

최대 16대까지 슬레이브 서버를 설정 할 수 있다.

2. 리플리카 셋 방법

프라이머리 서버/세컨더리 서버

프라이머리 서버에만 read/write 가 가능하고 secondary server에서는 read만 가능하다.

Primary server가 문제가 생기면 Secondary server 중 하나가 자동으로 Primary 서버가 되어서 read/write가 가능하다.

OpLog 를 통해서 백업 후 동기화 한다.( Journal 과 같은 기능이네...)

리플리카 셋을 하면 자동으로 Primary server가 죽었을 때 자동으로 Secondary server 중 하나가 선출을 통해서 Primary server가 되므로 마스터/슬레이브 방식보다 장애 발생시 유용하다. 

선출 방법.

1. 설정된 우선 순위에 의한 방법.

2. Arbiter Server에 의한 방법. (Arbiter는 어떤 기준으로 정하지???)

리플리카 셋을 만들 때 동일한 리플리카 셋 이름을 가지고 있어야만 한다.

8장. 성능 튜닝

1. 디자인 튜닝 : 성능 저하의 가장 큰 원인은 데이터를 저장하는 논리적 구조인 컬렉션에 대한 적절한 분석과 설계 작업이 안되어서다.

2. 문장 튜닝(Stagement Tuning): 쿼리 문장이 잘못 작성되어 성능이 저하.

3. 아키텍처 튜닝(Architecture Tuning) 

4. 인스턴스 튜닝(Instance Tuning)

5. 하드웨어 튜닝(Hardward Tuning)

: 샤딩 시스템, 리프리카 셋 등이 잘 못 됨. : 충분한 메모리 영역이 안됨.

: 하드웨어 문제.

MongoDB 디자인 튜닝

대용량 데이터의 Full Scan이 자주 발생하는 경우 Extent가 클 수록 유리

Indexed Scan이 자주 발생하는 경우 Extent가 작을 수록 유리.

Collection들이 강한 연관관계를 맺고 있으면 Embedded나 Extent Document로 되어야 함. 

Compound Index를 잘 설계 해야 함.

- 빅데이터의 저장인 경우 Background Index의 사용을 권장 함.

- find 조건으로 사용되는 필드 들

- 분포도가 넓은 필드

- 데이터 양이 적은 필드

- Equal 조건으로 검색되는 필드. ex) db.user.find({userNo:1234}). &in이나 $gte, $lte가 아닌 애들.

MongoDB 문장 튜닝.

- 쿼리의 검색 결과(데이터가 아님)는 db.system.profile에 일정시간 동안 저장 됨. 여기서 조건으로 검색 이 가능 함. 

ex) db.system.profile.find({miliis:{$gt:5}})

- Full Scan 되는 쿼리.

- Index Key는 되도록 insert, update, delete가 안 이루어지는 것으로 설정. 

- 빠른 Update를 위해서는 충분한 크기의 Extent가 필요.

- 빠른 인덱싱을 위해서는 Background Index를 고려.

MongoDB 아키텍처 튜닝

Replica Set과 비즈니스 영역 분리.

하나의 Instance 보다는 Shard Clusters를 적극 활용하여 분산 처리

- 추가/삭제가 쉽다.

Secondary 데이터 베이스는 Backup과 Reports 활동 중지.

- Secondary는 실시간으로 Primary의 데이터를 복제하므로 다른 작업 시키면 느려진다. => Primary에서 하는 것이 좋다.

하나의 서버에는 하나의 Mongod 인스턴스만.

- MongoDB는 많은 메모리를 사용하므로

- 디스크 IO 속도

Lock Time 확인하여 튜닝 필요.

MongoDB 인스턴스 튜닝

1. 문장 튜닝 우선.

2. 최적화된 read/write 우선.

3. Data Locality(인접성)이 높아지도록 설계 및 저장.

Resident Area가 시스템 전체 메모리 영역의 90% 이상을 점유하게 되면 메모리를 추가로 확장해야 함. 피크 타임에도 7~80%가 적절.

특정 field를 수정하는 것이라면 save 보다는 update가 적절.

MongoDB 하드웨어 튜닝. 

- SSD 써라.

충분한 메모리가 필요하다. 왜냐하면 메모리 매핑 기술을 사용하기 때문에 메모리에서 많은 작업들이 이 루어진다. 데이터 파일 1개가 2GB라면 메모리는 10~12GB가 필요하다.

다중 CPU 사용하세요.

샤딩 시스템 구축으로 분산 처리 하세요.

mongopref 유틸리티를 통해서 Disk-IO 확인 가능.

9장. MonboDB 백업/복구 & 유틸리티 백업 유형

- Shutdown & File Backup

- FsyncLock/FsyncUnLock & Backup

- Snapshot Backup (Journaling)

- MongoDump

- MongoExport

- Master/Slave Replica Backup(OpLog)

MongoDB 복구 유형

- Shutdown & File Recovery

- CopyDatabase / CloneDatabase - Snapshot Recovery (Journaling) - MonboRestore

- MongoImport

- Replica Set Recovery (OpLog)

MongoDB 백업 유형

Shutdown & File Recovery

빅 데이터를 저장하고 있는 데이터 파일을 운영체계에서 복하는 방법. 물리적 복사. 가장 간편한 방법이지만 복사하고 있는 동안에는 서비스를 할 수 없음

FsyncLock/FSyncUnlock & Backup

데이터베이스를 종료하지 않고 온라인 상태에서 데이터 파일들을 복사하는 방법. 백업 도중 무결성이 깨 질 수도 있기 때문에 FsyncLock 명령어를 통해 lock 한 뒤 복사 후 unlock 해야 함.

Snapshot Backup

입력/수정/삭제 작업 발생할 때 다양한 장애로 인해 데이터 유실이 발생할 수 있음. 이를 방지하기 위해 Journal 기능을 통해 사용자가 입력/수정/삭제한 데이터는 데이터 파일에 저장되기 전에 메모리 상에서 저널 파일에 먼저 백업되고 이후에 데이터 파일에 저장되도록 설계. 장애가 발생하더라도 저널 파일의 백업 데이터를 이용하여 데이터 복구 가능. 이를 Snapshot 백업이라 함.

MongoDump

데이터를 데이터베이스 단위/컬렉션 단위/전체 단위로 BSON 타입의 파일로 백업할 때 사용.

MongoExport

데이터를 JSON, CSV, TSV 타입 파일로 백업하는 유틸

Master/Slave & Replica Backup

Slave 나 Replica Set 형태로 백업하는 것.

MongoDB 복구 유형.

Shutdown & File Backup

MongoDB 종료 후 파일 단위로 OS에서 복사하는 방법.

Copy Database/Clone Database

MongoDB 에서 제공하는 명령어를 통해 존재하는 데이터베이스와 똑 같은 구조로 복사하고 백업할 수 있 고 복구 할 수 있는 방법. CopyDatabase는 Local DB 내에서 DB를 복사하는 방법이라면 Clone Database는 Remote DB 를 Local DB로 복사할 때 사용하는 방법

MongoRestore

MongoDump에 의해 생성된 BSON type의 백업 데이터를 MongoDB로 복구할 때 사용.

MongoImport

MongoExport 에 의해 백업된 JSON, CSV, TSV 타입의 파일 데이터로 복구 할 때 사용.

ReplicaSets Recovery

Primary Server가 장애가 발생하였을 때 Secondary Server가 Primary 서버 역할을 수행하도록 하게 함 으로써 무정전 시스템을 구축 할 수 있는 방법.

MongoDump & MongoRestore : 가장 대표적인 백업&복구 유틸. 3가지 모드 제공. 전체, 데이터베이스, 컬렉션.

BsonDump

MongoDump에 의해 백업된 BSON 파일 내에 어떤 데이터가 저장되어있는지 분석하는 유틸.

MongoImport & MongoExport

옵션에 따라 json, csv, tsv 로 내보내고 가지고 올 수 있다.

CopyDatabase & CloneDatabase

CopyDatabase 는 하나의 서버에 있는 대상 데이터베이스를 이름이 다른 데이터베이스 이름으로 복제할 때 사용.

CloneDatabase 는 대상 데이터베이스와 동일한 이름, 동일한 구조를 가진 데이터베이스를 복제할 때 사 용하지만, CopyDatabase는 대상 데이터베이스와 복제되는 데이터베이스의 이름이 반드시 달라야한다. 결론적으 로 CloneDatabase는 하나의 Local 데이터베이스가 아닌 remote 데이터베이스를 복제할 때 사용.

MongoDB 유틸

MongoStat & MongoTop

MongoStat : 발생하는 다양한 작업(insert, query, update, delete 등) 상태 정보와 메모리 상태

(mapped, vsize, res, faluts, locked 등) 및 기타 시스템 상태 정보를 출력해주는 유틸.

MongoTop : MongoDB 내의 모든 Collection 들에 대한 read/write 현황에 대한 상태정보를 제공하는

유틸.

Mongod를 통해 인스턴스를 활성화할 때 --rest 옵션을 사용하면 28017 port를 통해 웹브라우저로 모니 터링 상태를 볼 수 있음.

Log

--logpath 옵션을 통해 로그를 쌓아서 분석 할 수 있음.

Web Mornitoring