SQL vs NOSQL (관계형데이터베이스 비 관계형데이터베이스)

SQL vs NOSQL 

관계형 데이터베이스, 비관계형 데이터저장소인 NOSQL (문서 데이터베이스)
선택 기준

---

MSA 환경에서 개발을 하다보니 새 서비스가 나올때 마다
이 서비스는 어떤 데이터베이스를 사용하는 것이 좋을까? 고민하는 경우가 많아지는 것 같습니다.

저는 크게 RDB(관계형 데이터베이스), NOSQL(비 관계형, 문서 데이터베이스) 중에 고민하였고
두 데이터베이스 중 선택에 따른 Trade off 몇가지를 정리해보려합니다.

1. 일대다, 다대다

일대다 - NOSQL

다대일, 다대다 - SQL

애플리케이션에서 데이터가 문서와 비슷한 구조라면 (일대다 관계 트리, 보통 한번에 전체트리를 적재)
문서 모델을 사용하는것이 좋습니다. 
관계형 모델은 문서와 비슷한 구조를 여러 테이블로 나누어 저장하게되므로 다루기 힘든 스키마와
복잡한 애플리케이션 코드를 발생시킵니다.

ex) 간단한 이력서
문서모델 - 각 항목마다 값이 채워넣어진 형태 그대로 저장가능

관계형모델 - 인적정보 테이블, 지역테이블, 직업테이블 등 여러 테이블에 나누어 저장

ex) 어떤 시점에 발생한 이벤트를 기록하는 문서 데이터베이스 사용 분석 애플리케이션에서는 다대다가 결코 필요없음.

* 문서모델은 관계형보다 좀더 객체의 형태와 일치하고 직관적임
이력서를 JSON으로 표현한다면 확실히 직관적이다. 데이터가 특정 테이블의 id로 연결되어 표현된 이력서는 직관적이지 않다.

문서형 모델에는 제약이있습니다. 문서 내 중첩항목을 바로 참조할 수 없습니다.
ex) '사용자 251의 직위 목록의 두 번째 항목' 처럼 표현해야함

하지만 너무 깊게 중첩되지 않는다면 일반적으로 문제가 되지 않습니다.

 

애플리케이션에서 다대다 관계를 사용하면 문서 모델은 조인 지원이 미흡하기 때문에 매력이 떨어집니다.
비정규화로 조인의 필요성을 줄일 수는 있겠지만 애플리케이션에서 비정규화된 데이터의 일관성 유지를 위해 추가작업이 필요합니다.
조인을 흉내낼 수도 있지만 이런경우 문서모델을 사용하는 것은 훨씬 더 복잡한 애플리케이션 및 나쁜성능으로 이어질 수 있습니다.

 

ex) 지역이름이 강원도->약원도로 변경되었다면
문서모델 - 모든 문서의 지역항목에 강원도라는 지역을 약원도로 변경하는 작업이 필요
관계형모델 - 지역테이블에서 강원도를 약원도로 변경

ex) 지역이름의 번역본을 제공하는 경우
문서모델 - 한 컬렉션에 저장한다면 모든 문서에 지역항목에 한글 영어 일어 등 지역명이 저장되어야 할것이며 중복데이터가 크게 발생한다. 다른방법으로는 결국 따로저장하여 관계를 맺고, 조인을 흉내내야 할것

관계형모델 - 지역 id만을 참조할 것이므로 id와 관계를 가진 번역본 테이블에서 맞는 언어를 찾아 제공

 

결국, 애플리케이션에서 데이터가 어떻게 사용될 것인지 분석이 선행되어야 합니다.

 

2. 스키마 유연성

SQL - 데이터가 갖는 특정 구조를 명시적으로 강요한다. (쓰기에 강요됨) 변화 요구사항에 맞춰 편하게 변경 불가
NOSQL - 암시적이다. (읽기에서 다뤄짐) 유연하게 변경 가능

문서 데이터베이스는 종종 스키마리스로 불리지만 이는 오해의 소지가 있습니다.
애플리케이션은 데이터가 특정 구조를 갖는다고 가정할 가능성이 높습니다.
관계형 모델은 '쓰기 스키마' (RDB의 정통적인 접근 방식으로 스키마는 명시적, DB는 쓰여진 모든 데이터가 스키마를 따르고있음을 보장)

문서모델은 '읽기 스키마' ( 데이터구조는 암묵적이고, 읽을 때만 해석됨) 입니다.

접근 방식간 차이는 애플리케이션이 데이터 타입을 변경하고자 할 때 뚜렷하게 나타납니다.
예를들어 현재 name 필드에 유저의 풀네임을 저장중이고, 성과 이름을 분리해서 저장하고싶다고 가정해봅니다.
NOSQL - 이제부터 성과 이름을 분리해서 저장
읽는 부분에 처리하는 코드를 추가

