RDB의 단점1: 경직된 스키마
- 새로운 컬럼 추가 시 스키마 변경을 반드시 해야한다.
이미 해당 테이블에 많은 데이터가 있다면 새로운 컬럼을 추가하는 것은 부담이 될 수 있다.)
- 유연한 확장성의 부족
RDB의 단점2: 과도한 조인과 성능 하락
- 복잡한 조인으로 성능 하락
RDB는 데이터 중복제거르 위해 정규화를 진행한다다. 이를 통해 중복을 최소화하여 일관성을 향상시키고 저장 공간을 절약할 수 있다. 하지만 데이터를 가져오기 위해서는 여러 테이블 간에 JOIN을 수행하는 것이 필요하다. 복잡한 쿼리나 대량의 데이터에서 조인을 수행하면 성능 저하가 발생할 수 있다.(복잡한 JOIN은 read/write 성능에 영향을 미침)
RDB의 단점3: scale-out편하지 않음
- RDB는 기본적으로 한 대의 컴퓨터에 저장
많은 read/write가 올때 scale out(데이터 서버를 추가)이 힘듬
- scale up을 통한 database 성능 향상
cpu, memory를 향상해 성능 향상한다.
read: replication을 해서 read-only용으로 쓸 수 있게해서 select문은 처리할 수 있게 한다.

write: write 트래픽이 많다면 서버가 부하를 받게 된다. 그럼 cpu와 memory 사용량은 증가한다. 서버에 성능은 약화된다.
multi-master나 sharding 등의 방법이 있긴하지만 일반적으로 RDB는 scale-out에 유연한 DB는 아님
mulit-master: master가 여러 개이기 때문에 write를 나눠서 받을 수 있다.
replication를 구성하고 있는데 새로운 서버(세컨더리 서버)를 투입한다고 하면 복제를 해야하는 과정이 필요하다.
sharding: write 트래픽이 많아서 샤딩을 진행하면 데이터를 옮겨야하는데 서비스 운영 중에 데이터를 옮기는 것은 어렵다.
| scale up | 기존 서버의 사양을 업그레이드해 시스템 확장 |
| sacle out | 여러 대의 서버를 추가하여 시스템 확장 |
RDB의 단점4: ACID가 성능에 영향
- ACID를 보장하려다 보니 DB서버의 성능(performance)에 영향을 미침
RDB는 ACID(Atomicity, Consistency, Isolation, Durability) 특성을 보장하기 위해 트랜잭션을 사용한다.
이로 인해 데이터 일관성과 안전성은 확보되지만, 트랜잭션 처리로 인한 오버헤드가 발생하여 성능에 영향을 줄 수 있다.
| 원자성 (Atomicity) |
트랙잭션 연산이 정상적으로 수행하거나(Commit) 아니면 어떠한 연산도 수행되지 않아야 함(Rollback) |
| 일관성 (Consistency) |
시스템의 고정 요소는 트랙잭션 수행 전/후로 동일해야 함 |
| 고립성 (Isolation) |
개별 트랜잭션은 다른 트랜잭션의 간섭 및 영향 받지 않아야 함 |
| 영속성 (Durability) |
완료된 트랜잭션 결과는 영구적으로 기록되어야 함 |
RDB의 장점: ACID를 지원, 데이터 중복 최소화, 데이터 일관성 유지
NoSQL 특징
- 2000년대 초.중반
인터넷은 90년대 중반부터 널리 보급
폭발적인 인터넷 수요(SNS)로 기존의 RDBMS로는 감당하기 힘든 트래픽이 몰리는 상황이 발생한다.
*high-throughput(고처리량), low-latency(낮은 지연시간) 요구된다.
서비스의 형태가 다양해지면서 *비정형 데이터가 증가한다. 스키마가 고정되어 있는 것에 대한 불편함이 커졌다.
이에 대한 대안으로 NoSQL이 등장하게 되었다.
종류: mongoDB, redis, DynamoDB, CouchDB, Neo4j, HBase
NoSQL 특징1: 유연한 스키마 (mongoDB)
SQL은 테이블을 생성
create table student (
id INT PRIMARY KEY,
name VARCHAR(20),
...
);
NoSQL
db.createCollecion("student")
db.student.insertOne({
name: "easycode"
})
db.student.insertOne({
name : "hope"
address : {
counrty : "Korea",
state : "Seoul",
city : "Gangnam-gu",
street : "blurblur"
},
certificate : ["AWS soluition architect"]
})
db.student.find({name: "easycode"})
//결과
{
"_id" : ObjectId("63b3100da5829c4031c849af"), //자동 부여
"name" : "easycode"
}
db.student.find({}) //전체 결과
정의된 스키마가 없어서 데이터 넣고 싶은대로 넣는다.(스키마를 사전에 정의할 필요가 없다.)
mongoDB는 JSON 형태로 데이터를 저장한다.
NoSQL은 RDB의 Table에 해당하는 Collection을 가지고 있고, RDB의 Row에 해당하는 Document를 가지고 있다.
단점: application 레벨에서의 스키마 관리가 필요
RDB는 스키마 관리를 RDMS에서 해줬는데 개발자가 컬렉션 별로 어떤 데이터가 들어가는지 파악해야 한다.
NoSQL 특징2: 중복 허용 (mongoDB)
- 중복 허용(join 회피)
RDB의 경우 정규화를 통해 중복을 최소화한다. JOIN에 어려움이 발생한다.
NoSQL은 중복을 허용하여 JOIN을 회피한다.
db.getCollecion("order").find({})
{
"_id" : ObjectId("63b316b9a5829c4031c849d4"),
"prodcut_name" : "아이패드 5세대",
"price_per_product" : 120000.0,
"count" : 5.0,
"total_price" : 160000.0,
"user_name" : "easycode",
"phone_number" : "010-1234-5678"
},
{
"_id" : ObjectId("63be776a5829c4031c849d6"),
"prodcut_name" : "GOAT vvip 티셔츠 리미티드 에디션",
"price_per_product" : 25000.0,
"count" : 10.0,
"total_price" : 250000.0,
"user_name" : "easycode",
"phone_number" : "010-1234-5678",
"option" : [
"rocket_delivery"
]
}
easycode 부분을 보면 중복된 데이터가 발생한다.
RDB라면 정규화를 통해 중복을 최소화한다.
product 테이블로 저장하고 product_id만 저장
user 테이블로 저장하고 user_id만 저장해서 중복을 제거한다.
단점: application 레벨에서의 준복된 데이터들이 모두 최신 데이터를 유지할 수 있도록 관리해야 함.
NoSQL 특징3: scale-out 더 편함
- 서버 여러 대로 하나의 클러스터를 구성하여 사용
NoSQL
비정규화 = 데이터 중복 허용
NoSQL은 중복을 허용하기 때문에 DB 서버 간의 데이터 이동이나 JOIN을 필요로 하지않다.
NoSQL 데이터베이스는 일반적으로 데이터를 여러 서버로 분산하여 클러스터를 형성한다. 따라서 클러스터의 각 서버에서 데이터를 읽을 수 있으므로 응답 시간이 줄어든다. 노드에 장애가 발생하더라도 다른 노드에서 서비스를 지속할 수 있다.
RDB
RDBMS는 정규화된 데이터 모델을 사용하고, 데이터를 여러 테이블에 나누어 저장하기 때문에 JOIN을 하게 되면 네트워크 트래픽이 발생한다.
NoSQL 특징4: 더 높은 처리량
- ACID의 일부를 포기하고 high-throughput(고처리량), low-latency(낮은 지연시간) 추구
금융시스템, 예약시스템처럼 consistency가 중요한 환경에서는 사용하기가 조심스러움
Redis 특징
Redis는 in-memory key-value 데이터베이스이다.
reides> SET name easycode //name:key, value:easycode
"OK"//결과
redis> GET name
"easycode"
- in-memory key-value database, cache or, ..
- data type: strings, lists, sets, hashes, stored sets, ...
- hash-based sharded cluster: Redis는 데이터를 여러 서버에 분산 저장하는 기능을 제공하며 해시 기반의 샤딩(sharding) 클러스터를 형성할 수 있습니다. 이를 통해 대용량 데이터의 확장성을 확보할 수 있습니다.
- High Availability(replication, automatic failover): Redis는 데이터 복제(replication)와 자동 장애 복구(automatic failover)를 지원하여 고가용성을 제공합니다. 이로써 Redis 클러스터가 안정적으로 운영될 수 있습니다.
Redis를 cache로 사용한 예제

