티스토리 뷰

Development/Database & SQL

RDB와 NoSQL의 차이점

쥬리리리 2022. 3. 29. 18:04

RDBMS

관계형 데이터베이스 관리 시스템을 의미, 이름과 같이 RDBMS는 관계형 데이터 모델을 기초로 두고 모든 데이터를 2차원 테이블 형태(속성-값)로 표현하는 데이터베이스

각각의 속성과 값을 가진 테이블들은 서로 관계를 맺으며 존재, 데이터 구조가 명확하며 변경 될 여지가 없으며 명확한 스키마가 중요한 경우, 또한 중복된 데이터가 없어 변경이 용이하기 때문에 관계를 맺고 있는 데이터가 자주 변경이 이루어지는 시스템에 적합

 

☞ 장점

- 명확하게 정의된 스키마, 데이터 무결성 보장

- 관계를 통해 각 데이터를 중복없이 한번만 저장 가능

 

단점

- 상대적으로 덜 유연, 데이터베이스 스키마를 미리 알고 계획해야한다. (나중에 수정하는 것이 어렵거나 불가능)

- JOIN문이 많은 매우 복잡한 쿼리가 만들어질 수 있음

- 수평확장이 어렵고 보통 수직확장만 가능, 즉 어느 시점에서 처리량/처리 능력과 관련하여 약간의 성장 한계에 직면할 수 있음

 

NoSQL

Not Only SQL, 데이터 저장 기술, 테이블 간 관계를 정의하지 않는다. 데이터 테이블은 그냥 하나의 테이블이며 따라서 일반적으로 테이블 간 Join 불가능, 데이터의 일관성은 포기하되 비용을 고려하여 여러 대의 데이터에 분산하여 저장하는 Scale-Out을 목표로 등장

정확한 데이터 구조를 알 수 없고 데이터가 변경/확장이 될 수 있는 경우에 사용하는 것이 좋다. update가 많이 이루어지지 않는 시스템에 좋다. 막대한 데이터를 저장해야 되는 시스템에 적합, JSON 파일을 빠르게 저장


장점

- 유연성 높음. 즉 저장된 데이터를 언제든지 조정하고 새로운 필드 추가 가능

- 데이터는 애플리케이션에서 필요한 형식으로 저장. (조회 속도 향상)

- 수직 및 수평확장이 가능하므로 데이터베이스가 애플리케이션에서 발생시키는 모든 읽기 쓰기 요청을 처리할 수 있음

 

단점

- 유연성 때문에 데이터 구조 결정이 늦어질 수 있음 (바로 계획 결정하는 것이 아니기 때문)

- 복사된 데이터가 변경되면 여러 컬렉션(테이블)과 문서를 수정해야함



각각 사용하기 좋은 경우

SQL

- 앱의 여러 부분에서 관련된 데이터가 비교적 자주 변경되는 경우 (NoSQL이라면 항상 여러 컬렉션을 수정해야한다.)

- 명확한 스키마가 중요하며, 데이터 구조가 극적으로 변경되지 않는경우

→ 데이터의 일관성, key를 기준으로 쿼리를 작성하는게 중요, join, FK, index 체크 시

 

NoSQL

- 정확한 데이터 요구사항을 알 수 없는 경우

- 읽기(read)처리를 자주하지만, 데이터를 자주 변경하지 않는 경우 

  (한번의 변경으로 수십개의 문서를 수정할 필요가 없는 경우)

- 데이터베이스를 수평적으로 확장해야하는 경우 

   (막대한 양의 데이터를 다뤄야하는 경우, 읽기 쓰기 처리량이 큰 경우)

→ 구매 내역, 게임 로드 등 수정될 일이 거의 없는 경우

 

댓글
링크
최근에 올라온 글
Total
Today
Yesterday