https://www.youtube.com/watch?v=sqVByJ5tbNA&embeds_referring_euri=https%3A%2F%2Flilys.ai%2F&embeds_referring_origin=https%3A%2F%2Flilys.ai&source_ve_path=MjM4NTE
[BJ.53 NoSQL 설명!! RDB와는 어떤 차이가 있는지도 설명!! MongoDB, Redis 매우 간단한 예제 포함!!] 유튜브 영상을 정리한 내용입니다.
1. RDB(관계형 데이터베이스)의 한계
한계 1: 유연하지 않은 스키마 변경
쇼핑몰의 주문 테이블을 예로 들어보자. 기존 Order 테이블에 order_id, product_id, quantity, order_date, user_id가 있다.
여기에 로켓 배송 기능을 추가하려면? → rocket_delivery 컬럼을 추가해야 한다.
이벤트 기능을 추가하려면? → event_id 컬럼을 또 추가해야 한다.
새로운 기능 추가 = 스키마 변경(컬럼 추가) 필수문제는 데이터가 이미 대량으로 쌓여 있을 때 발생한다. 5,000만 건의 데이터가 있는 테이블에 컬럼을 추가하는 작업은 DB 서버에 큰 부담을 주고, 서비스 전체에 영향을 줄 수 있다.
RDB는 스키마를 정의하고, 그 스키마에 맞춰 데이터를 저장해야 하기 때문에
확장성이 부족하다.
한계 2: 정규화로 인한 JOIN 성능 저하
RDB는 데이터 중복을 허용하지 않는 방향으로 설계하도록 가이드되어 있다. 그래서 정규화를 통해 테이블을 쪼개서 중복을 최소화한다.
하나의 테이블 → 정규화 → 4개의 테이블로 분리
중복은 줄었지만, 원래의 전체 데이터를 읽으려면 여러 테이블을 JOIN해야 한다. JOIN이 많아지면 CPU 사용량이 증가하고 응답 시간이 느려진다.
한계 3: Scale-Out이 어려움
RDB는 기본적으로 한 대의 컴퓨터에 저장된다. 트래픽이 몰리면 두 가지 방법으로 대응할 수 있다.
Scale-Up: 더 좋은 CPU, 더 많은 메모리로 교체하는 방식
Scale-Out: 서버를 추가로 투입하는 방식 (Replication, Sharding)
하지만 RDB에서 Scale-Out은 쉽지 않다.
- Replication 추가 시 → 전체 데이터를 새 서버에 복제해야 한다
- Sharding 시 → 운영 중인 서비스에서 데이터를 옮겨야 한다
- Write 트래픽이 많으면 → Read-Only 복제본으로는 해결이 안 된다
한계 4: ACID 보장의 비용
RDB의 트랜잭션은 ACID(Atomicity, Consistency, Isolation, Durability)를 보장한다. 이것은 분명한 장점이지만, 그만큼 처리량(Throughput)과 응답 시간(Latency)에 영향을 준다.
2. NoSQL의 등장 배경
인터넷이 전 세계적으로 보급되고, SNS가 등장하면서 폭발적으로 사용자가 늘어났다. 기존 RDBMS만으로는 커버하기 힘든 규모의 트래픽이 발생하기 시작했다.
새로운 요구사항:
1. 높은 처리량 (High Throughput)
2. 빠른 응답 시간 (Low Latency)
3. 비정형 데이터 처리 (다양한 형태의 데이터)이런 시대적 흐름에서 등장한 것이 NoSQL(Not Only SQL)
3. NoSQL의 핵심 특징
특징 1: Flexible Schema (유연한 스키마)
MongoDB를 예로 들면, 컬렉션(Collection) 생성 시 스키마를 정의하지 않는다.
// SQL: 컬럼 이름, 타입, 제약조건을 미리 정의
CREATE TABLE student (
id INT PRIMARY KEY,
name VARCHAR(100) NOT NULL
);
// MongoDB: 컬렉션 이름만 지정
db.createCollection("student")데이터를 넣을 때도 자유롭게 넣는다.
db.student.insertOne({ name: "easycode" })
db.student.insertOne({
name: "hobin",
address: { city: "Seoul", zipcode: "12345" },
certificates: ["SQLD", "AWS SAA"]
})같은 컬렉션 안에서 각 document가 서로 다른 구조로 데이터를 저장할 수 있다. 대신 스키마 관리를 DBMS가 아닌 application 레벨(개발자)에서 해야 한다.
참고로 SQL에서 Row/Tuple이라고 부르는 것을 MongoDB에서는 Document라고 부른다.
특징 2: 중복 허용 (Denormalization)
RDB는 정규화를 통해 중복을 최소화하지만, NoSQL은 중복을 허용하는 방향으로 데이터를 관리한다.
// MongoDB의 주문 도큐먼트 — 상품 정보와 사용자 정보를 함께 저장
{
orderId: 1,
productName: "keyboard", // 상품 테이블에서 JOIN 없이 바로 접근
productPrice: 50000,
userName: "easycode", // 사용자 테이블에서 JOIN 없이 바로 접근
phoneNumber: "010-1234-5678"
}RDB라면 product_id와 user_id만 저장하고 나머지는 JOIN으로 가져왔을 것이다. NoSQL은 중복을 허용하는 대신 JOIN 없이 한 번의 조회로 필요한 데이터를 모두 가져올 수 있다.
단점은 중복 데이터를 모두 최신 상태로 유지하는 것을 애플리케이션에서 관리해야 한다는 것이다.
특징 3: Scale-Out 최적화
NoSQL은 일반적으로 서버 여러 대를 하나의 클러스터로 구성해서 사용한다.
NoSQL 클러스터:
[서버 1] ←→ [서버 2] ←→ [서버 3] ←→ [서버 4]
데이터A 데이터B 데이터C 데이터D중복을 허용해서 데이터를 저장하기 때문에, 여러 컬렉션을 JOIN할 필요 없이 한 컬렉션에서 필요한 데이터를 읽으면 된다. 이 덕분에 데이터를 여러 서버에 분산 저장해도 성능이 유지된다.
RDB였다면 정규화된 테이블들이 여러 서버에 흩어져 있어서 JOIN 시 네트워크 트래픽이 발생하고, 성능이 저하될 수 있다.
중복 허용 → JOIN 불필요 → 데이터 분산 용이 → Scale-Out 최적화 이런 시너지 효과가 있다.
특징 4: ACID 일부 포기, 높은 성능 추구
NoSQL은 ACID의 일부를 포기하고, 대신 더 높은 처리량과 더 빠른 응답 시간을 추구한다.
단, 금융 시스템, 결제 시스템, 예약 시스템처럼 데이터 일관성(Consistency)이 중요한 환경에서는 NoSQL 사용에 주의가 필요하다. 일부 NoSQL은 ACID를 지원하기도 하므로, 실제 사용할 NoSQL의 매뉴얼을 확인해야 한다.
4. Redis — 캐시로 활용하기
Redis는 인메모리(In-Memory) Key-Value 형태의 NoSQL이다. 메모리를 사용하기 때문에 SSD/HDD 기반 DB보다 응답이 빠르다. DB로도 사용되지만 보통 캐시로 많이 활용된다.
캐시로 활용하는 흐름
유튜브를 예로 들어보자. 인기 영상에 요청이 몰리는 상황이다.
[사용자] → [백엔드 서버] → [Redis 캐시] → [DB]
1. 요청이 들어오면 Redis 캐시를 먼저 확인
2. 캐시에 데이터가 없으면 (Cache Miss)
→ DB에서 조회 → 결과를 Redis에 저장 (TTL 60초) → 응답
3. 캐시에 데이터가 있으면 (Cache Hit)
→ Redis에서 바로 읽어서 응답 (DB 접근 없음)
Redis를 캐시로 사용하면 DB 서버로 가는 트래픽을 줄이고, 메모리 기반이라 응답도 빠르다. 또한 Redis는 Replication과 자동 Failover도 지원한다.
5. 정리: RDB vs NoSQL
| 항목 | RDB | NoSQL |
|---|---|---|
| 스키마 | 엄격한 스키마 정의 필수 | Flexible Schema |
| 데이터 중복 | 정규화로 최소화 | 중복 허용 (JOIN 회피) |
| JOIN | 정규화된 테이블 간 JOIN 필요 | JOIN 없이 한 번에 조회 |
| Scale-Out | 어려움 (Replication, Sharding 복잡) | 최적화되어 있음 (클러스터) |
| 트랜잭션 | ACID 보장 | ACID 일부 포기, 높은 성능 |
| 적합한 곳 | 금융, 결제, 예약 등 일관성 중요 | SNS, 대규모 트래픽, 비정형 데이터 |
| 스키마 관리 | DBMS가 관리 | 애플리케이션(개발자)이 관리 |
