SQL과 NoSQL을 비교하기전 어떤놈들인지 먼저 알아보자...

DBMS

DataBase Management System

사용자와 데이터베이스 사이에서 사용자의 요구에 따라 데이터를 생성해주고 데이터베이스를 관리해주는 소프트웨어이다.

SQL

Strucred Query Language

관계형 데이터베이스 시스템에서 데이터를 관리하기 위해 설계된 특수목적의 언어로, 자료의 검색과 관리, 스키마 생성과 수정, 데이터베이스 객체 접근 조정 관리를 위해 고안되었다.

RDBMS

DBMS에서 R이 추가되었는데 여기서 R은 Relation의 약자로 관계를 뜻한다.
이름에서 알 수 있듯 관계형 데이터 모델을 기초로 두고 있으며, 모든데이터를 2차원 테이블 형태(행, 열)로 표현하는 데이터베이스이다. 따라서 관계형 데이터베이스는 다른 테이블들과 관계를 맺고 모여있는 집합체라고 볼 수 있다.
이런 관계를 나타내기 위해 Foreign Key(외래키)를 사용하여 테이블간 JOIN이 가능하다는게 큰 특징이다.

이미지 출처 : Oracle Tutoroals

NoSQL

Not Only SQL

관계형 데이터베이스가 아닌 다른 형태의 데이터 저장기술로, 관계형 데이터베이스와는 다르게 테이블간 관계를 정의 하지 않기 때문에, 데이터테이블은 그냥 하나의 테이블로서 테이블간 JOIN이 불가능 하다.
빅데이터의 등장으로인해 트래픽이 기하급수적으로 증가함에 따라 RDBMS의 단점인 성능을 향상시키기 위해 등장했다.
따라서 데이터의 일관성은 포기하되 비교적 비용이 적게드는 Scale-Out(데이터 분산)의 장점이 있다.

Key-Value DataBase

• Key-Value의 쌍으로 데이터가 저장된다.
• Key 값은 어떠한 형태의 데이터라도 담을 수 있다 (이미지, 비디오 형식도 가능)
• 간단한 API를 제공하는 만큼 질의의 속도가 빠르다는 것이 장점이다.
• Redis, Riak, Amazon Dynamo DB등이 있다.
  

이미지 출처 :Amazon AWS

파티션키는 물리적 공간인 파티션을 특정하는 키

• 스케일이 아무리 커져도 주소를 알고 있어서 빠르게 가져올 수 있다.
• 파티션키로는 일치하는 값만 가져올 수 있고, 조건문으로 작성할 수 없는 이유이기도 하다.

정렬키는 파티션 내에서 정렬하는 기준 값 (검색을 위한 최소의 조건)

• Number, Binary, String 타입을 지원한다. String 이라면 utf-8 기준으로 정렬된다.
• 단순한 (문자열) 인덱스라고 생각하면 될 듯 하다.
• 단순정렬이기 때문에 파티션의 사이즈가 커도 빠르게 가져올 수 있다. (eq, lt, gt 등의 비교 조건과 between, begin_with 만 지원한다)

Document DataBase

• key와 Document 형태로 저장
• key-Value와 다른 점이라면 Value가 계층적인 형태로 저장된다.
  객체 지향에서 객체와 유사하며, 하나의 단위로 취급되어 저장되기 때문에 하나의 객체를 여러개의 테이블에 나눠서 저장할 필요가 없다.
• 객체를 Docunment의 형태로 저장하기 때문에 객체-관계 매핑이 필요하지 않다.
• Key-Value의 특징과 동일하게 검색에 최적화 되어있다.
• 단점으로는 사용이 번거롭고, 쿼리가 SQL과 다르다.
• MongoDB, Couth등이 있다.

이미지 출처 : CouchBase

Wide Column DataBase

• Column-Family Model 기반의 데이터베이스이다.
• key-Value 값을 이용해 필드를 결정하는 것과는 다르게 이 모델은 키에서 필드를 결정한다.
  Key는 Row(키값)와 Column-Family, Column-Name을 가지며, 이렇게 저장된 데이터는 하나의 커다란 테이블로 표현이 가능하다.
  질의는 Row, Column-Family, Column-Name을 통해 수행된다.
• HBase, Hypertable등이 있다.

이미지 출처 : ResearchGate

Graph DataBase

• 데이터를 Node와 Edge, Properaty와 함께 그래프 구조를 사용하여 데이터를 표현하고 저장한다.
• 개채와 관계를 크래프 형태로 표현한 것이므로 관계형 모델이라고도 할 수있으며, 데이터 간의 관계가 탐색의 키일 경우게 적합하다.
• 페이스북이나 트위터같은 소셜네트워크에 적합하고, 연관된 데이터를 추천해주는 추천엔진등의 데이터베이스로도 적합하다고 볼 수 있다.
• Neo4J등이 있다.

이미지 출처 : MathWorks

RDBMS 와 NoSQL의 장단점

RDBMS

장점

• 정해진 스키마에 따라 데이터를 저장해야 하기 때문에 명확한 데이터 구조(일관성)를 보장한다.
• 각 데이터를 중복없이 한번만 저장할 수 있다.

단점

• 테이블간 관계를 맺고 있어 시스템이 커질경우 복잡한 쿼리가 만들어 질 수 있다.
• 성능향상을 위해 Scale-Up만을 지원하기 때문에 비용이 기하급수적으로 늘어날 수 있다.
• 스키마로 인해 데이터가 유연하지 못하고, 스키마가 변경될 경우 수정이 번거롭고 어렵다.

NoSQL

장점

• 스키마가 없어 유연하고, 자유로운 데이터 구조를 가질 수 있다.
• 언제든 저장된 데이터를 조정하고 새로운 필드를 만들 수 있다.
• 데이터 분산이 용이하고 성능향상을 위해 Scale-Up뿐 아니라 Scale-out도 가능하다.

단점

• 데이터 중복이 발생할 수 있으며, 중복된 데이터가 변경될 경우 모든 컬랙션에서 수정해야하는 번거로움이 있다.
• 스키마가 존재하지 않기 때문에 명확한 데이터 구조(일관성)를 보장하지 않아 데이터 구조를 결정하기가 어려울 수 있다.

그럼 무엇을 언제 써야할까?

RDBMS

RDBMS는 데이터 구조가 명확(일관성)하기 때문에, 중복된 데이터가 없어 변경이 용이하기 때문에 관계를 맺고있는 데이터가 자주 변경이 이루어지는 시스템에 적합하다고 볼 수 있겠다.

NoSQL

NoSQL은 정확한 데이터 구조를 알 수 없고 데이터가 변경/확장이 될 수 있는 경우에 사용하는것이 좋다고 볼 수 있다. 하지만 데이터 중복이 발생할 수 있기 때문에 Update가 많이 이루어지지 않는 시스템이 좋다고 볼 수 있다. 또한 Scale-Out이 가능하다는 장점을 활용해 막대한 데이터를 저장해야하는 빅데이터 관련시스템에도 적합하다고 볼 수 있다.

글을 마치며

지난 시간에는 SQL을 배우고 오늘은 NoSQL을 배우게 되었다.
아직 모든 NoSQL을 전부 공부해보고 직접 실습을 해본건 아니지만 둘의 차이점을 찾아보면서 장단점을 알게되었고, 앞으로 진행할 프로젝트에서 어떤 것을 사용해야 좋을지도 이제 감이 잡히는거 같다.