SQL과 NoSQL

SQL : RDBMS Relational DataBase Management System

장점

• 관계망에 따라 데이터가 테이블에 분배된다. 따라서 데이터가 각 테이블에 중복저장되는 것을 줄일 수 있다.
• 또 미리 정의된 스키마에 의해 데이터가 저장되므로, 테이터 무결성 data integrity 에 장점이 있다.

 데이터 무결성 data integrity

소위 무결성 제한 Integrity constraints 등의 규칙으로 데이터베이스에 의해 강제되곤 한다.
다음의 세 갈래로 나눌 수 있다.

-개체 무결성 Entity integrity
고유키 관련. 개체 무결성은 모든 테이블이 고유한 기본키를 가지고 null 을 허용하지 않는다.

-참조 무결성 Referential Integrity
외래키 관련. 모든 외래키는 두 가지 상태 중 하나에만 속해야 한다.
1)일반적으로는 참조하는 테이블의 기본키 primary key.
2)그러나 경우에 따라 외래키 값이 null일 수 있다. 이 때는 객체간 관계가 없거나 관계가 알려지지 않은(unknow) 상태로 남는다.

-범위 무결성 Domain integrity
데이터베이스의 모든 칼럼이 선언되어야 한다.

 

단점

• 스키마가 사전에 계획되어야 하므로 상대적으로 유연성이 떨어진다. 나중에 수정하기도 힘들다.
• 데이터를 중복저장 하지 않는다고 하지만, 이로인해 필요한 데이터를 불러오기 위해 관계맺은 테이블 간의 join이 양산된다.
• 대체로 수직적 확장 scale up 만 가능하다고 하다고 한다.( 아직 뜻을 제대로 파악하지 못했다. )

 

---

NoSQL

장점

• 스키마도, join도, 관계도 없다. 그러므로 유연하다. 언제든 데이터를 조정하고 새로운 필드를 추가할 수 있다.
• 언제든 데이터를 조정한다는 것은, 애플리케이션이 필요로 하는 형식으로 유동적으로 저장할 수 있다는 것.
• 필요로 하는 형식으로 저장할 수 있다는 것은, 곧 데이터를 읽어오는 속도가 빨라진다는 것.
• 요약하면, 데이터의 정합성보다 대용량 처리를 중시한 셈이다.
• 수직적 확장 scale up, 수평적 확장 scale out 모두 가능.

수직적 확장 scale up 과 수평적확장 scale out


수직 확장 vertical scale up : 단일 노드에 자원추가 혹은 장비교체.

하드웨어의 사양관련. 램, HDD, CPU를 추가하는 등.
당연히 하드웨어 상 확장의 한계가 있을 수 있고, 하드웨어 추가에 따르는 비용이 비싸기도 하다.
게다가 마이그레이션이 어렵거나 처음부터 다시 시작해야 할 수 있다.
하지만 이는 짝패로 데이터 일관성을 얻을 수 있다는 뜻이기도 하다. (맞나?)
그러나 어플리케이션의 수정, 업데이트가 쉽다. (수정 내역을 한 서버의 한 노드에만 반영하면 되니까?)


수평확장 horizontal scale out : 서버를 추가해 처리성능을 높인다.

서버의 수를 늘리고 애플리케이션의 복제본을 실행한다. 서버에 노드만 추가해주면 된다.
이로써 서버의 부하가 분산된다.

똑같은 역할의 인스턴스를 늘리면 기존에 잘 작동되는 것을 건드릴 필요가 없어서 무중단 배포가 가능해진다.
예컨대, 특정 시간대 유저 수요가 급증하면 서버를 여러대 확보하고, 수요가 안정되면 서버를 줄일 수 있다.
같은 말을 이렇게 표현할 수도 있다.
“CPU 사용률, 상태, 네트워크 트래픽 양 등을 보면서 자동으로 Scale-Out.”
그리고 이 과정에서 서비스는 중단되지 않는다.
관련하여 다음의 키워드들을 더 찾아볼 것.
”컨테이너 기술”, “오케스트레이션”, “autosacling”, “마이크로 서비스로 모듈화”

한편, 다음의 단점도 부각된다.
“노드만 추가, 애플리케이션의 복제본 실행”이라고 했지만, 아무래도 그 일이 흔히들 말하는 것처럼 간단하지만은 않은 모양이다. 어플리케이션의 수정이 필요한 경우도 많고, 수정과 업데이트를 각각의 노드에 반영해야 하므로 작업량은 배가된다.
위의 내용을 이렇게 표현할 수도 있다.
코드의 모든 버그는 디버그하고 이해하기가 더 복잡해진다.
라이센스가 부여된 노드가 더 많아지기 때문에 라이센스 비용이 비싸진다.
필요한 공간, 냉각 및 전력 증가로 인해 데이터 센터 비용이 증가한다.

단점

• 유연하다는 것은, 데이터가 중구난방으로 중복되어 있을 수 있다는 것.
• 실수로 잘못된 자료형의 데이터를 넣거나 다른 도큐멘트에 없는 필드의 데이터를 넣는 경우. 이 때문에 Mongoose 같은 ODM 이 필요할 수 있다.
• 데이터의 수정을 다수의 컬렉션에서 수행해야 할 수 있음. 지난한 업데이트 우려.
• 때문에 “유연하고 유동적”이라는 흔한 평과 달리, 데이터가 자주 변경되는 애플리케이션에는 오히려 SQL과 RDBMS가 적합할 수 있다. 여러 컬렉션에 걸쳐 중복되어 있는 데이터들을 수정해야 하는 일이 생긴다.
• 물론 스키마 타입이 명확하지 않으면 “유연하고 유동적”이라는 평에 걸맞게, NoSQL이 적합하다.

---

무엇이 어떤 경우 더 좋은가?

NoSQL 이 유리한 경우

• 정확한 데이터 구조를 알 수 없다. 스키마가 명확하지 않다. 변경될 수 있고 확장될 수 있다.
• 읽기를 자주 하지만 데이터 변경(생성, 수정, 삭제)는 자주 없다.
• 데이터 양이 대용량이어서 수평적으로 확장해야 한다.
• 종합하면, 대량의 분산된 데이터를 필요한 형식으로 저장하고 읽어오는 데에 특화되어 있다.

SQL이 유리한 경우

• 데이터 구조, 스키마가 명확하다.
• 그 명확한 데이터의 구조, 관계망에서 데이터 내용은 자주 변경될 수 있다.
• SQL은 관계를 맺은 테이블들에 데이터가 알맞게 배분되어 있다면, 여러 Entity에 접근해 수정을 해야한다거나 할 일이 없다. (NoSQL은 여러 컬렉션을 수정해야 할 수도 있다.)

 

---

참고

https://velog.io/@guswns3371/데이터베이스-SQL-vs-NoSQL

[데이터베이스] SQL vs NoSQL