RDB와 NoSQL

1. RDB(Relational Database, 관계형 데이터베이스) 

데이터를 테이블(표) 형태로 저장하고 SQL을 사용하는 데이터베이스.

테이블 간의 관계로 데이터를 표현할 수 있다. (테이블 간 외래키를 사용하여 JOIN할 수 있음)

ACID 법칙 따름.

 

장점

명확한 데이터 구조 보장.

정규화된 데이터 처리에 적합.

데이터 중복 없음.

중요한 트랜젝션이 필요한 곳에 사용하기 적합(ex. 금융).

 

단점

수평적 확장이 어렵다.  

(수평적 확장 방식으로 테이블을 여러 컴퓨터에 분산해서 관리한다면 중재를 해야하는데,

중재가 비효율적이라 수직적 확장을 하는 것이 더 낫다.)  

테이블이 많아지는 경우 JOIN이 복잡해진다.

스키마에 따라야 한다 => 데이터를 유연하게 다루기 힘들다.

2. NoSQL(Not Only SQL, Non-relational Database, 비관계형 데이터베이스)

SQL을 사용하지 않는 데이터베이스.

RDB 테이블 외의 다른 방식으로 데이터를 저장한다. 

테이블 간의 관계를 정의하지 않는다 => 테이블 JOIN 불가능.

 

장점

수평적 확장(scale-out)이 쉽다.

스키마가 없다 => 데이터 구조 변경이 쉽다.

비정형적 데이터 처리에 유리하다.

대량의 데이터를 빠르게 처리하기에 적합하다.

 

단점

명확한 데이터 구조가 보장되지 않음.

데이터 무결성을 보장하지 않음.

데이터 중복이 발생할 수 있다 => 중복된 데이터 수정 시 모든 컬렉션에서 수정해야 함

업데이트가 많지 않은 경우 사용하는 것이 좋다.

 

수평적 확장

컴퓨터를 추가해서 성능을 개선하는 방식.

수평적 확장을 하면 컴퓨터마다 동일한 데이터를 복제(=레플리카)해서 나누어 가진다.

라우터가 요청을 받으면 각 레플리카 상태를 확인한 후 현재 처리 가능 속도가 가장 빠른 곳으로 보내준다.

따라서 읽기 속도가 빠르다.

 

하지만 쓰기(쓰기, 수정, 삭제) 작업에는 단점이 있다.

=> 레플리카마다 업데이트를 해야 한다.

=> 동기화 시 레플리카별로 딜레이가 발생하기 때문에 일관성을 유지하기가 어렵다.

 

데이터의 정확성보다 빠르게 읽는 것이 중요할 때, 쓰기보다 읽기가 빈번할 때 사용한다.

(ex. SNS)

 

1) Key-value Database

데이터를 key, value 쌍으로 저장.

value에는 어떤 형태의 데이터든 저장 가능.

검색 속도가 빠르다.

ex) Redis, Amazon Dynamo DB

 

2) Document Database

데이터를 key, document 형태로 저장.

document는 객체와 유사한 형태를 갖는다.

검색 속도가 빠르다.

SQL 쿼리를 사용하지 않으며,

쿼리 결과가 JSON이나 xml로 출력된다.

ex) MongoDB

 

3) Wide column Database

데이터를 테이블에 저장은 하는데

칼럼 형태가 고정되어 있지 않다.

ex) HBase, Hypertable

 

4) Graph Database

그래프 구조로 데이터를 저장.

데이터 간 관계를 탐색하는 경우에 적합.

SNS에서 친구찾기, 패턴 인식, 연관된 데이터 추천 등에 유리함.

ex) Neo4J