SQL, NoSQL의 차이에 대해 알아보자.
시작에 앞서..
SQL, NoSQL을 언급할 땐 각 단어 뒤에 DB를 붙여야겠다는 생각을 했다.
SQL, NoSQL 비교하기 위해 자료를 구글링하면
SQL은 관계형 DB, NoSQL은 그와 반대되는 비(Non) 관계형 DB 라는 식으로 설명을 한다.
근데 놓칠뻔 했던, 가장 기본적인 개념이 있었다.
SQL은 Structured Query Language의 약자로, 그 자체가 DB가 아니다.
SQL은 관계형 데이터베이스 관리 시스템(RDBMS)의 데이터를 관리하기 위해 설계된
특수 목적의 프로그래밍 언어라고 위키백과는 설명한다.
(RDBMS : relational database management system)
흔히 얘기하는 관계형 DB라는 단어는 RDBMS(ex, MySQL)인 것이고,
SQL은 RDBMS를 설계하는데 사용된 언어이다.
근데 예전부터 DB는 SQL로 만들어졌기 때문에
SQL이 관계형 DB라는 의미로 사용되는 거라 생각한다.
누군가는 사소한 부분이라고 생각할 수 있지만, 정리하고 시작하고 싶어 서두에 남긴다.
물론 아래 정리되는 내용에는 SQL, NoSQL로 언급할 예정이다..
1. 스키마(Schema)
스키마는 DB에 어떤 구조로, 어떤 제약 조건으로 저장 되어야 하는지 정의한 것이다.
(스키마도 자세히 들어가면 정말 한도 끝도 없었다..ㅠ)
SiriusJ님의 블로그를 참고하여 간단히 정리한다.
- 스키마는 데이터베이스의 구조와 제약조건에 관해 전반적인 명세를 기술한 것이다.
- 개체의 특징을 나타내는 속성(attribute), 속성들의 집합으로 이루어진 개체(entity),
개체 간 존재하는 관계(relationship)에 대한 정의와 이들이 유지해야할 제약조건들을 기술한 것이다.- 사용자 관점에 따라 외부, 내부, 개념 스키마로 나뉜다.
- 개념 스키마 : 데이터 베이스의 전체적인 논리적 구조
- 내부 스키마 : 데이터 베이스의 물리적 저장구조
- 외부 스키마 : 사용자에게 보여지는 스키마 (서브 스키마라고도 한다.)
1) SQL - strict schema
[ 출처: academind ]
SQL은 데이터를 저장하기 위해서 스키마가 먼저 정의되어야 한다.
SQL에서는 Table에 데이터가 저장된다.
Table 구조를 보면 excel sheet가 떠오른다.
excel에서 표로 어떤 데이터를 정리한다고 가정하면,
표의 각 항목(ex, id, name)이 Field(혹은 Column)가 되는 것이고,
항목에 맞춰 데이터를 입력한 열이 Recode(혹은 Row)가 된다.
SQL은 표에 어떠한 내용이 들어가는지,
'항목'을 정의하지 않으면 데이터를 저장 할 수 없다.
즉, 위에서 간단히 언급한,
외부/내부/개념 스키마를 정의해야 데이터의 저장을 시작할 수 있다는 얘기이다...
2) NoSQL - no schema
[ 출처: academind ]
NoSQL에서는 Document에 데이터가 저장된다.
JSON 혹은 객체의 형태인 key-value로 데이터가 저장된다.
Document들이 모여 Collection이 되고,
Collection이 모여 Database가 된다.
여기서 중요한 점은 스키마를 정의하지 않아도 된다는 점이다.
그래서 어떤 형식으로 데이터를 저장해야 할지 확신이 서지 않는 상황에서는
NoSQL이 적절한 방법이라고 흔히 말한다.
2. Relations
1) SQL - Relational DataBase
[ 출처: academind ]
SQL에서 중요한 부분은 관계(relation)이다.
User, Products, Orders Table에 데이터들이 나뉘어 저장되어있다.
그러나 Orders 테이블을 보면 Maximilian이 Chair를 구매했다는 것을 알 수 있다.
즉, 관계형 데이터는 각 table 간의 관계(join)을 통해 데이터를 파악할 수 있다.
이러한 점은 데이터를 중복 없이 저장할 수 있다는 것이고,
전체 데이터 하나만 관리하면 되기 때문에 데이터의 정확성을 높일 수 있다.
2) NoSQL - Non-relational DataBase
[ 출처: academind ]
NoSQL에서는 관계(Join) 란 개념이 없다.
(그래서 이름에 붙은 'no'가 붙어있다. 관계형이 '아니'라고ㅎㅎ!)
위의 예시를 보면,
Orders Collection에 관련된 내용이 모두 저장되어 있다.
즉, 확인하고자 하는 데이터가 다 담겨있기 때문에 join을 통해 확인할 필요가 없다.
Users, Products Collection처럼,
다른 Collection이 필요하다면 기존 Collection의 데이터를 일부 복제한다.
그래서 Collection 별로 중복된 데이터가 존재한다.
중복된 데이터는 삭제하거나 업데이트할 때 반영이 되지 않을 수 있어 유의해야한다.
3. Scalability
데이터의 확장은 Vertical(수직적) Scaling, Horizontal(수평적) Scaling 2개로 나눌 수 있다.
1) SQL - Vertical Scaling
SQL은 수직적으로 확장한다.
수직적 향상은 CPU나 RAM 같은 부품을 업그레이드하거나, 하드웨어를 추가하여
서버의 성능을 향상시키는 것을 의미한다.
(하나의 서버의 용량과 성능을 향상하는 것은 일정 수준의 한계가 존재한다.)
2) NoSQL - Horizontal Scaling
NoSQL은 수평적으로 확장한다.
수평적 확장 (Horizontal Scalability)은 더 많은 서버를 추가해서
서버를 전체적으로 분산시키는 것을 의미한다.
(서버의 수를 무한으로 늘리면 DB를 계속 증설할 수 있다.)
Sharding(샤딩)은 같은 테이블 스키마를 가진 데이터를
다수의 DB에 분산하여 저장하는 방법이다.
이 기술을 접목하면 SQL도 수평적 확장을 적용할 수 는 있지만, 실제 구현은 어렵다고 한다.
확장을 고려한다면 수평적 확장으로 구현이 가능한 NoSQL 방식을 적용하는 것이 유리하다.
4. Property
1) SQL - ACID properties
SQL은 ACID 특성을 따른다.
ACID는 DB의 Transaction(트랜잭션)이 안전하게 수행된다는 것을
보장하기 위한 특징이다.
트랜잭션이란 여러 작업들을 하나로 묶은 단위이다.
하나로 묶인 작업들은 모두 실행되거나, 실행되지 않는다. (all-or-nothing)
(트랜잭션의 예시로 많이 나오는게 송금이다.
A은행에서 B은행으로 돈을 보낸다고 할때, A은행에서 출금을 한 순간 시스템이 중지했다.
그럼 B은행으로 송금을 안했기 때문에 A은행에서 출금된 돈은 사라진다...)
- Atomicity(원자성)
: 트랜잭션의 작업이 부분적으로 실행되거나 중단되지 않는 것을 보장하는 것이다.
(불가능한 최소의 단위인 하나의 원자처럼 동작한다는 의미이다.)- Consistency(일관성)
: 미리 정의된 규칙에서만 수정이 가능한 특성을 의미한다.
(숫자 컬럼에 문자열값이 저장이 안되도록 보장한다.)- Isolation(고립성)
: 트랜잭션 수행시 다른 트랜잭션의 작업이 끼어들지 못하도록 보장하는 것이다.- Durability(영구성)
: 성공적으로 수행된 트랜잭션은 영원히 반영이 되는 것을 의미한다.
(한번 반영(commit)된 트랜젝션의 내용은 영원히 적용된다.)
2) NoSQL - CAP theorem
NoSQL은 CAP이론을 따른다.
CAP이론은 분산 시스템에서는 CAP 세 가지 속성 모두를 만족하는 것은 불가능하며,
오직 2가지만 만족할 수 있다는 것으로 정의할 수 있다.
- Consistency (일관성)
: 모든 요청은 최신 데이터 또는 에러를 응답받는다.
(DB가 3개로 분산되었다고 가정할 때, 하나의 특정 DB의 데이터가 수정되면
나머지 2개의 DB에서도 수정된 데이터를 응답받아야 한다.)- Availability (가용성)
: 모든 요청은 정상 응답을 받는다.
(특정 DB가 장애가 나도 서비스가 가능해야 한다.)- Partitions Tolerance (분리 내구성)
: DB간 통신이 실패하는 경우라도 시스템은 정상 동작 한다.
5. Support
SQL 👍, NoSQL 👎
SQL은 이전부터 사용되어 오던 DB의 종류이다.
(위키백과를 참고해보면 SQL의 시작은 1970년, NoSQL의 시작은 1998년이다.)
역사가 깊은 만큼 NoSQL보다는 적용하는 곳이 많아,
그만큼 전문가도 많고, 관련 기술 Issue에 대한 해결책도 많이 쌓여있다.
반면 NoSQL은 SQL보다는 역사가 깊지 않아
이와 관련된 기술 Issue는 많이 보고되고 있지만, 이 것은 지식 정도로 간주된다.*
(*잘못된 의역일 수 있어 원문을 첨부한다.
: Many problems have been reported, but most boil down to a single issue: knowledge.)
(상대적으로 NoSQL이 SQL보다 관련 커뮤니티가 작다고 이해하면 될 것 같다.)
6. 마치며..
SQL, NoSQL은 어떤 상황에서 적용해야할까? 🤔
지난번 정리한 SPA, MPA처럼 각각의 특징이 명확하기 때문에
현재의 상황을 고려하여 최선의 방법이 무엇인지 고민해서 적용하면 된다!ㅎㅎ
그리고 현업에서는 어떤 하나의 DB 형태만 적용하는 것이 아니라
2가지를 혼합해서 사용하는 경우도 많다고 한다.
현재 막연한 초보인 지금은
스키마의 설계가 어렵고, 한번 설계된 스키마를 수정하는 것도 쉽지 않고,
또 어떤 데이터의 형태로 설계해야 되는 것인지 판단이 어려울 것 같아
SQL보다는 NoSQL이 더 적절해보인다.
또 MongoDB와 mongoose를 이용하면 스키마 모델을 비슷하게 나마(?) 적용할 수 있으니,
NoSQL의 단점을 보완할 수 있다고도 생각된다.
7. 참고
