[데이터베이스] SQL과 NoSQL



사실 SQL과 NoSQL를 처음들었을 때, SQL이 RDBMS를 의미하는 것 같은데 왜 SQL이라고하지..? RDBMS와 NoSQL이 더 어울리지 않나 ? 라는 생각을 했습니다. 그래서 곰곰히 생각해봤는데 SQL(Structured Query Language)은 RDBMS의 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어이기 때문에 그 자체적으로 관계DB의 의미를 내포하고 있다고 생각했습니다. 그리고 SQL과 NoSQL이 서로 개념적으로 상이한 부분이 있기 때문에 SQL와 NoSQL이라고 많이들 말하지 않아 생각합니다.

 

이번 게시글에서는 SQL와 NoSQL에 대해 간략하게 알아보고 이 둘의 차이점, 각각 언제 사용해야 하는지에 대한 부분 위주로 다루겠습니다.

---

SQL

SQL(관계DB)는 스키마가 정의되어야 합니다. 여기서 스키마란 데이터베이스의 데이터 구조와 제약조건을 정의한 것입니다. 예를 들어 유저테이블의 name속성의 데이터 타입을 문자열로 했다면 정수값이 들어갈 수 없으며 이는 처음 유저 테이블을 정의할 때 정했기 때문에 수정할 수 없습니다(사실 바꿀 수 있지만 신중하게 선택해야 합니다). 따라서 유저 테이블에 정의하지 않은 속성/데이터 타입을 넣을 수 없습니다. 

 

또한 각 테이블은 논리적인 관계를 가지며 테이블 간에 join을 하여 데이터를 가져올 수 있으며 데이터의 무결성을 보장할 수 있다. 예를 들어 회원, 게시글 테이블에는 각각 회원ID 속성이 있으며 회원ID로 유저정보, 해당유저의 게시글을 가져올 수 있으며 각 테이블의 회원ID값은 무결성을 보장할 수 있다.

---

NoSQL

SQL에서는 테이블관의 관계가 존재했지만, NoSQL에서는 관계, join이 존재하지 않으며 NoSQL의 No가 non-relational(관계가 없는)을 의미한다. SQL처럼 정해진 형식/데이터타입에 맞추지 않아도 되며 서로 다른 데이터구조를 넣어도 상관없다.

 

각각의 데이터는 json과 비슷한 형태로 저장되며 하나의 데이터를 ducoment, ducoment가 모여서 collection, collection이 모여서 DB가 된다. 이와는 반대로 SQL의 경우 tuple이 모여 table, table이 모여 DB가 된다.

---

SQL vs NoSQL

앞서 SQL와 NoSQL에 대해 알아보았습니다. 그렇다면 이 둘을 각각 어떤 차이점을 보이는지 보겠습니다.

 

1. 확장성(scalability)

확장성은 DB에서 처리할 수 있는 읽기/쓰기 요청수를 의미하며, 수평적 확장성과 수직적 확장성이 있습니다.

 

1) 수평적 확장성 - NoSQL

더 많은 서버가 추가됨에 따라 처리량과 저장공간이 추가됨을 의미합니다. 그러면서도 응답속도는 보장됩니다

 

2) 수직적 확장성 - SQL

서버의 성능을 향상시키는 것으로 SSD, CPU 등의 부품을 추가하거나 업그레이드 하는 것을 의미합니다. 이 경우 확장하는데 까다로우며 하드웨어의 업그레이드는 한계가 존재합니다.

 

2. 쿼리 언어

SQL의 경우 쿼리언어가 있습니다. RDBMS마다 조금씩은 다르지만 전체적인 흐름은 같습니다. 데이터들이 정형화 되어있고 이들간의 join하는 형태로 데이터에 접근한다면 SQL이 더 잘어울립니다.

 

반면에 페이스북이나 인스타그램처럼 유저가 폭발적으로 증가할 수 있으면서도 간단한 데이터에 대해서는 NoSQL이 더 잘어울립니다.

3. 강한 스키마 vs 약한 스키마

