🧠 RDB vs NoSQL – 수직/수평 확장성과 트랜잭션 일관성 비교
✅ 1. 수직 확장 vs 수평 확장
구분 | 수직 확장 (Scale-Up) | 수평 확장 (Scale-Out) |
---|---|---|
개념 | 서버의 성능을 높이는 방식 | 서버의 개수를 늘리는 방식 |
방식 | CPU, RAM 업그레이드 | 서버 여러 대 추가 후 분산 처리 |
대표 | RDB (MySQL, Oracle) | NoSQL (MongoDB, Cassandra) |
장점 | 구조 단순, 트랜잭션 유지 쉬움 | 확장성 뛰어남, 대규모 처리에 유리 |
단점 | 비용 증가, 한계 존재 | 시스템 복잡성 증가, 일관성 관리 어려움 |
💬 왜 RDB는 수직 확장에 적합할까?
- 트랜잭션(ACID)을 보장하려면 동기화와 정합성 유지가 중요한데,
여러 서버에 분산되면 복잡해짐 - 테이블 간 JOIN, 외래 키 제약 등도 동기화가 빠른 단일 서버에서 유리함
💬 왜 NoSQL은 수평 확장에 적합할까?
- 스키마가 없고 JOIN도 안 쓰는 설계라서, 데이터를 잘게 나누어 여러 서버에 저장 가능
- Sharding(샤딩), Replication(복제) 같은 구조에 최적화됨
- 서버를 추가하기만 하면 성능이 확장됨 (Cloud 환경에서 매우 유리)
✅ 2. NoSQL의 "최종 일관성(Eventual Consistency)"이란?
분산 환경에서 모든 노드가 즉시 일치하지는 않지만, 결국엔 일치하게 되는 모델.
💡 개념 정리
- 즉시 일관성(Strong Consistency): 항상 동일한 데이터 보장 (RDB)
- 최종 일관성(Eventual Consistency): 일시적으로 불일치 가능하지만 나중에 동기화됨
- 예: A 서버에 쓴 데이터가 B 서버에 조금 늦게 반영될 수 있음
🔁 그럼 NoSQL은 트랜잭션이 없는 걸까?
아니야. 대부분의 NoSQL은 전통적인 ACID 트랜잭션은 보장하지 않지만,
제한적이거나 다른 방식으로 일관성을 관리해.
DB 종류 | 트랜잭션 지원 여부 |
---|---|
MongoDB | ✅ 단일 문서 트랜잭션, 최근은 다중 문서도 가능 |
Cassandra | ❌ 전통적인 트랜잭션 없음 (대신 Eventually Consistent) |
Redis | ✅ MULTI/EXEC로 간단한 트랜잭션 구조 지원 |
💬 면접용 요약 정리
RDB는 강력한 정합성과 트랜잭션 보장을 위해 수직 확장에 적합하고,
NoSQL은 스키마가 없고 분산 처리에 최적화되어 있어 수평 확장에 유리합니다.
NoSQL에서는 트랜잭션을 반드시 보장하지 않고, 대신 "최종 일관성"을 통해 결국 데이터가 모든 노드에 반영되도록 설계됩니다.
📌 참고: CAP 이론에서는 NoSQL이 가용성(Availability)과 파티션 허용성(Partition tolerance)을 중시하고,
일관성(Consistency)을 조금 포기한 모델이 많습니다.
'개발 > DB' 카테고리의 다른 글
1~3NF 정규화 과정 (0) | 2025.05.22 |
---|---|
트랜잭션 격리수준(Isolation Level) (MySQL) (2) | 2024.11.30 |
Lock (2) | 2024.11.29 |
DB 인덱싱 (4) | 2024.11.28 |