NoSQL과 MongoDB

NoSQL특징

데이터간의 관계를 정의하지 않음
데이터의 스키마를 정의하지 않음(스키마가 유동적임)

MongoDB 특징

• Join이 없으므로 Join이 필요 없도록 데이터 구조화가 필요
• 데이터를 구조화해서 json 형태로 저장
• 메모리맵 형태의 파일엔진 DB이기 때문에 메모리에 의존적
• 메모리 크기가 성능을 좌우
• 스키마를 고정하지 않는 형태, 다양한 형태의 데이터 저장이 가능
• Read/Write 성능이 뛰어남
• Scale Out이 간단함

Document 데이터 모델

• 속성의 이름과 값으로 이루어진 쌍의 집합
• 속성은 문자열이나 숫자, 날짜 가능

SQL 쿼리/ MongoDB 쿼리 비교

SQL / MongoDb

MongoDB Index

• index는 DB의 검색을 빠르게 하기 위하여 데이터의 순서를 미리 정리해 두는 과정
  MongoDB는 고정된 스키마는 없지만 원하는 데이터 필드를 인덱스로 지정하여 검색결과를 빠르게 하는것이 가능
  Doucument가 추가되거나 수정될 때 Index도 새로운 Document를 포함시켜 수정

  MongoDB Idnex 주의점
  데이터가 변경될 시 Index의 순서도 재구성을 하여 Wrtie 작업 성능을 저하시킨다.

Sharding 시스템 특징

• 샤딩 시스템은 분산 처리를 통한 효율성 향상을 가장 큰 목적으로 한다.
• 가능한 성능 보장을 위해 3대 이상의 서버를 샤드로 활용하는 것을 추천한다.
• 최소 2대만 있으면 샤드 서버 구축이 가능하다.
• 샤드 서버로 운영하게 되면 기존에 한 대의 서버로 운영할 때보다 메모리를 20~30% 정도로 추가로 사용한다. (mongos와 OpLog, Balancer 프로세스가 추가로 메모리 사용)

Sharding 방식

1.Range Sharding

• key 값에 따라서 range를 나눠서 데이터를 분배
• key에 따라서 일부 데이터가 몰릴 수 있음

2.Hash Sharding

• Key를 받아 해당 데이터를 hash 함수 결과로 분배
• HotSpot을 방지하고 균등하게 분배
• 재분배를 해야하는 경우 전체 데이터를 다시 Hash value를 이용하여 분배

Config서버

1.Config 서버는 샤딩 시스템의 필수 구조

2.최소 1대가 요구되며 장애로 인해 서비스가 중지되는 것을 피하기 위해 추가로 config서버 설정이 필요

3. Config 서버는 각 샤드 서버에 데이터들이 어떻게 분산 저장됐는지에 대한 Meta Data를 저장

• Shared Meta 정보
  MongoS가 처리하는 Chunk(데이터의 단위) 단위로 된 chunk 리스트와 chunk들의 range 정보를 보유
• 분산 Lock
  Mongos 간의 config 서버와읭 데이터 통신 동기화를 위해 도입
  샤딩을 수행할 연산들에 대해 분산 락을 사용

Mongos 서버

1. 데이터를 Shared서버로 분배해 주는 프로세스 (Router-Balancer)
2. 하나 이상의 프로세스가 활성화 가능
   3.Config 서버로부터 Meta-Data를 캐싱한다.
3. MongoS는 Config Server와 연결하게 되는데, Config Server가 여러 대인 경우 하나라도 연결이 안되면 MongoS는 연결 실패처리한다.
4. MongoS내에서는 데이터를 저장하지 않으며, 다른 MongoS간 연결이 없기 때문에 데이터 동기화를 위해 config 서버를 이용한다.

Chunk

1.Collection을 여러 조각으로 파티션하고 각 조각을 여러 샤드 서버에 분산해서 정하는데, 
이 데이터조각을 Chunk라고 한다.

2.군등하게 저장하기 위해 큰 청크를 작은 청크로 split하고 청크가 많은 샤드에서는 적은 샤드로
Chucnk Migaration을 수행한다.

SHared Cluster Balancer