SQL의 경우 테이블을 설계할 때 속성의 개수, 데이터 타입을 모두 정의하기 때문에 데이터를 조작할 때 정의된 규칙에 따라야 합니다. 반면에 NoSQL의 경우 따로 정의된 규칙이 없기 때문에 자유롭게 데이터를 넣을 수 있습니다. 하지만 생각없이 넣게 되면 지저분해지는 단점이 있습니다.

 

4. CAP

CAP이론은 분산 시스템에서는 CAP 세 가지 속성 모두를 만족하는 것은 불가능하며, 오직 2가지만 만족할 수 있다는 것을 의미합니다. SQL의 경우 CA를 만족하며 NoSQL의 경우 PA or PC를 만족합니다.

 

- C : Consistency

특정 시점에서 반드시 동일 데이터가 존재해야 하는 것을 의미합니다. 

 

- A : Availability

하나의 서버가 다운돼도 다른 서버가 처리를 계속하는 것을 가리킵니다.

 

- P : Partition tolerance

서버를 늘림으로써 성능을 확장할 수 있는 것을 의미합니다.

 

RDBMS에서는 데이터 일관성과 안정성을 가장 중시하므로 C와A를 최대한 지키려고 합니다. 이 아키텍처는 '중요한 데이터는 한 곳에 가지고 있자' 라는 생각에 기반을 두고 있습니다. 한 곳에 데이터를 모으기 때문에 P를 달성하기 어렵다는 것이 약점입니다. 또한 일관성을 중시하기 때문에 C를 확보하기 위한 '배타적 제어', '락 처리'가 병목 지점이 되기 쉽습니다. 또한 P는 원래 약하기 때문에 이것을 달성하려고 하면 구조가 복잡해져서 안정성이 떨어지게 되는 위험성이 따릅니다.

 

NoSQL의 경우 데이터 저장 방식에서는 A와 P를 중시하는 경우가 많습니다. '가능한 많은 서버를 배치해서 성능을 좋게 하자'라는 방식(스케일 아웃)으로 데이터가 흩어져서 C를 달성하기가 어렵게 됩니다. 또한 P를 확보하기 위한 서버 간 데이터 '복제'가 병목 지점이 되기 쉽습니다. C에 약하기 때문에 애플리케이션 측에 일관성 및 일치성을 확인하는 구조를 만들어 두어야 합니다.

5. ACID vs BASE

1) ACID - SQL

Atomicity : 원자성

Consistency : 일관성

Isolation : 고립성

Durability : 영구성

 

ACID는 트랙잭션의 특징을 의미하는데, SQL은 데이터의 무결성을 중요시 합니다. 예를 들어 어떤 트랜잭션을 수행하다 장애가 발생하면 해당 트랙잭션을 rollback하고 모든 트랜잭션이 성공적으로 수행되면 commit을 진행합니다(all-or-nothing)

 

예를 들어 A가 B에게 송금하는 경우 송금하는 도중 장애가 생기면 A는 돈이 빠졌는데도 불구하고 B에게 돈이가지 않았다. 이런 경우 아예 송금하기 전 상태로 rollback할 수 있습니다.

2) BASE - NoSQL

Basically Available : 기본적으로 사용가능하고,주서버가 안되더라도 백업서버는 동작한다

Soft-state : 데이터를 관리해주지 않으면 사라진다

Eventually consistency : 지금 당장은 아니더라도 언젠가는 데이터가 일관성을 가진다

 

BASE는 ACID보다 좀 더 유연하며 ACID와 같이 데이터의 일관성은 좀 약하지만 사용성을 우선적으로 합니다. 예를 들어 페이스북의 경우 내가 게시글을 작성했다 하더라도 다른 사람이 바로 볼 수 있으면 좋지만 꼭 그렇지 않더라도 큰 영향은 없습니다. 1~2초후에 내 게시글을 볼 수 있어도 크게 문제가 없다는 말이죠. 즉, 현재 정확한 데이터가 아니더라도(업데이트 전의 데이터) 사용자가 데이터를 사용할 수 있도록 합니다.