미니 스케줄러, 영화 리뷰 커뮤니티 프로젝트
해당 프로젝트 들 뿐만 아니라 지금까지의 대부분의 웹 프로젝트 들을 MySQL을 기반으로 사용하여 RDBMS를 기반으로 데이터 간의 관계를 이용해 DB를 설계하였다. 자주 사용할 수록 잘 알고 있어야 하므로 RDBMS에 대한 다시 정리를 하고, NoSQL과의 차이를 알아보자.
RDBMS
DBMS
- Database Management System
- 사용자와 DB 사이에서 사용자의 요구에 따라 정보를 생성해 주고 DB를 관리해 주는 소프트웨어
SQL
- Structured Query Language
- 관계형 DB 관리 시스템의 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어
- 자료의 검색과 관리, DB 스키마 생성과 수정, DB 객체 접근 조정 관리를 위해 고안되었다.
RDBMS
- Relational Database Management System(관계형 데이터베이스 관리 시스템)
- RDB를 관리하는 시스템이며 RDB는 관계형 데이터 모델을 기초로 두고 모든 데이터를 2차원 테이블 형태로 표현하는 데이터 베이스
- 관계형 데이터베이스는 다른 테이블과 관계를 맺고 모여있는 집합체로 이해할 수 있다.
- 외래키를 통해 테이블 간 Join이 가능하다.
NoSQL
-
Not Only SQL
-
RDB 형태의 관계형 데이터베이스가 아닌 다른 형태의 데이터 저장 기술
-
RDBMS와는 달리 테이블 간 관계를 정의하지 않는다.
-
데이터 테이블은 그냥 하나의 테이블이며 따라서 일반적으로 테이블 간 Join도 불가능
-
데이터와 트래픽이 증가함에 따라 RDBMS에 단점인 성능을 향상시키기 위해 등장
-
데이터 일관성은 포기하되 비용을 고려하여 여러 대의 데이터에 분산하여 저장하는 Scale-Out을 목표
-
Document 기반의 MongoDB는 NoSQL의 대표적인 한 종류
-
Key-Value Database
* 데이터가 Key와 Value의 쌍으로 저장- Key 값은 어떠한 형태의 데이터라도 담을 수 있다. (이미지, 비디오 가능)
- 간단한 API를 제공하는만큼 질의의 속도가 굉장히 빠름
- Redis, Riak, Amazon Dynamo DB 등
-
Document Database
* Key와 Document의 형태로 저장- Key-Value 모델과 다른점이라면 Value가 계층적인 형태인 도큐먼트로 저장되는 것. 객체 지향에서의 객체와 유사하며, 이들은 하나의 단위로 취급되어 저장된다. 다시 말해 하나의 객체를 여러 개의 테이블에 나눠 저장할 필요가 없어진다는 뜻.
- 객체-관계 매핑이 필요하지 않다. 객체를 Document의 형태로 바로 저장 가능
- 검색에 최적화(Key-Value 모델의 특징과 동일)
- 사용이 번거롭고 쿼리가 SQL과 다르다.
- MongoDB, CouthDB 등
-
Wide Column Database
* Column-family Model 기반의 Database- 이전의 모델들이 Key-Value 값을 이용해 필드를 결정했다면, 이 모델은 키에서 필드를 결정한다. 키는 Row(키 값)와 Column-family, Column-name을 가진다. 연관된 데이터들은 같은 Column-family 안에 속해 있으며, 각자의 Column-name을 가진다. 관계형 모델로 설명하지면 어트리뷰트가 계층적인 구조를 가지고 있는 셈이다. 이렇게 저장된 데이터는 하나의 커다란 테이블로 표현이 가능하며, 질의는 Row, Column-family, Column-name을 통해 수행된다.
- HBase 등
-
Graph Database
* 데이터를 Node와 Edge, Property와 함께 그래프 구조를 사용하여 데이터를 표현하고 저장하는 DB- 개체와 관계를 그래프 형태로 표현한 것이므로 관계형 모델, 데이터 간의 관계가 탐색의 키일 경우에 적합
- 페이스북이나 트위터 같은 SNS에서 적합, 연관된 데이터를 추천해주는 추천 엔진이나 패턴 인식 등의 DB로도 적합
RDBMS와 NoSQL의 장단점
RDBMS
장점
- 정해진 스키마에 따라 데이터를 저장하여야 하므로 명확한 데이터 구조를 보장
- 또한 각 데이터를 중복없이 한번만 저장할 수 있습니다.
단점
- 테이블 간 관계를 맺고 있어 시스템이 커질 경우 JOIN문이 많은 복잡한 쿼리가 만들어질 수 있다.
- 성능 향상을 위해서는 Scale-up만을 지원. 이로 인해 비용이 기하급수적으로 늘어날 수 있다.
- 스키마로 인해 데이터가 유연하지 못하다. 나중에 스키마가 변경될 경우 번거롭고 어렵다.
NoSQL
장점
- 스키마가 없기 때문에 유연하고 자유로운 데이터 구조
- 언제든 저장된 데이터를 조정하고 새로운 필드를 추가할 수 있다.
- 데이터 분산이 용이하며 성능 향상을 위한 Scale-up 뿐만이 아니라 Scale-out 또한 가능.
단점
- 데이터 중복이 발생할 수 있으며 중복된 데이터가 변경될 경우 수정을 모든 컬렉션에서 수행을 해야한다.
- 스키마가 존재하지 않기에 명확한 데이터 구조를 보장하지 않으며 데이터 구조 결정하기 어려울 수 있다.
정리
RDBMS
- 데이터 구조 명확하며 변경될 여지 없으며 명확한 스키마가 중요한 경우에 사용하자.
- 중복된 데이터가 없는 경우(데이터 무결성) 변경이 용이하기에 관계를 맺고 있는 데이터가 자주 변경이 이루어지는 시스템에 적합하다.
NoSQL
- 정확한 데이터 구조를 알 수 없고 데이터가 변경/확장이 될 수 있는 경우에 사용하자.
- 데이터 중복이 발생할 수 있으며 중복된 데이터가 변경될 시에는 모든 컬렉션에서 수정을 해야하기 때문에 Update가 많이 이루어지지 않는 시스템이 좋다.
- 막대한 데이터를 저장해야 하는 시스템에 적합하다.
