🐰 요약 🐰
RDBMS는 SQL에 의해 저장되며 정해진 스키마에 따라 데이터를 저장하는 관계형 데이터베이스 시스템입니다.
테이블 간 외래 키를 이용한 join이 가능하며, 명확한 스키마로 데이터 구조를 보장하고 중복없이 저장 가능하다는 장점이 있습니다.
그러나 시스템이 커질 경우 복잡한 join 쿼리와 스케일 업 비용, 스키마 변경이 어렵다는 단점이 있습니다.
NoSQL은 테이블 간 관계를 정의하지 않으며 비정형 데이터를 지원하는 시스템입니다.
다양한 유형(Key-Value, Document, Graph, Column)이 있으며, 유연한 데이터 구조와 데이터 확장이 용이하다는 장점이 있습니다.
하지만 스키마의 부재로 인해 정확한 데이터의 구조를 알 수 없고 중복된 데이터 등의 단점이 있습니다.
👉 RDBMS
- SQL에 의해 저장되고 있으며 정해진 스키마에 따라 데이터를 저장
- 모든 데이터를 2차원 테이블 형태로 표현하는 데이터베이스
- 관계형 데이터베이스 관리 시스템
- 테이블 간 외래 키를 이용해서 테이블 간 join이 가능함
- 데이터 update가 많을 때 유리
- 장점
- 정해진 스키마에 따라 데이터를 저장하여야 하므로 명확한 데이터 구조를 보장
- 각 데이터를 중복없이 한 번만 저장할 수 있음
- 단점
- 테이블 간 관계를 맺고 있어 시스템이 커질 경우 JOIN문이 많은 복잡한 쿼리가 만들어질 수 있음
- 성능 향상을 위해 Scale-up만을 지원하므로 비용이 기하급수적으로 늘어날 수 있음
- 스키마로 인해 데이터가 유연하지 못함 → 스키마가 변경될 경우 번거롭고 어려움
- 명확한 스키마가 중요한 경우, 중복된 데이터가 없어 변경이 용이하기 때문에 관계를 맺고 있는 데이터가 자주 변경이 이루어지는 시스템에 적합
👉 NOSQL
- 테이블 간 관계를 정의하지 않음
- 비정형 데이터를 저장할 수 있도록 지원
- update가 적고 조회가 많을 때 유리
- Key-Value DB
- Key-Value 방식으로 데이터를 저장
- Key값은 모든 데이터 타입을 수용할 수 있고, 중복되지 않는 유니크한 값
- 간단한 구조인 만큼 속도가 빠른 편
- Redis, AWS DynamoDB, Riak 등
- Document DB
- Key-Value에서 확장된 방식으로, Key-Document 형태로 저장
- 장점
- Document는 계층적인 타입(JSON, XML)으로 저장
- JSON 타입을 사용하므로 HTTP 기반의 웹 서버의 경우 데이터를 편리하게 주고받을 수 있음
- MongoDB, Couch DB 등
- Gragh DB
- 데이터를 Node와 Edge, Property와 함께 그래프 구조를 사용하여 데이터를 저장
- 객체와 관계를 그래프 형태로 표현한 것으로 관계형모델이라고 할 수 있으며, 데이터 간의 관계가 키일 경우에 적합
- SNS, Network Diagrams 등에 사용되고, SNS에서 함께 아는 친구 찾기, 추천 등 연관된 데이터를 추천해주는 엔진이나 패턴 기능에 사용
- Neo4j 등
- Column DB
- Key, Value와 유사한 형태
- 데이터가 내부에서 Key를 기준으로 오름차순 저장되는 차이점이 있음
- 장점
- Order by를 제공하지 않는 NoSQL에서 다양한 방법으로 활용할 수 있음
- 이전의 모델들이 Key-Value값을 이용해 필드를 결정했다면, 이 모델은 키에서 필드를 결정
- 키는 Row와 Colummn-family, Column-name을 가짐
- 연관된 데이터들은 같은 Column-family 안에 속해 있으며, 각자의 Column-name을 가짐
- 관계형 모델로 설명하자면 어트리뷰트가 계층적인 구조를 가지고 있음
- 저장된 데이터는 하나의 커다란 테이블로 표현이 가능하며, 질의는 Row, Column-family, Column-name을 통해 수행됨
- HBase, Hypertable 등
- 장점
- 스키마가 없기 때문에 유연하며 자유로운 데이터 구조를 가질 수 있음
- 언제든 저장된 데이터를 조정하고 새로운 필드를 추가할 수 있음
- 데이터 분산이 용이하며 성능 향상을 위한 Scale-up 뿐만이 아니라 Scale-out 또한 가능
- 단점
- 데이터 중복이 발생할 수 있으며 중복된 데이터가 변경될 경우 수정을 모든 컬렉션에서 수행해야함
- 스키마가 존재하지 않기에 명확한 데이터 구조를 보장하지 않으며 데이터 구조 결정하기 어려움
- 정확한 데이터 구조를 알 수 없고 데이터 확장이 될 수 있는 경우, update가 많이 이루어지지 않는 시스템, 막대한 데이터를 저장해야 하는 시스템에 사용하는 것이 좋음
