RDB와 NoSQL

쉬운코드님의 유튜브 영상 보면서 정리한 내용입니다.

 

Relation Database의 단점

유연한 확장성의 부족

새로운 column을 추가하고 싶으면 반드시 scheme를 변경해야 한다.

scheme를 변경이 필요하여 컬럼을 추가한다면 해당 작업 자체가 굉장히 위험 부담이 될 수 있다.

(왜냐하면 기존에 있는 대량 데이터에 대해서 새로운 column을 추가하기 때문에 대용량 write가 필요함)

 

복잡한 join은 read의 하락

중복 제거(for 데이터의 일관성)를 위해 정규화 진행한다. 이는 데이터 중복을 최소화한다.

하지만 전체 데이터를 읽어오고 싶을 때 join을 많이 해야하는 문제가 발생한다.

→ 그만큼 DB 서버에 CPU 많이 사용하고, 응답 시간이 늘어난다.

 

일반적으로 RDB는 scale-out에 유연한 DB가 아니다

read/write 요청에 엄청 몰려오면 컴퓨터의 cpu, memory 사용량이 높아진다.

→ 처리량(throughput)이 힘들어진다.

RDB는 scale up을 통해 database 성능을 향상시킬 수 있다(보다 좋은 CPU, memory로 바꿔준다.

혹은 replication을 사용할 수 있지만, read 트래픽만 분산 처리 할 수 있다.

 

ACID 특성

ACID를 보장하려다보니 trade off로 DB 서버의 performance에 어느정도 영향을 미치게 된다.

NoSQL

[등장 배경] 2000대 이후 SNS 등의 미디어가 등장하면서

high throughput, low latency 요구됨 + 비정형 데이터 증가

 

특징

• 스키마가 유연하다.
  이는 application 레벨에서 스키마 관리 필요하다.
• 중복을 허용한다. (join 회피)
  이는 application 레벨에서 중복된 데이터들이 모두 최신 데이터를 유지할 수 있도록 관리해야 한다.
• scale-out에 용이하다.
  서버 여러 대로 하나의 클러스터를 구성하여 사용한다.
• ACID의 일부를 포기하고 high-throughput, low-latency 추구한다.
  하지만, 금융 시스템처럼 consistency가 중요한 환경에서는 사용하기에 조심스럽다.

 

NoSQL이 대두되는 이유 중 하나는 RDBMS에서의 데이터 일관성과 성능 사이의 트레이드오프를 극복하기 위함이다.

RDBMS는 ACID 특성을 보장하여 데이터 일관성과 무결성을 강조하지만, 이로 인해 처리량과 응답 시간에 제약이 생길 수 있다.

반면에 NoSQL은 BASE 원칙을 따르며, 데이터 일관성보다는 가용성과 성능에 더 중점을 둔다. 이러한 특성으로 NoSQL은 대규모 데이터 처리 및 확장성을 제공하면서도 높은 처리량과 빠른 응답 시간을 달성할 수 있다.