RDBMS 와 NoSQL 정리

chichi·2023년 1월 17일

nosql rdb

RDBMS

관계형(Relational) 데이터베이스 관리 시스템.

모델

모든 데이터를 2차원 테이블 형태(row-column)로 표현.

특징

table 과 table 간에 관계를 맺을 수 있고, 그 관계를 외래키(fk)를 통해 표현한다.
fk를 통한 join 이 가능하고, 그렇기에 데이터를 중복 저장할 필요가 없다.
Schema 가 명확하여 데이터의 무결성이 보장된다.
트랜잭션: 질의를 하나의 묶음으로 처리해서, 중가네 실행이 중단될 경우 Rollback 하고, 오류 없이 실행되면 commit 을 하는 실행의 단위를 트랜잭션이라 한다. 결과적으로 한 번 질의가 실행되면 '모두 수행되거나' '모두 수행되지 않는' 작업 수행의 논리적 단위이다. 참고

NoSQL

Not only SQL

정의

Relational 하지 않은, 다른 형태의 데이터 저장 기술. Schema 가 없는 경우가 많음.

특징

테이블 간 관계가 따로 정의되지 않는다. 트랜잭션이 RDB 보다는 약하게 지원된다.
참고
- MongoDB transaction 공식문서
- NoSQL에서도 트랜잭션 개념이 적용될까?

도입 이유

기술의 발전과 웹 사용량 증가로 인해 Data와 트래픽이 폭증하는 바탕 속에서, RDB가 해당 데이터를 담을 경우 성능이 느려진다. 이 때 성능 향상을 위해서는 장비를 더 좋은 장비로 교체하는 방법밖에 없었다. 이런 식의 scale-up 은 비용 폭증을 불러왔기에, 데이터 일관성을 포기하는 대신 여러 대에 데이터를 나누어 보관하는(Scale-Out) 것을 목표로 하여 등장했다.

NoSQL 의 분류

1. Key-Value Model

특징

Key와 Value 를 쌍으로 저장한다.
값(Value)에는 무엇이든 들어갈 수 있다.
대표적인 NoSQL Key-Value Model 로는 Redis, Riak, Amazon Dynamo DB 가 있다.

2. Document Model

특징

Key-Document 형태로 저장된다.
Value에 계층적 형태인 Document 가 저장된다는 점에서 Key-Value 모델과 차이를 가진다. Document 는 하나의 단위로 저장된다. 그렇기에 하나의 객체와 그 구성요소는 여러 테이블이 아난 하나의 Document 에 저장된다.
관계 매핑을 따로 지원하지 않는데, 관계된 내용까지 모두 Document 내에 저장하기 때문이다. (cf. RDB 는 관계된 내용을 fk를 이용해 연결한다.)
질의 결과는 xml 혹은 JSON 형태로 출력된다.

RDBMS - NoSQL 장단점

RDBMS

장점

스키마에 따라 Data 가 저장되기 때문에, 명확한 DB 구조가 보장된다. 데이터 중복 없이 한 번만 저장하면 다양한 곳에서 해당 데이터를 이용할 수 있다. (관계는 fk로 연결되기 때문이다.)

단점

테이블 간 관계가 많아질 경우, 시스템이 커질수록 JOIN 이 많은 복잡한 쿼리를 사용하게 된다.
성능을 향상하기 위해서는 서버 성능을 향상시켜야 하는데, 이러한 Scale-up 은 비용을 급격하게 늘린다.
- 샤딩(sharding)으로 ACID를 준수하며 RDB를 수평적으로 확장하는 것은 매우 까다로운 작업이다.

NoSQL

장점

Schema 가 없어 데이터 구조 변경이 용이하다. 언제든 데이터를 조정하고, 새로운 필드를 추가/제거 할 수 있다.
관계된 내용을 전부 Document 에 저장하기 때문에 조회에 유리하다.
데이터의 분산에 용이하기 때문에, 데이터를 나누어 저장하는 Scale-out 을 통한 성능 향상이 쉽다.

단점

데이터가 중복되어 있기 때문에, 어떤 데이터 하나를 수정하면, 관련된 모든 컬렉션을 조회하고 데이터를 수정해야 한다. (수정에 비용이 많이 든다.)
스키마가 따로 없기 때문에 DB가 데이터의 구조를 보장하지 않는다.

선택 기준

RDB: 구조가 명확하고, Schema 가 중요할 경우 선택. 트랜잭션을 통해 데이터의 무결성을 보장해야 할 경우 또한 RDB 사용이 요구된다. 중복된 데이터가 없기 때문에, 관계맺는 데이터가 자주 변경될 경우 적합하다.
NoSQL: 정확한 데이터 구조를 알기 어렵고, 데이터 구조가 변경/확장될 경우 사용한다. Update 가 자주 이뤄지지 않을 경우 또한 사용할 수 있다. (수정에 비용이 많이 들기 때문) 막대한 데이터를 저장해야 해서 Scale-Out 이 필요한 경우에도 사용한다.