프로젝트를 진행하며 채팅 내역을 MongoDB에 저장하기로 결정했다. 이는 MongoDB가 NoSQL 데이터베이스로서, 채팅 내역과 같은 비정형 데이터를 저장하는 데 더 적합하고, 조회 속도 또한 빠르기 때문이다. MongoDB가 이러한 장점을 가지는 이유를 RDB와 비교하며 정리해보려고 한다.
RDB(Relational Database)란?
RDB는 관계형 데이터베이스(Relational Database)의 약자로, MySQL, Oracle, PostgreSQL 등 대표적이다. 데이터를 행(Row)과 열(Column)로 구성된 테이블 형태로 저장하며, 스키마(Schema)라는 데이터 구조를 미리 정의하는 것이 특징이다.
RDB의 장점
- 명확한 스키마 구조
- 데이터를 테이블 형태로 관리하며, 사전에 정의된 스키마를 기반으로 일관성(Consistency)을 유지한다.
- 예를 들어, 회원 테이블에 email 컬럼이 정의되어 있으면, 반드시 이메일 형식의 데이터만 저장할 수 있다.
- ACID 트랜잭션 보장
- RDB는 ACID(Atomicity, Consistency, Isolation, Durability) 특성을 보장하여 트랜잭션의 안정성을 제공한다.
- 특히, 금융 서비스나 주문 관리 시스템처럼 데이터 무결성이 중요한 분야에 적합하다.
RDB의 단점
- 수평적 확장(Scale-out) 어려움
- RDB는 보통 수직적 확장(Scale-up)에 유리하고, 수평적 확장(Scale-out)이 쉽지 않다.
- 스키마 변경의 어려움
- 사전에 정의된 스키마 구조는 데이터의 안정성을 보장하지만, 구조 변경 시는 많은 작업이 필요하다.
- Join 연산으로 인한 성능 저하
- RDB는 데이터 정규화(Normalization)를 통해 중복을 최소화하지만, 테이블 간 Join 연산이 많아질수록 성능이 저하될 수 있다.
MongoDB(NoSQL)란?
MongoDB는 대표적인 NoSQL 데이터베이스로, 데이터를 JSON 형태의 문서(Document)로 저장한다. (엄밀히 말하면 BSON형식이다)
- 관계형 데이터베이스가 테이블 중심이라면, MongoDB는 문서를 중심으로 데이터를 관리한다.
- 복잡한 관계 설정 없이도 유연하게 데이터를 관리할 수 있어, 비정형 데이터(이미지, 영상, 로그 데이터) 처리에 유리하다.
MongoDB의 장점
- 유연한 스키마 구조
- 스키마리스(Schema-less) 구조를 지원하여 데이터 구조 변경이 자유롭다.
- 예를 들어, user 컬렉션에 새로운 필드를 추가하려고 해도 기존 문서를 변경할 필요 없이 바로 적용할 수 있. (RDB는 많은 작업이 필요하다)
- 수평적 확장(Sharding) 용이
- MongoDB는 Sharding을 통해 수평적 확장(Scale-out)이 매우 용이하다.
- 트래픽이 늘어나면, 서버를 여러 대로 나누어 부하를 분산할 수 있다.
MongoDB의 단점
- ACID 보장이 약함
- MongoDB는 단일 문서 수준에서만 ACID를 보장하기 때문에, 다중 문서를 다루는 트랜잭션에서는 데이터 일관성이 보장되지 않는다.
- 다만, 최근 버전에서는 다중 문서 트랜잭션도 지원하여 RDB와 유사한 수준의 ACID 보장이 가능해졌다.
- 중복 데이터 발생 가능성
- MongoDB는 중첩 문서(Embedded Document) 구조를 권장다.
- 하지만 중첩 문서를 많이 사용하면 데이터 중복이 발생할 수 있고, 이로 인해 데이터 관리의 복잡성이 증가할 수 있다.
MongoDB는 왜 ACID 대신 BASE를 선택했을까?
MongoDB는 관계형 데이터베이스처럼 완전한 ACID 특성을 보장하지 않는다. 대신, 성능과 확장성을 위해 BASE 원칙을 따른다.
BASE란?
- Basically Available: 시스템은 항상 응답을 제공해야 한다.
- Soft state: 데이터의 일관성을 즉각적으로 보장하지는 않는다.
- Eventual consistency: 시간이 지나면 데이터의 일관성이 유지된다.
즉, MongoDB는
- 성능과 확장성을 위해 ACID를 포기하고 BASE 원칙을 통해 효율성을 극대화 했다.
RDB vs MongoDB: 스키마 변경
RDB에서 필드(칼럼) 추가
RDB는 정해진 스키마(Schema)를 기반으로 작동하기 때문에, 칼럼 추가 시 반드시 구조 변경 작업이 필요하.
RDB 칼럼 추가 시 주의사항
- 서비스 중단 가능성
- 대규모 테이블에 칼럼 추가 시 서비스가 잠시 중단될 수 있음.
- 예를 들어, 수억 개의 레코드가 있는 테이블에 칼럼을 추가할 경우 상당한 시간이 소요된다.
- 기존 데이터에 대한 처리 필요
- 신규 칼럼은 기본값이 NULL이기 때문에, 데이터 일관성 유지를 위해 후속 업데이트 작업이 필요할 수 있다.
- 예: 기존 사용자들에게 기본 전화번호를 설정해야 하는 경우.
- 스키마 변경 시 코드 수정
- 애플리케이션 코드에 칼럼이 새로 추가되면 관련된 SQL 쿼리를 모두 수정해야 한다.
MongoDB에서 필드(칼럼) 추가
MongoDB는 스키마리스(Schema-less) 구조를 기반으로 작동하므로,
필드를 추가하기 위해 별도의 구조 변경 작업이 필요없다.
- 데이터를 삽입할 때 새 필드를 추가하면 MongoDB가 자동으로 필드를 생성한다.
MongoDB 필드 추가 시 주의사항
- 데이터 구조 관리 필요
- 구조를 강제하지 않기 때문에, 동일 컬렉션 내에서 필드 구조가 다를 수 있음.
- 예를 들어, phone_number가 있는 문서와 없는 문서가 혼재할 수 있다.
- 애플리케이션 코드 변경 필요
- 데이터베이스 구조는 변경할 필요가 없지만,애플리케이션 코드 내 필드 참조 부분은 수정해야 한.
- 필드 누락 오류 가능성
- 프런트엔드나 백엔드 코드에서 해당 필드가 없을 때의 예외처리를 반드시 고려해야 한다.
이처럼 MongoDB는 RDB에 비해 필드를 추가하는 데 더 용이하고, 확장성이 높다.
물론 이로 인해 일관성 부족 등의 단점이 존재한다.
RDB vs MongoDB: 구조적 차이로 인한 확장성 차이
RDB(관계형 데이터베이스)의 구조적 한계
- 스키마 고정 및 관계성(Join) 의존
- RDB는 테이블 간 관계(Join)을 중시하여 데이터 정규화를 통해 중복을 최소화한다.
- 다수의 테이블을 Join해야 하므로 데이터를 여러 서버로 나누는 수평적 확장이 어렵다.
- 수평적 확장을 시도하면, 서로 다른 서버 간 Join 연산 발생 → 성능 저하.
- 마스터-슬레이브 복제(Master-Slave Replication)
- RDB는 주로 Master-Slave 구조로 확장한다.
- Master가 모든 쓰기 작업을 담당하고, Slave는 읽기 작업을 담당.
- 파티셔닝(Partitioning) 복잡성
- RDB는 데이터 파티셔닝(분할) 시 수동 설정이 필요하고 관리가 복잡하다.
MongoDB(문서형 데이터베이스)의 수평적 확장 설계
MongoDB는 수평적 확장(Scale-out)을 전제로 설계되었다.
- 관계(Join)를 최소화하고, JSON(BSON) 기반의 문서(Document)로 데이터를 저장하여 독립적 확장성을 확보.
- MongoDB는 Sharding을 통해 데이터와 트래픽을 여러 서버에 자동으로 분산한다.
Master-Slave Replication, Sharding, Partitioning
Master-Slave Replication(마스터-슬레이브 복제)
정의
- 하나의 Master 노드가 쓰기 작업(Write)을 담당하고,
- 여러 Slave 노드가 읽기 작업(Read)을 분담하여 데이터베이스의 읽기 성능을 개선하는 방식.
- RDB와 MongoDB 모두 지원.
장점
- 읽기 성능(Read) 확장 → Slave를 늘릴수록 성능 선형 증가.
- Master 장애 시 Slave를 Master로 승격(Failover) 가능.
단점
- 쓰기 성능 제한 → Master 1대만 쓰기 처리.
- Replication Delay(복제 지연) → 네트워크 지연으로 Slave 데이터 불일치 가능.
- Failover 관리 필요 → Master 장애 시 수동 또는 자동 전환 필요.
Sharding(샤딩)
정의
- 데이터베이스를 **샤드(Shard)**라는 단위로 **수평적으로 분할(Scale-out)**하여 여러 서버에 분산 저장하는 기술.
- 하나의 큰 데이터베이스를 작은 단위로 나누어 병렬 처리 성능을 극대화.
장점
- 수평 확장성(Scalability) → 데이터를 여러 서버에 분산 저장하여 전체 시스템의 용량을 확장할 수 있음.
- 성능 최적화 → 데이터가 분산되므로 읽기/쓰기 성능이 향상될 수 있음.
- Fault Tolerance(장애 내성) → 샤드 서버 중 일부가 장애를 일으켜도 전체 시스템의 가용성이 유지될 수 있음.
단점
- Shard Key 선택 중요 → Hotspot 현상(특정 Shard에 데이터 집중).
- Cross-Shard Query(다중 Shard 조회) 성능 저하 가능.
- 관리 복잡성 → Shard 추가 및 데이터 재분배 필요.
Partitioning(파티셔닝)
정의
- 하나의 테이블이나 인덱스를 논리적으로 분할하여 성능과 관리 효율성을 개선하는 기법.
- 데이터를 분할하여 성능을 향상시키지만, 하나의 데이터베이스 내에서만 적용.
- 같은 데이터베이스 내부에서 샤딩을 하는 느낌
RDB vs MongoDB: Master-Slave Replication과 Sharding
RDB에서 Sharding이 어려운 이유
RDB는 관계형 모델(Relational Model)을 기반으로 설계되어 데이터 정규화와 Join 연산이 필수적이다.
- JOIN 연산은 다중 서버 조회 시 성능 저하를 유발.
- Sharding Key를 설정해도 Cross-Shard Join 발생 → 네트워크 I/O 증가.
- 정규화된 구조는 Sharding 시 데이터 재구성 필요 → 유지보수 비용 증가.
MongoDB가 Sharding에 유리한 이유
- MongoDB는 JSON 기반의 문서(Document) 저장 방식을 사용하여 데이터 간 관계(Join)를 최소화 한다.
RDB는 Sharding보다 Master-Slave Replication 선호
- Sharding은 RDB에도 가능하지만, 관리와 성능 이슈로 잘 사용되지 않음.
- RDB는*마스터-슬레이브 복제(Master-Slave Replication)로 읽기 성능을 개선.
- MongoDB는 Sharding을 통해 데이터를 수평적으로 분산 → 대규모 트래픽에 유리
Master-Slave Replication 구조
Master-Slave Replication은 쓰기/읽기 부하 분산과 고가용성(HA)을 위한 데이터 복제 구조이다.
Master 노드는 쓰기(Write)를 담당하고, Slave 노드는 읽기(Read)를 담당하며, Master에서 변경된 데이터를 Slave에 복제한다.
Master-Slave Replication의 기본 동작 흐름
- Master에 데이터 변경(INSERT/UPDATE/DELETE)
- Master는 변경 내용을 Binary Log(또는 WAL)로 기록
- Slave는 Binary Log를 주기적으로 복제(fetch)
- Slave는 Binary Log 내용을 재현(Replay)하여 Master와 동일한 데이터 유지
1. Synchronous Replication(동기 복제)
Master와 Slave가 완벽히 동기화될 때까지 쓰기 작업 완료 응답을 지연.
쓰기 작업 흐름:
- 클라이언트 → Master에 데이터 삽입 요청.
- Master → 모든 Slave에 데이터 복제 요청.
- 모든 Slave가 복제를 완료하면 클라이언트에 응답 반환.
장점:
- 데이터 일관성(Strong Consistency) 보장.
- Master와 Slave의 데이터 동기성 유지.
단점:
- Slave 중 하나라도 응답이 느리면 전체 쓰기 성능 저하.
- 네트워크 지연 발생 시 쓰기 성능 병목 가능.
2. Asynchronous Replication(비동기 복제)
Master가 바로 응답하고, Slave는 이후 비동기적으로 동기화.
쓰기 작업 흐름:
- 클라이언트 → Master에 데이터 삽입 요청.
- Master → 즉시 클라이언트에 응답 반환.
- Slave가 별도 쓰레드로 변경 로그(Replication Log)를 주기적으로 가져와 복제.
장점:
- 쓰기 성능(Write Throughput)이 뛰어남.
- Slave가 많아도 성능 저하 최소화.
단점:
- Replication Lag(복제 지연)으로 인해 Slave의 데이터가 Master보다 늦게 업데이트될 수 있음.
- 읽기 작업의 일관성이 떨어질 수 있음(읽기 시점에 Slave에 데이터가 없을 수 있음).
3. Semi-Synchronous Replication(반동기 복제) (하이브리드 방식)
- 일부 Slave만 동기 복제 후, 나머지는 비동기로 처리.
동작 원리:
- 쓰기 작업 후 최소한 한 개의 Slave 노드가 복제를 완료해야 클라이언트에 응답.
- 나머지 Slave는 비동기 방식으로 데이터 복제.
장점:
- 동기 복제의 일관성(Consistency)과비동기 복제의 성능(Performance) 절충.
단점:
- Slave 1개 이상이 응답하지 않으면 쓰기 지연 발생.
Master-Slave Replication이 성능 개선이 극대화되는 상황
1. 읽기(Read) 요청이 많은 서비스
- *읽기 요청(SELECT)**이 **쓰기 요청(INSERT/UPDATE/DELETE)**보다 훨씬 많은 경우.
- Slave 수를 늘림으로써 읽기 성능이 선형적으로 개선된다.
대표 사례:
- 게시판: 게시글 조회 트래픽이 게시글 작성보다 많음.
- 뉴스 포털: 뉴스 조회 수백만 건, 뉴스 작성은 일부 기자만 담당.
- SNS 피드: 타임라인 조회는 수억 건, 글 작성은 상대적으로 적음.
예시:
- Master가 쓰기 요청을 처리.
- Slave는 조회(피드, 댓글 조회)를 병렬 처리하여 읽기 성능 극대화.
2. 데이터 일관성(Consistency)보다 가용성(Availability)이 중요한 서비스
- 읽기 성능이 중요한 서비스에서 **일관성 지연(Replication Lag)**을 허용할 수 있는 경우.
- Real-time 강제 동기화가 필요하지 않은 서비스.
대표 사례:
- 쇼핑몰의 상품 조회 서비스: 가격 변경 시 몇 초간의 데이터 일관성 오류는 허용 가능.
- 동영상 플랫폼(YouTube, Netflix): 동영상 조회 수 카운트는 지연되어도 서비스 품질에는 큰 영향이 없음.
3. 데이터 가용성을 위한 고가용성(High Availability)이 필요한 경우
- Master 장애 발생 시 → Slave를 Master로 승격(Promotion)하여 서비스 연속성 확보.
- Failover(장애 전환)이 필요할 때.
대표 사례:
- 은행의 거래 내역 조회 시스템: 조회 서비스는 중단 없이 유지되어야 함.
- 이커머스 서비스의 상품 페이지: 트래픽 급증 시 Slave 서버를 즉시 추가하여 서비스 안정성 유지.
Master-Slave Replication의 주요 장점
1. 읽기 성능(Reading Performance) 수평적 확장(Scale-out)
- Slave 서버를 추가하면 읽기 성능이 Slave 수만큼 선형적으로 증가.
- Master 1대 → Slave 10대로 구성 시, 이론적으로 10배의 읽기 성능 향상 가능.
예시:
- 동시 사용자 수: 1만 명 → Slave 5대를 추가 → 동시 읽기 처리 능력 5배 증가.
2. 시스템 가용성(Availability) 강화
- Master 장애 시 → Slave를 Master로 승격(Failover)하여 서비스 중단 방지.
- Master-Slave Replication은 고가용성(HA)을 위한 기본 구성 요소로 활용.
예시:
- MySQL Replication과 MHA(MySQL Master High Availability)로 자동 Failover 구성.
3. 데이터 백업(Backup) 중 서비스 지연 최소화
- 백업 작업을 Slave에서 수행하여 Master의 서비스 성능 저하 방지.
- Slave DB를 Read-Only 모드로 두고 백업 및 분석 작업을 병렬로 진행.
예시:
- 데이터 분석을 위한 BI 도구는 Slave에서 분석 쿼리 실행 → Master는 서비스 트랜잭션 유지.
4. 서비스 장애 및 부하 분산(Load Balancing)
- Geo-Replication(지리적 복제)로 전 세계에 Slave를 배치 → 지역 사용자에게 빠른 응답 제공.
- 트래픽 폭증 시 Slave 서버 추가로 부하 분산 가능.
예시:
- 미국, 유럽, 아시아에 Slave 배포 → 글로벌 서비스 응답 속도 개선.
Master-Slave Replication의 한계와 개선 방법
1. Master의 쓰기 성능 병목(Write Bottleneck)
- Master 1대에서 모든 쓰기 작업을 담당 → 쓰기 부하 증가 시 성능 한계.
- 해결 방법:
- Sharding 도입 → 여러 Master로 분산.
- Multi-Master Replication(다중 마스터 복제) 사용. (충돌, 일관성 문제가 생길수 있다)
2. Replication Lag(복제 지연)
- Slave의 Binary Log 복제 및 Replay 지연 시, 일관성 문제 발생.
- 해결 방법:
- Semi-Synchronous Replication 도입.
- Slave 서버 성능 모니터링 및 튜닝(I/O 성능 개선).
3. Split-Brain(스플릿 브레인)
- Master 장애 시 Slave를 Master로 승격 → 기존 Master 복구 시 두 Master의 데이터 충돌 발생 가능.
- 해결 방법:
- Heartbeat 모니터링 및 Split-Brain Detection 도구 사용.
- Orchestrator, MHA 등 자동 장애 감지 및 복구 도구 적용.
결론: Master-Slave Replication을 적용하기 좋은 경우
- 쓰기(Write)보다 읽기(Read) 트래픽이 압도적으로 많은 서비스.
- 비즈니스적으로 약간의 데이터 일관성 지연이 허용되는 경우.
- 서비스 가용성(Availability) 확보를 위해 장애 복구(Failover)가 필요한 시스템.
정리: MongoDB는 왜 RDB보다 속도가 빠를까?
MongoDB가 RDB보다 속도가 빠른 이유
- 스키마리스 구조 (Schema-less)
- RDB는 데이터를 저장하기 전에 스키마를 정의하고 이를 엄격히 따라야 하며, Join 연산으로 데이터 관계를 유지한다.
- 반면 MongoDB는 JSON(BSON) 기반의 문서 저장 방식을 사용하여 스키마 변경이 유연하며, 데이터 구조를 사전에 정의할 필요가 없다.
- 이로 인해 데이터 삽입, 조회 속도가 빨라지고 애플리케이션 코드 변경 시에도 유연한 구조 관리가 가능하다. (구조적 검증 절차 최소화)
- Join 연산 최소화
- RDB는 데이터 정규화를 통해 중복을 최소화하지만, 다수의 테이블을 Join해야 하는 경우 성능 저하가 발생한다.
- MongoDB는 중첩 문서(Embedded Document)를 사용하여 하나의 문서에 관련 데이터를 함께 저장하므로 Join 없이 빠른 조회가 가능하다.
- 수평적 확장(Sharding)
- MongoDB는 Sharding(샤딩)을 통해 수평적 확장(Scale-out)이 용이하다.
- 데이터와 트래픽을 다수의 서버로 분산하여 병렬 처리가 가능하므로 대규모 데이터 환경에서 성능이 뛰어나다.
- RDB는 관계형 구조로 인해 Sharding 시 Cross-Shard Join 성능 저하가 발생할 수 있다.
- BASE 원칙 채택
- RDB는 ACID 특성(Atomicity, Consistency, Isolation, Durability)을 보장하여 데이터 일관성을 우선시한다.
- MongoDB는 BASE 원칙(Basically Available, Soft state, Eventual consistency)을 채택하여 일관성을 다소 희생하고 성능을 극대화했다.
- 즉, 네트워크 지연이나 시스템 장애 시에도 가용성 확보와 빠른 응답 제공이 가능하다.
- 쓰기(Write) 성능 최적화
- MongoDB는 단일 문서 수준에서만 ACID를 보장하므로, 쓰기 작업 시 Lock의 오버헤드가 RDB보다 낮다.
- 특히 로그 저장, 사용자 행동 데이터 수집과 같은 쓰기 중심(Write-heavy) 애플리케이션에 적합하다.
결론
MongoDB는 Sharding 기반의 수평적 확장성, Join 최소화, Schema-less 구조를 통해 RDB보다 속도가 빠를 수 있다. 그러나 일관성이 중요한 서비스에는 ACID 보장이 더 강력한 RDB를 선택해야 하며, 유연성과 성능이 필요한 서비스에서는 MongoDB가 강점을 발휘할 수 있다.
댓글