RDB와 NoSQL
RDB와 NoSQL 차이 정리
개발을 하다 보면 한 번쯤 이런 질문을 받게 된다.
“RDB랑 NoSQL 중에 뭐 써야 하나요?”
이 질문에 단순히
“이건 RDB, 저건 NoSQL”이라고 답하는 건 쉽다.
하지만 실제 현업에서는 그렇게 단순하게 결정되지 않는다.
이 글에서는
이론적인 정의보다는, 현업에서 둘 다 써보면서 느꼈던 차이점과 선택 기준을 중심으로
RDB와 NoSQL을 정리해보려고 한다.
RDB란 무엇인가? (아주 간단히)
RDB(Relational Database)는
데이터를 테이블(행과 열) 형태로 저장하고,
테이블 간의 관계(Relation) 를 명확하게 정의하는 데이터베이스다.
RDB의 핵심 특징
- 고정된 스키마
- SQL 기반 쿼리
- ACID 트랜잭션 보장
- 데이터 무결성에 강함
대표적인 RDB
- MySQL
- PostgreSQL
- Oracle
한 줄 요약
“데이터 정합성과 관계가 중요한 시스템에 강한 DB”
NoSQL은 왜 등장했을까?
NoSQL은 RDB를 대체하기 위해 등장한 기술이 아니다.
RDB가 잘 해결하지 못하는 문제를 풀기 위해 등장한 선택지에 가깝다.
RDB가 힘들어지는 순간
- 트래픽이 급격히 증가할 때
- 수평 확장이 필요할 때
- 스키마가 자주 바뀌는 서비스
- 비정형 데이터가 많을 때
이런 상황에서
“테이블 구조를 엄격하게 유지하는 방식”은 오히려 발목을 잡는다.
NoSQL이란 무엇인가?
NoSQL은 말 그대로
Not Only SQL, 즉 SQL이 아닌 방식도 허용하는 DB다.
NoSQL의 특징
- 스키마가 유연함
- 수평 확장에 유리
- 대용량 데이터 처리에 강함
- 경우에 따라 Eventually Consistency 선택
NoSQL 종류별 간단 정리
| 유형 | 예시 | 주 사용처 |
|---|---|---|
| Key-Value | Redis | 캐시, 세션 |
| Document | MongoDB | JSON 데이터 |
| Column | Cassandra | 로그, 이벤트 |
| Graph | Neo4j | 관계 중심 데이터 |
한 줄 요약
“유연성과 확장성이 필요한 경우에 강한 DB”
RDB vs NoSQL 한눈에 비교
| 항목 | RDB | NoSQL |
|---|---|---|
| 데이터 구조 | 테이블 | 문서, 키-값 등 |
| 스키마 | 고정 | 유연 |
| 트랜잭션 | 강함 (ACID) | 제한적 |
| 확장 방식 | 수직 확장 | 수평 확장 |
| 일관성 | 강한 일관성 | 최종 일관성 |
| 학습 난이도 | 비교적 높음 | 상대적으로 낮음 |
현업에서 써보니 느낀 차이
RDB를 쓸 때 좋았던 점
- 데이터 정합성에 대한 고민이 적다
- JOIN을 활용한 복잡한 조회가 편하다
- 장애 상황에서도 신뢰도가 높다
👉 결제, 주문, 정산 같은 도메인에서는 여전히 최적
NoSQL을 쓸 때 좋았던 점
- 구조 변경에 대한 부담이 적다
- 대량 트래픽 처리에 유리하다
- 캐시나 세션 처리에서 압도적으로 편하다
👉 로그, 이벤트, 캐시 계층에서는 사실상 필수
그래서 언제 어떤 걸 써야 할까?
RDB가 잘 맞는 경우
- 금융, 결제, 주문 시스템
- 데이터 관계가 복잡한 경우
- 무결성이 가장 중요한 경우
NoSQL이 잘 맞는 경우
- 로그, 이벤트, 통계 데이터
- 트래픽이 많고 확장이 중요한 경우
- 스키마가 자주 바뀌는 서비스
- 캐시 / 세션 관리
그리고 현실에서는 대부분 이렇게 간다.
RDB + NoSQL을 함께 사용
메인 데이터는 RDB,
캐시나 부하 분산용으로 NoSQL을 붙이는 구조가 가장 흔하다.
마무리하며
RDB와 NoSQL의 차이는
“어느 게 더 좋다”의 문제가 아니다.
중요한 건
지금 해결하려는 문제가 무엇인가
그 문제에 가장 적합한 도구가 무엇인가
라는 질문에 답할 수 있는가이다.
DB를 선택하는 기준이 명확해질수록,
아키텍처도 자연스럽게 설득력을 갖게 된다.
