[DB] DB 선택 가이드
서론
요즘 DB가 엄청 많아지는 바람에 어떤 프로젝트에는 어떤 DB가 잘 맞는지 잘 모르는 경향이 있다. 따라서 오늘은 DB 선택 가이드에 대해서 포스팅해보겠다.
사실 DB 선택 가이드라고 거창하게 말하긴 했지만 실제로는 프로젝트에 맞는 DB를 선택할 수 있도록 각 DB의 장단점을 풀어놓는 것에 불과하다.
그럼 시작하겠다.
DB의 종류
DB는 크게 2종류로 나눌 수 있다.
- RDBMS (Relational Database Magement System)
- NoSQL
RDBMS
먼저 RDBMS에 대해서 살펴보겠다. RDBMS는
관계형 데이터베이스 관리 시스템을 의미하는데, 이는 관계형 데이터 모델을 기초로 두고 모든 데이터를 2차원 테이블 형태로 표현하는 DB이다.RDBMS는 구성된 테이블이 다른 테이블들과 관계를 맺고 모여있는 집합체로 이해할 수 있다. RDBMS에서는 이러한 관계를 표현하기 위해
외래 키라는 것을 사용한다.이
외래 키를 이용하여 테이블 간 Join이 가능하다는 것이 RDBMS의 가장 큰 특징이다.
NoSQL
NoSQL이란 Not Only SQL의 약자로 테이블 간 관계를 정의하지 않는 방식의 데이터 저장 기술을 사용한다.
하나의 테이블에 모든 데이터가 들어가고, 테이블 간의 관계를 정의하지 않아 일반적으로 테이블 간 Join도 불가능하다.
NoSQL은 기술의 발전으로 인한 데이터와 트래픽이 기하급수적으로 증가함에 따라 RDBMS의 단점인
성능을 향상시키기 위해서는 장비를 업그레이드해야 하는 Scale-Up의 특징이 비용을 기하급수적으로 증가시키기 때문에 데이터 일관성은 포기하되 비용을 고려하여여러 대의 서버에 데이터를 분산하여 저장하는 Scale-Out을 목표로 등장했다.
1. Key-Value DB
Key-Value DB는 데이터가 Key와 Value의 쌍으로 저장된다.
Key는 Value에 접근하기 위한 용도로 사용되며, 값은 어떠한 형태의 데이터라도 담을 수 있다.
간단한 API를 제공하는 만큼 질의의 속도가 굉장히 빠른 편이다.
ex) Redis, Riak, Amazon Dynamo DB 등
2. Document DB
Document DB는 언뜻 보기엔 Key-Value DB와 비슷하지만, Value 대신 계층적인 형태인 Document가 저장된다.
객체와 관계 사이의 매핑이 필요하지 않다.
검색에 최적화된 모델이다.
사용이 번거롭고 쿼리가 SQL과는 다르다.
ex) MongoDB, CouthDB 등
3. Wide Column DB
이전의 모델들이 Key-Value 값을 이용해 필드를 결정했다면, 이 모델은 키에서 필드를 결정한다.
Key는 Row와 Column-family, Column-name을 가진다.
연관된 데이터들은 같은 Column-family 안에 속해 있으며, 각자의 Column-name을 가진다.
저장된 데이터는 하나의 커다란 테이블로 표현이 가능하며, 질의는 Row, Column-family, Column-name을 통해 수행된다.
ex) HBase, Hypertable 등
4. Graph Database
데이터를 Node와 Edge, Property와 함께 그래프 구조를 사용하여 데이터를 표현하고 저장한다.
개체와 관계를 그래프 형태로 표현한 것이므로 관계형 모델이라고 할 수 있으며, 데이터 간의 관계가 탐색의 키일 경우에 적합하다.
SNS에서 적합하고, 연관된 데이터를 추천해주는 추천 엔진이나 패턴 인식 등의 DB로도 적합하다.
ex) Neo4J
RDBMS와 NoSQL의 장단점
RDBMS
장점
- 명확한 데이터 구조
- 중복 방지
단점
- 시스템이 커질 경우 Join문이 많은 복잡한 쿼리 발생 가능
- 성능 향상을 위해서는 서버의 성능을 향상시켜야 하는 Scale-Up만을 지원
- 스키마로 인한 유연하지 못한 데이터
NoSQL
장점
- 스키마의 부재로 유연하며 자유로운 데이터 구조
- 데이터 분산이 용이하며 Scale-Out 또한 지원
단점
- 데이터 중복 가능
- 불명확한 데이터 구조
그래서 뭘 사용해야 되는데?
RDBMS는 데이터 구조가 명확하며 변경될 여지가 없으며, 명확한 스키마가 포인트인 경우 사용하는 것이 바람직하다. 또한 중복 데이터가 없어 변경이 용이하기 때문에 관계를 맺고 있는 데이터가 자주 변경이 이루어지는 시스템에 적합하다.
NoSQL은 정확한 데이터 구조를 알 수 없고 데이터가 변경/확장이 될 수 있는 경우에 사용하는 것이 좋다. 하지만 데이터 중복이 발생할 수 있으며, 중복된 데이터가 변경될 시에는 모든 컬렉션에서 수정을 해야 하는 번거로움이 있다. 따라서 NoSQL은 Update가 자주 일어나지 않는 시스템이 좋으며 막대한 데이터로 인한 Scale-Out을 해야되는 시스템에 적합하다.