RDB 단점

• 경직된 스키마, 유연한 확장 어려움
• 운영중인 로우가 많은 DB에 새로운 컬럼을 추가하는 것이 어려움
• 많아지는 테이블과 과도한 조인으로 성능 하락
• scale-out 어려움, 특히 레플리카를 사용하여 read는 많이 수용가능하나 write는 한계
• 트랜잭션 ACID로 인하여 성능 하락

NoSQL

2000년대 SNS 서비스의 발전으로 데이터 양이 기하급수적으로 증가하면서 기존 RDB의 성능 한계를 느낌
또한, 성능 측면에서만 아닌 예상할 수 없는 다양한 형태의 데이터를 받게되면서 기존 RDB의 스키마 설계 어려움을 느낌
아래는 MongoDB를 기준으로 설명

유연한 스키마

각 테이블을 collection으로 지칭, 각 튜플을 document로 지칭
스키마가 따로 없고 어떠한 형태의 document도 json 형식으로 저장 가능

즉, RDB에서 해주는 데이터 타입 검증, 제약 조건, 관계 설정 등을 모두 해주지 않음
애플리케이션측에서 관리가 필요함

중복 허용

조인을 최소화하기 위해 중복을 허용함
주문 목록 collection에 모든 document에 주문자 정보가 들어가 있음(RDB라면 주문자 정보를 가진 table을 분리하고 조인)

중복을 허용하므로 데이터 일관성을 유지하기 어려움
만약 주문자의 전화번호가 바뀐다면 모든 document에 전화번호를 업데이트 해야함
이러한 중복 데이터의 최신화 관리를 애플리케이션측에서 해야함

쉬운 scale-out

collection을 여러 서버에 분산하며 하나의 클러스터로 구성하여 사용
RDB라면 다른 서버의 테이블끼리 조인해야함

high-throughput, low-latency

ACID의 일부를 포기하고 high-throughput(단위 시간당 높은 처리량)과 low-latency(낮은 응답 시간)를 추구

Redis

key-value 형식의 빠른 데이터 저장소
in-memory 데이터베이스로 데이터를 메모리에 저장하여 빠른 응답 속도를 제공
캐시로 사용되기도 함

Redis를 캐시로 사용

HDD에 저장된 DB에 접근하기 전에 Redis에 데이터가 있는지 확인
cache miss가 발생하면 HDD에 접근하여 데이터를 가져옴
이후 Redis에 데이터를 저장 및 저장할 시간 설정
똑같은 요청에 대하여 cache hit이 발생하여 더 빠른 응답 속도를 제공