SQL & NOSQL

[SQL(Structured Query Language)]

SQL은 RDBMS(관계형 데이터베이스 관리 시스템)의 데이터를 관리하기 위해 설계된 프로그래밍 언어로, NoSQL보다 오래되고 많이 사용되어 옴. SQL의 예시로는 MySQL, PostgreSQL 등이 있음.

[NoSQL(Not Only Structured Query Language)]

NoSQL은 앞서 말한 SQL보다 덜 제한적인 모델을 이용해 데이터의 저장 및 검색 메커니즘을 제공. NoSQL의 예시로는 mongoDB, redis 등이 있음!

• 들어가기전에! 스키마란?
  -> 스키마는 DB에 어떤 구조로, 어떤 제약 조건으로 저장 되어야 하는지 정의한 것이다.
• 스키마는 데이터베이스의 구조와 제약조건에 관해 전반적인 명세를 기술한 것.
• 개체의 특징을 나타내는 속성(attribute), 속성들의 집합으로 이루어진 개체(entity), 개체 간 존재하는 관계(relationship)에 대한 정의와 이들이 유지해야할 제약조건들을 기술한 것.
• 사용자 관점에 따라 외부, 내부, 개념 스키마로 나뉜다.
• 개념 스키마 : 데이터 베이스의 전체적인 논리적 구조
• 내부 스키마 : 데이터 베이스의 물리적 저장구조
• 외부 스키마 : 사용자에게 보여지는 스키마 (서브 스키마라고도 한다.)

SQL은 데이터를 저장하기 위해서 스키마가 먼저 정의되어야 한다.
즉, 위에서 간단히 언급한, 외부/내부/개념 스키마를 정의해야 데이터의 저장을 시작할 수 있다는 얘기.

NoSQL에서는 Document에 데이터가 저장된다.
JSON 혹은 객체의 형태인 key-value로 데이터가 저장된다.

여기서 중요한 점은 스키마를 정의하지 않아도 된다는 점이다.
그래서 어떤 형식으로 데이터를 저장해야 할지 확신이 서지 않는 상황에서는 NoSQL이 적절한 방법이라고 흔히 말한다.

1. 데이터구조

SQL과 noSQL은 데이터를 저장하는 구조가 다름!

[SQL]
SQL을 이용해 고객 정보를 저장한다고 생각해보자.

만약 이 고객 테이블에 email 주소를 추가로 저장하고 싶다면 어떻게 해야 될까? 또는 새로운 고객의 데이터를 추가하는데, 그 고객의 핸드폰 번호를 모른다면 어떻게 해야 될까?

SQL에서는 엄격한 스키마(데이터 저장 구조)를 원칙으로 하기 때문에 스키마에 맞지 않는 형식의 데이터는 저장할 수 없음. 따라서 위의 테이블에 한 명의 고객만 email을 추가하거나, 핸드폰 번호를 적지 않는 것은 불가능함.

[NoSQL]
반면, NoSQL에서는 다른 구조의 데이터를 추가할 수 있음.

위와 같이 "John"의 문서(=document =SQL의 레코드)에 email key값을 추가한다고 해서, 다른 문서에 영향을 미치지 않음. 따라서 NoSQL은 데이터의 구조가 같을 필요가 없음.

2. 관계

[SQL(Relational)]
SQL은 데이터 사이의 관계를 지정하기 쉽다.

Orders 테이블을 보면, Customer ID와 Product ID를 통해 John이 연필을 12개 샀다는 것을 알 수 있다. 이처럼 SQL은 각 테이블 간의 관계 지정을 통해 테이블을 접근할 수 있고, 따라서 중복 없이 해당 데이터만을 다룰 수 있다.

[NoSQL(Non-Relational)]
반면 NoSQL에서는 보통 하나의 컬렉션(SQL에서의 테이블)에 관련 데이터를 모두 작성함. John이 연필을 12개 샀을 때, Orders 컬렉션에는 주문 번호와 고객에 대한 정보, 상품에 대한 정보가 모두 들어가게 됨. 이때 SQL과 달리 id만을 저장하는 것이 아니라 고객 이름이나 전화번호 등 모든 정보를 저장하게 된다. 이렇게 해서 Customers와 Products를 보지 않고 Orders만으로 우리가 원하는 데이터를 모두 얻을 수 있도록 한다.

