[SQL/DB]NoSQL과 SQL는 무슨 차이가 있는 걸까?

프로젝트를 진행하기 전에 어떤 데이터베이스를 선택해야할지도 중요한 요건 중 하나이다.

오늘은 NoSQL과 SQL의 차이를 비교하면서 어떤 경우에 어떤 데이터베이스를 선택하는게 좋은지 알아보려고 한다.

데이터베이스와 DBMS

• 데이터베이스(DB) : Data를 보관하는 저장소 개념
• DBMS : 데이터베이스에 저장된 데이터를 관리(Manage)하거나 데이터 베이스를 생성하기 위한 관리 시스템

일반적인 파일 시스템의 경우 종속성과 중복성의 문제가 있었기 때문에 DBMS를 통해 이러한 문제를 해결할 수 있었다.

RDB(SQL)

관계형 데이터베이스는 "관계"라는 단어가 중요한 역할을 하고 있다.

관계형 데이터베이스 엑셀 문서와 비슷하게 하나 이상의 행(Row), 열(Column)이 존재하는 테이블(Table, Relation)을 정의한다.

이 테이블간의 관계(Relation)를 통해 여러 테이블에 분산하여 저장할 수 있는 것이다.  

 

관계형 데이터베이스에는 세가지의 핵심이 있다.

• 정해진(엄격한) 스키마(Schema)에 따라 데이터를 저장한다.
• 관계형 데이터베이스이기 때문에 설계할 때 정규화를 진행한다. 정규화를 통해 데이터의 무결성을 보장할 수 있다.
• ACID 특성을 따른다. 트랜잭션이 안전하게 수행되는 것을 보장한다.

스키마(Schema)는 관계형 데이터베이스에서 데이터가 구성되는 방식, 데이터 간 관계를 구성하는 엔티티 간 관계를 의미한다.

스키마를 미리 정의하고 데이터베이스를 구조화하면 명확한 구조를 갖고 있기 때문에 데이터가 중복되지 않는다.

이외에도 외래 키 관계를 갖고 있기 때문에 복잡한 트랜잭션 처리가 가능하며 테이블끼리 JOIN 연산이 가능하다는 점이다.

하지만, 복잡한 시스템의 경우 JOIN 연산으로 인한 성능 이슈가 발생할 수 있다는 점이 있다. 

 

관계형 데이터베이스

장점 및 단점

• 장점
  • 명확한 데이터 구조와 중복이 없는 무결성을 보장한다.
• 단점
  • JOIN을 많이 하게되면 복잡한 쿼리를 만들게 된다.
  • 사전에 스키마를 정의해야한다. 이는 나중에 수정이 어렵다는 점이다.

---

NoSQL

Not Schema, Not Relation한 데이터베이스이다. Not Only SQL의 약자로 SQL의 특정 단점을 해결하는 녀석이다.

NoSQL는 SQL과 다르게 자유로운 데이터베이스 구조를 갖는다. 스키마(Schema)가 존재하지 않고 딱히 테이블에 명시된 규칙이란게 없다.

저장방식에 따른 NoSQL 종류

모델	특징	예시
Key-Value	하나의 키와 하나의 데이터로 저장할 수 있는 단순하고 빠른 구조, 복잡한 조회 연산을 지원하지 않는다.	Redis, AWS DynamoDB
Doument	하나의 키에 하나의 구조화된 문서를 저장하고 조회한다. 자동으로 인덱스를 생성한다.	MongoDB, Azure Cosmose DB
BigTable(Column Family)	하나의 키에 여러개의 컬럼 이름과 값의 쌍으로 데이터를 저장하고 조회한다.	Hbase, Casandra
Graph	인스턴스를 노드로 표현하고 간선을 통해 관계를 맺는 구조	Sones, AllegroGraph, Neo4j

 

NoSQL은 일반적으로 키(key) 값을 이용해 위와 같은 다양한 형태의 데이터를 저장하거나 조회한다.

• Schema-less :  Key-Value 형태로  데이터가 저장하거나 접근한다. 
• 캐싱(Caching) : 대규모 질의에도 고성능의 응답 속도를 제공하는 메모리 캐싱 기술을 적용할 수 있다.
• BASE : DBMS와 대조적으로 가용성과 성능을 중시한다.

NoSQL - Document, 하나의 컬럼내 여러개의 Document로 저장된다.

 

BASE

• 가용성(Basically Available) : 하나의 저장소가 고장이나도 다른 저장소에 백업본이 저장되어있기 때문에 항상 접근이 가능하다.
• 독립성(Soft-State) : 노드의 상태는 외부에서 전송된 정보를 통해 상태를 결정한다. 데이터가 도달한 시점에 데이터를 갱신한다.
• 일관성(Eventually Consistency) : 갑자기 일관성이 깨지더라도 일정 시간이 지나면 데이터의 일관성이 유지된다.

장점 및 단점

결론적으로 RDB의 장점이 NoSQL의 단점이다. 

• 장점
  • 스키마가 없기 때문에 데이터 모델을 유연하게 변화할 수 있다(비정형, 반정형 가능). 뿐만아니라 ERD 설계를 할 필요 없다는 점이다.
  •  확장성과 유연성이 뛰어나 대량의 데이터(빅데이터)에도 처리할 수 있다. 또한, 관련된 데이터를 동일한 컬렉션에 담기 때문에 빠르게 조회할 수 있다는 점이다.
  • Auto Sharding을 지원한다. (데이터셋을 분산시키는 기법)