1. 각 Shard의 Chunk 수를 모니터링하는 백그라운드 프로세스
2. Shard의 Chunk 수가 Migration 임계치 값에 도달하면 밸런서가 shard간 chunck를 자동으로 Migration하고 shard당 동일한 수의 chunk를 유지

Sharding System 주의점

1. 하나의 Shard 서버에 데이터가 집중되고 균등 분산이 안되는 경우

   • 적절한 Shared Key를 선택하지 못한 경우 발생
   • 균등 분산이 안된다고 판단되면 Chunk size를 줄여야함

2. 샤드 크러스터의 밸런스가 균등하지 않는 경우

   • 데이터를 입력할 때 로드 밸런싱이 적절하게 수행됐지만, 사용자의 필요에 따라 특정 서버의 데이터를 삭제 또는 이동한 경우 밸런서가 깨지게됨

3. 과도한 Chunck Migration이 클러스트 동작을 멈추는 경우

   복제

   고성능 DB에서 가장 핵심이 되는 기능
   같은 데이터를 갖는 여러개의 mONGOdB서버를 설계하는 과정
   mASTER/Slave Replication

복제 동작 원리

일반 마스터-슬레이브 방식과 동일하게 쓰기는 마스터에서만 이루어짐
몽고디비에서 쓰기 연산이 실행되면 데이터 저장소와 Oplog 영역에저장
데이터 저장소는 쓰기 연산을 수행한 결과만을 저장
Oplog에는 연산 수행과 관련된 명령 자체를 타임스탬프와 함께 저장

ReplicaSet

1. DB 노드의 장애가 발생하거나, db에 문제가 발생하는 경우에도 빠르게 장애에 대응하여 복구하는 시간을 줄일 수 있는 장점
2. ReplicaSet의 가장 큰 목적은 서비스중인 MongoDB 인스턴스에 문제가 생겼을 때, ReplcaSet의 구성원 중 하나인 복제 노드가 장애 녿르를 대처하는 것
   3.어떠한 상황에서도 클라이언트와 db와의 통신은 지속적으로 동작할수 있도록 구성하는 기본적이고 물리적인 DB 설계 방식

ReplicatSet 구성원

1. Primary : 클라이언트에서 DB로 읽기 및 쓰기 작업
2. Secondary : Primary로 부터 데이터를 동기화한다.
3. Arbiter : 데이터를 동기화하지 않으면 ReplicaSet의 복구를 돕는 역할을 한다.

Primary

ReplicatSet에서 프라이머리 노드는 단 하나만 존재할 수 있다. 프라이머리만이 직접적으로 클라이언트와 정보를 주고 받기때문에 프라이머리가 장애가 발생하거나 네트워크에 문제가 발생하면 실제 레플리카셋이 구성되어 있더라도 세컨더리가 프라이머리로 올라오는 동안 실제 데이터를 읽고 쓰는 것이 일시적으로 중단된다.

Secondary

세컨더리의 가장 중요한 역할은 프라이머리 노드로부터 데이터를 동기화하고, 장애시 프라이머리로의 역할 전환이다. 프라이머리의 장애 상황에서 어떤 세컨더리 노드를 프라이머리로 올릴것인지 투표권을 가지고 있따.

Arbiter

아비터 노드의 역할은 ReplicaSet을 3대 이상의 홀수로 구성할 수 없을 시, 투표권만을 가지고 ReplicaSet을 모니터링하는 역할

ReplicaSet 특징

1. primary 서버는 세컨더리 서벌르 2초 단위로 상태를 체크하여 데이터 동기화를 위해 HeartBeat를 확인

2. hearbeat의 수신 결과, secondary 서버를 사용할 수 없는 상황이 되더라도 데이터 복제만 중단된다.

3. 만약 primary서버가 장애 상황이 된다면 ,secondary 서버를 primary서버로 만듦

4. primary가 될 수 있는 자격 조건으로는 priority와 elections 등으로 정한다.

ReplicaSet의 투표

1. 프라이머리 노드 장애 발생시 ReplicaSet의 선거방법은 ' 구성원의 과반이 동의하는 것'으로 구성되어 있음