SQL (관계형 DB)

SQL을 사용하면 RDBMS에서 데이터의 CRUD가 가능하다.

관계형 데이터베이스 특징

• 데이터는 정해진 데이터 스키마에 따라 테이블에 저장
• 데이터는 관계를 통해 여러 테이블에 분산
  

테이블와 스키마

• 스키마의 경우 DB 벤더에 따라 역할과 정의에 대한 설명이 조금씩 다름

	테이블	스키마
정의	행과 열로 구성된 데이터의 집합	DB의 구조와 제약조건에 대한 명세

💡 MySQL의 스키마
MySQL에서 물리적으로 스키마는 DB와 동의어이다.
공식문서에서는 추가로 CREATE SCHMA와 CREATE DATABASE는 같은 기능을 한다고 명시되어 있다.
참고로 오라클의 스키마는 단일 사용자가 소유한 테이블을 의미한다.

NoSQL (비관계형 DB)

위에서 말했던 스키마나 관계가 없는 데이터 저장소이다. RDB에서 정보를 레코드라 부른다면 NoSQL에서는 문서(documents)라고 부른다.

SQL (관계형 DB)와 차이

• 정해진 스키마가 없기 때문에 다른 구조의 데이터라도 같은 컬렉션에 추가 가능
• 문서(documents)는 Json과 비슷한 형태로, 관련 데이터는 동일한 컬렉션에 저장
• 테이블에 대한 개념이 없기 때문에 Join이라는 개념도 존재하지 않음

❓ NoSQL에서의 Join
컬렉션을 통해 데이터를 복제하여 각 컬렉션 일부분에 속하는 데이터를 정확하게 산출한다.
→ 중복 데이터가 발생되어 서로 영향을 줄 위험이 있기 때문에 Join을 사용하지 않거나 자주 변경되지 않 데이터일 때 NoSQL을 고려하면 효율적!

확장 개념

• DB의 확장 개념에는 수직적 확장, 수평적 확장이 있다.

• RDB는 일반적으로 수직적 확장만 지원하지만(수평적 확장이 어렵다) NoSQL은 수직적 확장과 수평적 확장을 모두 지원함

  수직적 확장 : 단순히 데이터베이스 서버의 성능을 향성시키는 것( ex. CPU 업그레이드)
수평적 확장 : 서버를 추가시켜 DB를 분산시키는 확장(하나의 DB에서 작동하지만 여러 호스트에서 작동)
  

❓ SQL도 샤딩(Sharding)하면 수평적 확장이 되는 거 아닌가요?
SQL DB도 수평적 확장을 못하는 건 아닙니다. 하지만 보통 수평적 확장을 지원하지 않는 SQL DB와 다르게 NoSQL DB는 수평적 확장을 기본으로 지원하기 때문에 샤딩(Sharding)보다 구현 난이도가 비교적 쉽습니다.

NoSQL이 수평적 확장에 유리한 이유

• RDB가 가지는 관계성 때문에 수평적 확장이 어렵다.
  1. 게시글과 댓글 테이블이 있고 데이터가 A, B, C 서버에 나누어 저장된다고 가정
  2. 최악의 경우 한 게시글의 데이터와 게시글 댓글 데이터가 A, B, C 서버에 나누어 저장될 수 있음
  3. 하나의 게시글을 표시하기 위해 A, B, C 서버의 데이터를 조회하고 조합해야 함
• NoSQL DB는 도큐먼트 하나에 모든 정보가 들어가 있기 때문에 도큐먼트 단위로 잘라서 여러 서버에 나눠 저장해도 문제가 없다.

❓ RDB도 한 테이블에 게시글, 댓글을 담으면 수평적 확장이 쉬워지는 거 아닌가요?
이론적으로 충분히 가능하긴 하지만 정규화 측면에서 좋지 않은 구조로 RDB의 특성 중 하나인 관계를 아예 포기해버려야 한다. RDB는 중복 데이터를 최소화하고 JOIN을 통한 정보 조합이 바람직하다는 걸 기억하자!

SQL vs NoSQL

그래서 둘 중에 뭘 쓰면 좋은 걸까?

정답은 당연히 없고 상황에 적합한 솔루션을 선택하는 것이 좋다.

SQL

• 장점
  • 명확하게 정의되는 스키마, 데이터 무결성 보장
  • 관계는 각 데이터를 중복없이 한번만 저장
• 단점
  • 철저한 스키마 계획이 필요하여 비교적 덜 유연함(수정이 어려움)
  • 관계를 맺고 있는 쿼리는 Join문이 많은 복잡한 쿼리 생성이 될 수도 있음
  • 대체로 수직적 확장만 가능함
• SQL DB가 좋은 경우
  • 관계를 맺고 있는 데이터가 자주 변경되는 애플리케이션의 경우
  • 변경될 여지가 없고, 명확한 스키마가 사용자와 데이터에게 중요한 경우

NoSQL

• 장점
  • 스키마가 없어서 유연함.
  • 애플리케이션이 필요로 하는 형식으로 저장하기 때문에 Read 속도가 빨라짐
  • 수직 및 수평 확장이 가능하여 애플리케이션의 모든 I/O 요청 처리 가능
• 단점
  • 높은 유연성 때문에 데이터 구조 결정을 미루게 될 수 있음
  • 데이터 중복을 체크하고 업데이트 해야함
  • 데이터가 여러 컬렉션에 중복되어 있기 때문에 수정 시 모든 컬렉션에서 수행해야함(SQL은 중복 데이터가 없음을 보장하므로 한번만 수행 가능)
• NoSQL DB가 좋은 경우
  • 데이터의 구조를 정확히 할 수 없거나 변경/확장 될 수 있는 경우
  • 읽기는 잦지만 데이터 변경은 자주 없는 경우
  • DB의 수평 확장이 필요한 경우(막대한 양의 데이터를 다뤄야하는 경우)