• 단점
  • 데이터 구조가 분산되어 있다. 일관성이 부족하기 때문에 중복된 데이터를 수정하려면 모든 컬렉션의 분산된 중복 데이터를 같이 수정해야하므로 시간 비용이 든다.
  • RDB와 다르게 표준화가 되어 있지 않아 서로 다른 NoSQL 데이터베이스 간 마이그레이션이 어려울 수 있다.
  • JOIN은 가능하지만 중복될 우려가 있기 때문에 자주 변경되지 않은 데이터에 JOIN하는게 좋다. (컬렉션을 통해 데이터를 복제해 각 컬렉션에 겹치는 데이터를 산출하는 방법.. 하지만 중복된 컬렉션 데이터로 영향을 줄 수 있다.)
  •  인덱스 구조를 메모리에 저장하기 때문에 많은 인덱스를 사용하면 충분한 메모리가 필요하다.

---

비교

두 데이터베이스는 각자 어떤 데이터를 다루느냐에 따라 고려사항이 달라진다. 

• RDB를 사용하기 좋을 때(안정성)
  • 명확한 스키마가 있기 때문에 데이터가 자주 변경이 되어도 구조화된 형태로 저장할 수 있다.
•  NoSQL을 사용하기 좋을 때(가용성, 성능)
  • 수정/생성 작업보다는 조회를 많이하는 경우, 스키마가 없기 때문에 데이터 구조가 명확하지 않는 경우, 빅데이터를 다뤄야 하는 경우에 사용한다.

 

확장 개념에 대한 차이

두 데이터베이스의 확장(Scaling) 차이를 이해하기 전에 먼저 확장 개념을 알아야한다.

이 두가지 방식에 따라 어떻게 성능을 개선하는지 달라진다.

• 수평적 확장(Scale out) : 많은 서버가 추가되고 이에 따라 데이터베이스를 분산하는 것이다. (일을 나눠서 한다.)
• 수직적 확장(Scale up) : 서버의 성능을 향상 시키는 것 ex. CPU와 RAM 부품들을 업그레이드하는 것

조금 이해가 어려울 수 있으니 예시를 들면, 한 카페에 대박나서 손님(데이터)이 많이와 사장님 혼자로서는 모든 손님을 감당하기 어려웠다.

이때 사장님이 생각해낸 아이디어로 최신 고성능의 커피머신(수직적 확장)으로 바꾸던가 커피머신을 2개를 두던가(수평적 확장)를 고민하는 것이다. 당연히 커피머신 2개를 두는게 저렴한 비용으로 해결할 수 있는 방법이다.

 

빅데이터를 다루는 DB 측면에서 수직적 확장보다 수평적 확장이 더 좋다. NoSQL은 수직적 확장 뿐만 아니라 수평적 확장도 지원한다.

만약 회사 내 부서들의 정보를 담은 데이터베이스가 있다고 가정하자. 단지 조회용도로만 사용되는 DB이다. 

수평적 확장으로 부서별 DB로 Scale out 하면 '개발' 부서를 찾을 때 '개발' DB만으로 데이터를 가져올 수 있기 때문에 훨씬 시간 비용을 줄일 수 있다.

 

 

물론 SQL에도 수평적 확장이 가능하다. 

수평적 확장을 하기 위해 샤딩(Sharding)을 통해 데이터를 수평 분할한다. 하지만 ACID를 유지하면서 샤딩을 해야하기 때문에 까다로운 작업이다. 만약 관계 테이블이 존재한다면, 데이터를 추출하기엔 복잡한 작업이 될 것이다... 

 

무조건, NoSQL이 좋다는 것은 아니다. 각 상황에 맞게 사용하는 것이 좋다.

---

CAP 이론

• 일관성(Consistency) : 모든 노드가 같은 시간에 같은 데이터를 볼 수 있다. 약간 원자성과 비슷하다.
  • 각 사용자가 항상 동일한 데이터를 조회
• 가용성(Availability) : 사용자가 읽기, 쓰기등 모든 요청하면 항상 성공 혹은 실패를 반환한다. 내고장성을 의미하며 NoSQL에서는 이를 보장하기 위해 Replication을 사용한다.
  • 모든 사용자가 항상 읽고 쓸 수 있게끔 서비스에 영향을 주면 안됨.
• 분할내성(Partition Tolerance) : 분할된 네트워크 환경에서 동작하는 시스템들은 전달이 실패하거나 망가져도 시스템은 계속 동작한다. 
  • 네트워크 분산 환경에서도 시스템이 잘 동작해야 함.

이 세가지 중에서 최대 2가지만 만족 할 수있다고 한다.

 

CP(일관성, 분할 내성)

A, B 노드 간 네트워크가 중단되는 경우 일관성과 분할내성을 유지하기 위해 A노드에서는 쓰기 할 수 없도록 막는다. 이후 네트워크가 복구되면 그때 동기화하여 불일치를 복구한다.

AP(가용성, 분할 내성)

네트워크 중단되는 경우 A, B 노드를 계속 사용할 수 있지만 A, B가 다른 데이터를 반환할 수 있다. 네트워크가 복구되면 다시 노드를 동기화시켜 불일치를 복구한다.

CA(일관성, 가용성)

사실상 DB가 단일 노드의 경우 CA로 분류된다. 이 경우는 노드간 오차가 없는 경우이므로 처리할 필요 없다. 

 

 

---

☕️ 포스팅이 도움이 되었던 자료

• What is a NoSQL Database? - IBM
• ACID, BASE,CAP 이론과 DB 선택 방법 - 우공80
• NoSQL에 대해 간단히 알아보자 - Embian Blog

오늘도 저의 포스트를 읽어주셔서 감사합니다.

설명이 부족하거나 이해하기 어렵거나 잘못된 부분이 있으면 부담없이 댓글로 남겨주시면 감사하겠습니다.