SQL (Structured Query Language)
SQL은 RDBMS(관계형 데이터베이스 관리 시스템)의 데이터를 관리하기 위해 설계된 프로그래밍 언어
로, 특정 유형의 데이터베이스와 상호 작용하는데 사용하는 쿼리 언어이다. SQL을 사용하여 RDBMS에서 데이터를 저장, 수정, 삭제, 및 검색을 할 수 있다.
NoSQL (Not Only Structured Query Language)
NoSQL은 이름에서도 알 수 있듯, 기존 RDBMS가 갖고 있는 특성뿐 아니라, 다른 부가적인 특성들을 지원하는 데이터베이스이다. 관계형 데이터베이스 보다 유연한 확장과 이용성을 가지고 있다.
SQL과 NoSQL은 언어로 나뉘기 보다는, 관계형 데이터베이스와 비 관계형, 분산형 데이터베이스로 나뉘는게 정확하다고 생각한다. 앞서 다뤘던 MySQL과 MongoDB는 관계형 데이터베이스와 비 관계형, 분산형 데이터베이스의 대표격인 데이터베이스다.
SQL(관계형 데이터베이스)와 NoSQL의 특징
데이터 구조 (Structure)
* 엄격한 스키마
- 데이터는 테이블(table)에 레코드(record)로 저장되며, 각 테이블에는 명확하게 정의된 구조(structure)가 있다.
스키마에 맞지 않는 형식의 데이터는 저장할 수 없습니다
.
예를 들어, Customers 테이블에 email 을 추가로 저장하고 싶다면? 또는 새로운 고객의 데이터를 추가하는데, 그 고객의 핸드폰 번호를 모른다면? (not_null 가정)
위의 스키마에 맞지 않는 형식의 데이터는 저장할 수 없습니다
설명하듯 데이터를 저장 할 수 없다.
엑셀 형식의 데이터 구조
* 스키마 없음 (데이터 필드 추가에 있어서 자유로움.)
- NoSQL에선 레코드(record)를 문서(documents)라고 부른다. 이것의 차이점은 SQL 에서는 정해진 스키마를 따르지 않는다면 데이터를 추가 할 수 없지만, NoSQL에서는 다른 구조의 데이터를 같은 컬렉션(= SQL에서의 테이블)에 추가할 수 있다.
SQL에선 추가하지 못한 email 정보를 간단하게 추가 할 수 있다. JSON 형식의 데이터 구조
관계 (Relationship)
* 테이블 간의 관계
- 데이터들을 여러개의 테이블에 나누어서, 데이터들의 중복을 피할 수 있다.
Orders 테이블을 보면, Customer ID와 Product ID를 통해 John이 연필을 12개 샀다는 것을 알 수 있다.
이처럼 SQL은 각 테이블 간의 관계 지정을 통해 테이블을 접근할 수 있고, 따라서 중복 없이 해당 데이터만을 다룰 수 있다.
* 관계 없음 (하나의 컬렉션에 관련된 데이터 모두 저장 가능.)
- NoSQL은 문서(documents)에 한 번에 담을 수 있기 때문에 필요한 데이터를 얻기위해 관계형 데이터베이스 처럼 각각의 테이블을 조인할 필요가 없다.
대신 컬렉션을 통해 데이터를 복제하여 각 컬렉션 일부분에 속하는 데이터를 정확하게 산출하도록 해야한다.
이런 방식은 데이터가 중복되기 때문에 불안정한 측면이 있다. 실수로 컬렉션 B에서는 데이터를 수정하지 않았는데, 컬렉션 A에서만 데이터를 업데이트 할 위험이 있다.
특정 데이터를 같이 사용하는 모든 컬렉션에서, 똑같은 데이터 업데이트를 수행되도록 해야 한다.
그럼에도 불구하고, 이러한 방식의 커다란 장점은 복잡하고 (어떤 순간에는 느린) 조인을 사용할 필요가 없다는 것이다.
필요한 모든 데이터가 이미 하나의 컬렉션안에 저장되어 있기 때문이다.
특히 자주 변경되지 않는 데이터 일때 더 큰 장점이 있다.
확장성 (Scalability)
확장은 우선 수직적(Vertical) 확장과 수평적(Horizontal) 확장으로 구별 할 수 있다.
- 수직적 확장이란 단순히 데이터베이스 서버의 성능을 향상시키는 것. (예를 들어, CPU를 업그레이드 하는 방식)
- 수평적 확장은 더 많은 서버가 추가되고 데이터베이스가 전체적으로 분산됨을 의미한다. 따라서 하나의 데이터베이스에서 작동하지만 여러 호스트에서 작동한다는 의미이다.
정리
SQL의 장점
- 명확하게 정의 된 스키마, 데이터 무결성 보장
- 테이블 간의 관계를 설정, 데이터 중복을 피할 수 있음.
SQL의 단점
- 데이터 스키마는 사전에 계획 되어야 하며, 후에 수정이 번거로움.
- 필요한 데이터가 여러 테이블에 흩어져 있을 시, JOIN문이 많은 매우 복잡한 쿼리가 만들어 질 수 있음.
- 수평적 확장이 어렵고, 수직적 확장은 한계가 있다.
NoSQL의 장점
- 스키마가 없기 때문에, 유연한 데이터 구조를 가짐. (새로운 "필드"를 손쉽게 추가.)
- 데이터는 애플리케이션이 필요로 하는 형식으로 저장됨. 데이터를 읽어오는 속도가 빨라진다.
- 수직 및 수평 확장이 가능하므로 데이터베이스가 애플리케이션에서 발생시키는 모든 읽기 / 쓰기 요청을 처리 할 수 있습니다. (분산 처리 가능.)
NoSQL의 단점
- 데이터가 여러 컬렉션에 중복되어 있기 때문에, 수정(update)를 해야 하는 경우 모든 컬렉션에서 수행해야 함.
언제 사용하는 것이 좋을까?
- SQL
- 관계를 맺고 있는 데이터가 자주 변경(수정)되는 애플리케이션일 경우 (NoSQL에서라면 여러 컬렉션을 모두 수정해줘야만 합니다.)
- 변경될 여지가 없고, 명확한 스키마가 사용자와 데이터에게 중요한 경우
- NoSQL
- 정확한 데이터 구조를 알 수 없거나 변경 / 확장 될 수 있는 경우
- 읽기(read)처리를 자주하지만, 데이터를 자주 변경(update)하지 않는 경우 (즉, 한번의 변경으로 수십 개의 문서를 업데이트 할 필요가 없는 경우)
- 데이터베이스를 수평으로 확장해야 하는 경우 ( 즉, 막대한 양의 데이터를 다뤄야 하는 경우)
* 참고