이런 방식은 SQL과 다르게 중복된 데이터가 생기게 된다. 그래서 데이터를 업데이트할 때마다 주의해야 함. 예를 들어 Customer에 John의 email을 추가했는데, Orders에는 이를 업데이트하지 않으면 문제가 발생...!

3. 확장성

확장성의 의미는 처리할 작업량이 늘어날때마다, 늘어나는 요구에 맞춰 크기를 키우거나 기능을 확장시킬 수 있는 시스템, 네트워크 혹은 과정은 능력을 말한다. 데이터베이스의 확장은 크게 두가지로 구별되는데, 수직적과 수평적으로 구별된다.

• 수직적 확장
  수직적 확장 (Vertical Scalability)는 CPU나 RAM 같은 부품이나 하드웨어를 추가해주거나 교체를 해 전체적인 성능을 향상시키는 것을 의미한다. 그래서 소프트웨어의 설계나 구조에 변화를 주거나 시간을 따로 쏟을 필요가 없다. 단순하게 데이터베이스 서버의 성능을 향상시킨다.
• 수평적 확장
  수평적 확장 (Horizontal Scalability)은 더 많은 서버를 추가해서 데이터베이스를 전체적으로 분산시키는 것을 의미한다. 하나의 데이터베이스는 작동하지만 여러 호스트에서 작동한다.

[SQL(vertical scale)]
SQL은 일반적으로 수직적 확장(vertical scale)만을 지원. 수직적 확장은 하드웨어를 업그레이드하거나 추가하여 서버의 성능을 향상시키는 것을 말함.

[NoSQL(horizontal scale)]
반면에 NoSQL에서는 수평적 확장(horizontal scale)이 가능. 서버를 추가하면서 데이터베이스를 분산시킬 수 있음.

4. SQL vs NoSQL 정리

SQL

• 장점
  확실하고 명확하게 정의된 스키마,
  구조의 완전성을 보장할 수 있다.
  관계를 설정하기에, 데이터는 중복없이 한번만 저장된다.

• 단점
  유연하지 못하다. 스키마를 사전에 시간 들여 철저하게 짜야 하고 나중에 수정하기 번거롭다 (엄격한 스키마).
  관계를 맺어 데이터를 저장하기에, 중복되지는 않지만, 조인을 많이 해야할 경우 매우 복잡한 쿼리를 작성해야 할 수 있다.
  수평적 확장이 가능하지만 어렵기 때문에 성장 한계가 오는 시점이 온다.
  관계를 맺고 있는 데이터가 자주 변경되는 경우, 또 명확한 스키마가 사용자와 데이터에게 중요한 경우 관계형 데이터베이스를 사용하는게 좋다. 금융 산업과 같은 시스템의 형태가 급격하게 변하지 않으면서 그 안의 데이터가 계속 바뀌는 보수적인 시스템에서 유리하다.

NoSQL

• 장점
  스키마가 없기에, 훨씬 더 유연하다. 언제든지 데이터를 추가할 수 있다 (필드 추가).
  어떠한 형식으로도 데이터를 저장할 수 있기에, 필요한 대로 저장해 읽어오는 속도가 빨라진다.
  수직 및 수평 확장 모두 가능해 데이터베이스가 애플리케이션에서 발생시키는 모든 읽기 / 쓰기 요청을 처리할 수 있다.

• 단점
  유연성에 의해, 데이터 구조 결정을 계속 미룰 수 있다.
  데이터를 중복되게 필요한 컬렉션 마다 저장할 수 있어, 필요한 컬렉션마다 돌면서 여러 개의 레코드를 다 업데이트해줘야 한다. 누락할 시, 데이터가 최신이 아닐 수 있다.
  수정 시, 모든 컬렉션에서 다 수정해줘야 한다.
  비관계형 데이터베이스는 정확한 데이터 구조를 알 수 없거나 변경 / 확장 될 수 있는 경우 (수평적으로), 읽기 처리는 많이 하지만, 데이터를 자주 변경하지 않는 경우 사용하면 유리하다. 스타트업이 짧은 시간안에 구조등을 계속 발전시키며 변화를 줘야 할 때 사용하면 좋다. 읽기를 많이 하고 많은 양의 정보를 저장해야하는...채팅 정보를 저장하면 유리할 것 같다! 읽어오기만 하면 되니까!

참고이미지!

출처: https://mjmjmj98.tistory.com/43