MongoDB > 1. 소개, 장단점, 빅데이터 처리 특화, 불안정성, Sharding, Replica-Set
in Database
본 글은 SW마에스트로 멘토링 이후 별도 학습 후 작성한 글입니다.
1. 서론
1.1. 소개
- 크로스 플랫폼 도큐먼트 지향 데이터베이스 시스템
- JSON과 같은 동적 스키마형 도큐먼트(MongoDB에서는 BSON이라 함) 구조 사용
1.2. 장점
- Schema-less 구조
- 다양한 형태의 데이터 저장 가능
- 데이터 모델의 유연한 변화 가능(데이터 모델 변경, 필드 확장 용이)
- MySQL에 비해 빠른 Read/Write 성능
- Scale Out 구조
- 많은 데이터 저장 가능
- 구조 확장이 용이함
- 애플리케이션을 더 쉽고 빠르게 데이터 통합을 가능하게 함
- JSON 구조
- 직관적으로 데이터 구조 이해 가능
- 데이터 크기
- MySQL : 하나의 row의 최대 크기가 65,535 bytes
- MongoDB: 하나의 document의 최대 크기가 16MB
1.3. 단점
- 데이터 업데이트 중 장애 발생 시, 데이터 손실 가능
- 많은 인덱스 사용 시 충분한 메모리 확보 필요
- 데이터 공간 소모가 RDBMS에 비해 많음(비효율적인 Key 중복 입력)
- 복잡한 JOIN 연산 사용 시 성능제약이 따름
- 트랜잭션 지원이 RDBMS 대비 미흡
- 제공되는 MapReduce 작업이 Hadoop이 비해 성능이 떨어짐
2. 본론
2.1. 빅데이터 처리 특화
- Memory Mapped(데이터 쓰기 시에 OS의 가상 메모리에 데이터를 넣은 후 비동기로 디스크에 기록하는 방식)을 사용
- 방대한 데이터를 빠르게 처리 가능
- OS의 메모리를 활용하기 때문에 메모리가 차면 하드디스크로 데이터 처리하여 속도가 급격히 느려짐
- 하드웨어적인 특면에서 투자 필요
2.2. MongoDB 불안정성
- 데이터 양이 많을 경우
- 일부 데이터의 손실 가능성 존재 샤딩의 비정상적인 동작 가능성 레플리카 프로세스의 비정상 동작 가능성
=> MongoDB 5.0, 6.0 버전을 거듭하면서 해결됨
2.3. 샤딩
2.3.1. 샤딩이란
- 데이터를 분산하여 저장하는 개념
- 한 대의 서버에 빅데이터를 저장하게 되면 I/O가 한 대의 서버에서 일어나게 됨
- 서버 여러 대를 두고 분산 저장한다면 I/O가 여러 대에서 일어나기 때문에 효율성 향상
2.3.2. 목적
- 데이터 분산
- 데이터를 분산하여 순차적으로 저장한다면 한 대 이상에서 트래픽을 감당하기 때문에 부하를 분산하는 효과가 있음
- 백업과 복구 전략
- 미리 데이터를 분산하여 저장하면 리스크로부터 보호받고 효과적인 시스템 운영이 가능
- 빠른 성능
- 여러 대의 독립된 프로세스가 병렬로 작업을 동시에 수행하기 때문에 이상적으로 빠른 처리 성능 보장
2.3.3. MongoDB 샤딩 구성 요소
- Shard : 분산된 데이터 저장 공간
- Mongoos : 라우트 서버로 샤드 서버에게 알맞은 일을 분배함, 올바른 각각의 요청된 일을 알맞은 샤드로 라우팅하고 샤드 서버는 이(빅데이터)를 처리
- Config servers : 샤드에 대한 메타 데이터 저장(인덱싱)/관리
2.4. 레플리카 셋(Replica Set)
2.4.1. 정의
- 데이터베이스의 고가용성 환경을 위해 필요한 기능
- DB 노드의 장애가 발생하거나, DB에 문제가 발생하는 경우에도 빠르게 장애에 대응하여 복구하는 시간을 줄일 수 있음
- 자체적인 복제 기능을 지원하여 서비스 중인 MongoDB 인스턴스에 문제가 생겼을 대, 레플리카 셋의 구성원 중의 하나인 복제 노드가 장애 노드를 즉시 대체
2.4.2. 역할
- Primary : 클라이언트에서 DB로 읽기 및 쓰기 작업 수행
- 단 하나만 존재 가능
- 직접적으로 클라이언트와 정보를 주고 받음
- 장애가 발생하거나 네트워크에 문제가 발생하면 실제 레플리카셋이 구성되어 있더라도 세컨더리가 프라이머리로 올라오는 동안 실제 데이터를 읽고 쓰는 것이 일시적 중단될 수 있음
- Secondary : 프라이머리로부터 데이터를 동기화
- 장애시 프라이머리로의 역할 전환
- 프라이머리의 장애 상황에서 어떤 세컨더리 노드를 프라이머리로 올릴것인지 투표권을 가지고 있음
- 클라이언트의 읽기 작업을 복제노드로 분산시켜 DB의 읽기 부하를 줄이는 역할
- 프라이머리와 세컨더리의 동기화 시간을 즉각적이지 않기 때문에 실시간 반영이 필요한 부분에서는 적용이 어려움
- 지연된 읽기 복제 기능
- 프라이머리에 쓰기 작업을 발생하여 데이터가 생성되어도 일정시간 간격을 두고 복제
- 사람의 실수를 방지하고, 패치나 배치 작업 이후 DB를 되돌려야 하는 상황이 발생 했을때 지연된 시간만큼 원래 데이터로 복구가 가능
- 지연된 복제 기능으로 구성된 세컨더리 노드는 투표권이 없고, 장애 발생시 세컨더리 노드가 가지는 기능인 예비 프라이머리 노드의 역할을 하지 않음
- 수동으로 프라이머리로 승격 가능
- Arbiter : 데이터를 동기화하지는 않으며 레플리카 셋의 복구를 돕는 역할 수행
- 투표권만을 가지고 레플리카 셋을 모니터링하는 역할
2.4.3. Heartbeat
- 레플리카셋 구성언 사이에서 주기적으로 10초에 한 번 씩 ping을 보내 서로의 노드를 확인하는 작업
- 노드 및 DB의 장애를 파악하는 역할
- 장애가 발견되면 세컨더리 노드중에 하나를 프라이머리로 승급
- 투표권을 가진 노드들이 프라이머리로 올리게 될 노드를 결정하여 프라이머리로 승급
2.4.4. 참고
- 레플리카셋은 최소 3대 이상, 홀수로 구성원을 가지는 것을 권장
- ex) 프라이머리의 장애를 감지했을 때, 레플리카셋이 프라이머리와 세컨더리 둘만으로 구성되어 있는 경우 레플리카 셋의 다수의 멤버들이 투표를 할 수 없는 상황이 발생 -> 세컨더리는 고립된 노드로 남기 때문에 레플리카 셋이 정상적으로 동작하지 않음
- DB로 사용할 수 있는 노드가 2개로 제한되어 있는 경우 -> 다른 용도의 노드에 Arbiter를 구성해 선거권만 주면 2대의 노드로도 레플리카 셋을 구성하는 것이 가능
- 한개 노드의 장애가 발생했을 때 과반수 이상의 투표권을 가지는 노드가 존재하게 되서 세컨더리 노드를 프라이머리로 올리는 선거인단 역할을 수행
- 데이터를 쌓지 않기 때문에 적은 리소스로도 사용 가능
