[Database] SQL vs NoSQL

SQL

• Structured Query Language
• 특정 유형의 데이터베이스와 상호작용하는 데 사용하는 쿼리 언어
• 뭉뚱그려 RDBMS(관계형 데이터베이스)를 칭하기도 함
• RDBMS의 특징
  • 데이터는 엄격한 스키마(structure)에 따라 테이블에 저장
  • 데이터는 관계를 통해 연결된 여러 테이블에 분산

엄격한 스키마

• 테이블은 명확하게 정의된 구조(structure)로 설계
  • structure : 데이터의 요소를 정의하는 field(column)의 집합
• 데이터는 테이블에 record(row) 형태로 저장
• 스키마를 준수하지 않는 레코드는 추가할 수 없음

관계

• 여러 개의 테이블을 나누어 중복을 피할 수 있음
• ex) Users, Products, Orders 여러 테이블을 만들고, 각각의 테이블들은 다른 테이블에 저장되지 않은 데이터만 보유
• 각 테이블마다 중복 없이 하나의 데이터만 관리하여, 다른 테이블에서 수정될 일 없음

NoSQL

• Not only SQL
• 정해진 스키마 없음
• 관계 없음
• 여기서 record를 document라고 부름
• 다른 구조의 데이터를 동일 collection에 추가할 수 있음
• 데이터는 JSON 타입
• join 필요 없이 문서를 모두 갖추어 작성
• join과 같은 기능이 필요하다면, 그냥 데이터를 복제하여 collection에 추가
  • 데이터 수정시 복제된 컬렉션에서도 모두 수정해야하는 불편함

수직적(Vertical) & 수평적(Horizontal) 확장(Scaling)

• 수직적 확장 : 데이터베이스 서버 성능 향상
• 수평적 확장 : 많은 서버를 추가하여 데이터베이스를 분산
• SQL은 수직정 확장을, NoSQL은 수평적 확장을 주로 함
• NoSQL에서 지원하는 Sharding은 수평적 확장을 유리하게 함

어떤 DB를 써야하나?

SQL의 장점

• 명확한 스키마, 데이터 무결성
• 관계는 각 데이터 중복 없이 한 번만 저장

NoSQL의 장점

• 스키마가 없어 유연
• 데이터 읽어오는 속도 빠름

SQL의 단점

• 스키마는 사전에 계획되어 유연하지 못 함
• join문이 많은 복잡한 쿼리가 필요할 수 있음
• 수평적 확장의 어려움

NoSQL의 단점

• 유연성 때문에, 데이터 구조 결정이 어려움
• 데이터 중복으로 인해 여러 컬렉션에서 모두 수정 필요

SQL은 언제 사용?

• 관계 맺는 데이터가 자주 수정되는 앱일 경우
• 변경될 여지가 없는 명확한 스키마가 필요할 때

NoSQL은 언제 사용?

• 정확한 데이터 구조를 알 수 없거나 변경/확장될 수 있는 경우
• 읽기를 자주하지만, 데이터를 자주 변경하지 않는 경우

---

ref :
SQL vs NoSQL