if(user && user.name && user.first_name){
	// 이전 데이터에는 first_name이 없음
	user.first_name = user.name.split(" ")[0];
}

SQL - 테이블 스키마 변경 및 데이터 마이그레이션 작업 필요

ALTER TABLE ...
UPDATE users SET ...

스키마 변경은 느리고 중단시간을 요구할 수 있기 때문에 위험부담이 있음.

애플리케이션에서 오류발생 가능 (ex. JPA 사용시 Entity와 테이블 매핑 불일치 )

 

사용자가 제어할 수 없고 언제나 변경 가능한 외부 시스템에 의해 데이터 구조가 결정되는 등 

NOSQL은 컬렉션 안의 항목이 어떤 이유로 모두 동일한 구조가 아닐때 유리합니다.
다른 여러 유형의 오브젝트가 있고 유형별로 자체 테이블에 넣는것은 실용적이지 않습니다.

하지만 모든 레코드가 동일한 구조이며 예상 가능하다면 스키마는 문서화와 구조를 강제하기 위한 유용한 매커니즘입니다.

 

3. 데이터를 위한 질의 언어

SQL - 선언형 질의언어 (데이터베이스에서 자동으로 최적화할수 있는 여지가 많음)
NOSQL - 명령형 언어 (명령어를 특정 순서로 수행하기 때문에 병렬처리등 최적화 어려움)

 

SQL은 선언형 질의어이고 일반적인 프로그래밍 언어는 명령형 코드입니다.
예를 들어 동물 종 목록에서 고양이만 반환한다고 가정하면 아래와 같습니다.

SELECT * FROM animals WHERE family = 'cats';

function getCats(animals){
	var cats = [];
    for(  ){
     // animals에서 cat을 찾아 배열에 담음
    }
    return cats;
}

선언형 질의언어는 목표를 달성하고자하는 방법이 아니라 결과의 충족조건과 데이터를 어떻게 변환할 것인지만 지정합니다.
어떤 색인을 사용하여 어떤 순서로 실행하고, 최적화 할지는 데이터베이스 시스템의 질의 최적화기의 몫 입니다.

반면, 명령형 언어는 특정 순서로 특정연산을 수행하도록 컴퓨터에 지시합니다. 따라서 개발자가 명령어 수행에 최적화된 코드를 고려하여
개발하여야 합니다.

---

4. 확장성 (Scalability)

 

SQL - 수직적 확장 (Vertical)
NOSQL - 수평적 확장 (Horizontal)

 

RDB에서는 데이터가 저장되는 방식 때문에 일반적으로 서버의 성능을 늘려 확장을 합니다.

즉, 수직적으로 확장합니다. (CPU 업그레이드, 메모리 업그레이드 등)

같은 테이블 스키마를 가진 데이터를 다수의 데이터베이스에 분산하여 저장하는 방법인 '샤딩(Sharding)'의 개념이 존재하기는

하지만 제한이 있으며 구현하기 어렵습니다.

 

NOSQL은 기본적으로 샤딩을 지원하여 여러 서버에 분산하여 데이터를 저장할 수 있습니다.
따라서, NOSQL에서는 서버의 대수를 늘려 확장이 가능합니다. 즉, 수평적으로 확장합니다.

 

대부분 서버를 더 추가하는 방식의 수평적 확장이 서버 하나에 자원을 더 추가하는 수직적 확장 보다 더 빠르고 경제적입니다.

---

5. ACID / CAP

SQL - ACID (atomic, consistent, isolated and durable) 트랜잭션이 안전하게 수행됨을 보장
NOSQL - CAP (Consistency, Availability and Partition Tolerance) 3가지 중, 두가지만 충족이 가능

RDB는 데이터의 ACID(atomic, consistent, isolated and durable)를 보존하도록 구현되었기 때문에, 데이터의 무결성을 보장합니다.

하지만 NoSQL은 ACID 속성을 가지지 못하므로, CAP (Consistency, Availability and Partition Tolerance) 방법을 따릅니다.

CAP 이론은 분산시스템 환경에서 일관성, 가용성, 분리내구성 중 두가지만 충족가능하다는 이론입니다.

NoSQL DB들은 수평적으로 확장이 가능하고, 수평적으로 확장된 서버들 사이에 데이터 동기화 문제가 발생하기 때문에 데이터의 무결성이 완벽하게 보장된다고 할 수 없습니다.

하지만 RDB에서 데이터의 삽입/읽기/갱신/삭제 수행시 ACID를 보장하기 위해 NOSQL의 경우보다 더 많은 자원을 소모하므로
이부분도 고려가 되어야 합니다.

 

---

이상으로 데이터베이스 제품 선택에 어떠한점을 고려해야하고, 각 선택에 따른 Trade off를 알아보았습니다.

읽어주셔서 감사합니다.