Redis는 in-memory 기반의 DB이고 memory의 응답성이 ssd, hdd보다 빠르기 때문에 DB 앞단에 Redis를 두어 cache로 많이 사용합니다. Redis를 Cache로 사용하면 DB 서버 혼자서 모든 트래픽을 처리하지 않아도 됩니다. Redis는 메모리 기반이므로 빠른 응답성을 제공하며 캐시 역할을 하여 DB 서버의 부하를 줄여줍니다. 많은 트래픽을 처리할 수 있으며 응답 시간이 개선됩니다.
아래의 강의를 보고 정리한 내용입니다.
출처: BJ.53 NoSQL 설명!! RDB와는 어떤 차이가 있는지도 설명!! MongoDB, Redis 매우 간단한 예제 포함!!
https://www.youtube.com/watch?v=sqVByJ5tbNA&t=564s
'cs > dev' 카테고리의 다른 글
| [CS]TDD(테스트 주도 개발) (1) | 2025.10.17 |
|---|---|
| [DB]파티셔닝? 샤딩? 레플리케이션? (partitioning? sharding? replication?) (0) | 2025.10.16 |
| [Spring] Spring Batch란? (0) | 2025.09.28 |
| [CS]프로세스, 스레드, 멀티태스킹, 멀티스레딩, 멀티프로세싱, 멀티프로그래밍까지 (0) | 2025.09.27 |
| 2022년 한이음 ICT 멘토링 후기 [공공데이터를 이용한 마이데이터 서비스 개발] (0) | 2025.09.26 |