RDBMS vs NoSQL 비교

MySQL DB인 프로젝트에서 채팅 기능을 개발했는데, 대용량 채팅 조회 성능 개선 방법 중 하나로 NoSQL 로 리팩토링을 한번 해보려고 하는 중이다.

보통 NoSQL이 조회 성능이 좋다고 하는데, 성능 측면에서 뭐가 어떻게 빠른지 궁금해서 이번에 직접 비교해 보고 정리해두려고 한다.

---

1. RDBMS vs NoSQL

주요 차이점

• 데이터 저장 방식
• 스키마
• 쿼리
• 확장성

RDBMS

• 관계(외래키) 정의, JOIN 가능
• 강한 일관성(ACID) → 데이터 무결성 보장
• 확장 방식: 주로 Scale-Up (고성능 서버로 업그레이드)
• 분산 저장 가능하지만 복잡하고 동기화 비용이 큼

NoSQL

• 관계 정의 없음, JOIN 거의 불가능
• 최종 일관성(Eventual Consistency) 우선
• 확장 방식: Scale-Out (서버 여러 대로 분산 저장)
• 대규모 트래픽·빅데이터 환경에 적합

2. NoSQL+RDBMS 섞어서 쓰는 경우

• 데이터 특성별로 DB 선택

  • 로그/분석 데이터 → NoSQL (속도, 확장성 우선)
  • 결제/거래 기록 → RDBMS (정합성 우선)

• 장점: 효율성과 안정성 둘 다 확보

• 단점: 운영·데이터 통합이 복잡해짐

3. NoSQL 종류

• MongoDB: 문서형 NoSQL, 유연한 쿼리·인덱스, 샤딩 지원
• Cassandra: 와이드컬럼, 대규모 쓰기 처리량에 강함(조회 패턴 고정 필요)
• Redis: 세션/캐시/실시간 카운트 관리
• Elasticsearch: 검색·하이라이트용 보조 인덱스
• Firebase: 구글 관리형 NoSQL, 실시간 동기화 기본 제공, 서버 없이 사용 가능

4. NoSQL의 Scale-Out이 이루어지는 방식

1. 최종 일관성(Eventual Consistency) 중심

   • 모든 노드의 데이터가 항상 동일할 필요 없이, 일정 시간 후 동기화됨
   • 실시간 강한 일관성 유지 비용이 없어서 노드 확장이 쉽고 빠름

2. 샤딩(Sharding)

   • 데이터를 샤드 키(Shard Key) 기준으로 여러 서버(노드)에 분산 저장
   • 범위 샤딩, 해시 샤딩, 복합 키 샤딩 등 다양한 방식
   • 노드 추가 시 데이터가 자동 재분배되어 부하 분산

3. 리플리케이션(Replication)

   • 동일 데이터를 여러 노드에 복제하여 장애 대비 및 읽기 부하 분산
   • Primary-Secondary 구조, 멀티 마스터 구조 등
   • 읽기 요청은 여러 복제본에 분산 가능, 쓰기는 Primary(또는 리더)에서 처리 후 복제

5. 채팅 서비스에서 RDBMS+NoSQL 조합

1) 참조형

• NoSQL: 메시지 본문 + userId 저장
• RDBMS: userId 기반 사용자 정보 조회 (캐시+벌크 조회로 최적화)
• 장점: 항상 최신 사용자 정보 표시 가능
• 단점: 쿼리 2번(메시지+프로필), 캐시 필수

2) 스냅샷형

• NoSQL: 메시지 본문 + 당시의 사용자 정보(닉네임, 아바타 등) 저장
• 장점: 메시지 조회 시 조인 불필요, 속도 빠름
• 단점: 프로필 변경 시 과거 메시지에 반영 안 됨(최종 일관성)
• 채팅·피드 등 조회 성능이 중요한 서비스에서 선호

---

📌 정리

• 채팅 시스템에선 메시지 저장은 NoSQL, 권한·유저 정보는 RDBMS 조합이 일반적
• 조회 성능이 중요하면 스냅샷 저장(2번 패턴)이 더 적합
• Firebase는 관리형·실시간 편의성은 뛰어나지만 제약이 있고, MongoDB는 자유도·확장성은 높지만 실시간·인프라는 직접 구성해야 함

참고

https://whatap.io/bbs/board.php?bo_table=blog&wr_id=216&page=3