SQL과 NoSQL

들어가기 전에

SQL과 NoSQL. 대표적으로 MySQL과 MongoDB를 접하면서 한번쯤 들어보았지만,
명확하게 알고있지는 못하는 것 같아서 스터디를 진행하면서 정리하고 공유해보았다.

(아래의 내용 중에는 잘못된 내용이 존재할 수 있습니다.)

---

SQL의 관계

DB는 다양한 방법으로 데이터를 정리한다

• One to One Relationship: 1:1 관계
• One to Many Relationship: 1:Many 관계
• Many to One Relationship: Many:1 관계
• Many to Many Relationship: Many:Many 관계

-> 관계를 이용해서 각각의 테이블을 조인할 수 있고, SQL쿼리를 이통해 원하는 데이터를 얻을 수 있다.

SQL의 단점

NoSQL은 아래의 단점을 가지고 있다.

• SQL은 스키마가 사전에 계획되어 있기때문에, 스키마에 맞게 데이터를 넣어야한다.
• 데이터가 여러 테이블로 분산되어 있기 때문에 Join을 이용해야 한다.
• 수평적 확장이 어렵다. (ACID로 인한 문제)

수직적 확장 : 서버의 사양을 올리는 확장
수평적 확장 : 여러 대의 서버를 두어 성능을 올리는 확장

---

NoSQL의 등장 배경

무수히 많은 데이터의 저장이 가능해지면서, 분산처리 및 저장의 개념인 하둡이 나오고 RDB로는 적합하지 않게 되었으며, 비정형 데이터의 저장 수요가 높아지면서 RDB를 통한 저장의 한계가 발생한다.
이런 상황에서 한계를 극복하고자 나오게된 것이 NoSQL이다.

(출처 : https://dingrr.com/blog/post/개발-sql-vs-nosql-언제-무엇을-사용할까)

---

접근방식에 따른 장단점

SQL의 장점

• 명확하게 정의된 스키마, 데이터 무결성 보장
• 관계는 각 데이터를 중복없이 한번만 저장

NoSQL의 장점

• 스키마가 없기 때문에, 훨씬 더 유연하다.
  언제든지 저장된 데이터를 조정하고 새로운 "필드"를 추가 할 수 있다.
• 데이터는 애플리케이션이 필요로 하는 형식으로 저장된다. 이렇게하면 데이터를 읽어오는 속도가 빨라진다.
• 수직 및 수평 확장이 가능하므로 데이터베이스가 애플리케이션에서 발생시키는 모든 읽기 / 쓰기 요청을 처리할 수 있다.

---

SQL의 단점

• 상대적으로 덜 유연하다. 데이터스키마는 사전에 계획되고 알려져야 한다. (나중에 수정하기가 번거롭거나 불가능할 수도 있다.)
• 관계를 맺고 있기 때문에, JOIN문이 많은 매우 복잡한 쿼리가 만들어질 수 있다.
• 수평적 확장이 어렵고, 대체로 수직적 확장만 가능하다. 즉, 어떤 시점에서 (처리 할 수 있는 처리량과 관련하여) 성장 한계에 직면하게 된다.

NoSQL의 단점

• 유연성 때문에 데이터 구조 결정을 하지 못하고 미루게 될 수 있다.
• 데이터 중복은 여러 컬렉션과 문서가 (SQL처럼 하나의 테이블에 하나의 레코드가 아니라) 여러 개의 레코드가 변경된 경우 업데이트를 해야한다.
• 데이터가 여러 컬렉션에 중복되어 있기 때문에, 수정(update)를 해야 하는 경우 모든 컬렉션에서 수행해야 함을 의미합니다. (SQL에서는 중복된 데이터가 없기 때문에 한번만 수행하면 된다.)

---

뭘 사용하는게 좋을까?

SQL은 언제 사용하는 것이 좋을까?

• 관계를 맺고 있는 데이터가 자주 변경(수정)되는 애플리케이션일 경우 (NoSQL에서라면 여러 컬렉션을 모두 수정해줘야만 한다.)
• 변경될 여지가 없고, 명확한 스키마가 사용자오아 데이터에게 중요한 경우

NoSQL은 언제 사용하는 것이 좋을까?

• 정확한 데이터 구조를 알 수 없거나 변경 / 확장 될 수 있는 경우
• 읽기(read)처리를 자주하지만, 데이터를 자주 변경(update)하지 않는 경우 (즉, 한번의 변경으로 수십 개의 문서를 업데이트 할 필요가 없는 경우)
• 데이터베이스를 수평으로 확장해야 하는 경우 (즉, 막대한 양의 데이터를 다뤄야 하는 경우)

+

데이터베이스는 다른 방식으로 설계될 수 있다.
NoSQL 데이터베이스를 쓰더라도 설계적으로 언급된 단점들을 완화시킬 수 있다. (예를들면 중복된 데이터를 줄이는 방법).
SQL 데이터베이스도 마찬가지로 요구사항을 만족시키고, 복잡한 JOIN문을 만들지 않도록 설계할 수 있다.

어떤 제품들이 있나?

(NoSQL의 경우, 저장하는 방식에 따라서 쓰임이 다르다. 이에따른 자세한 내용은 이 글에서는 설명하지 않는다.)

---

참고 자료

• https://www.one-tab.com/page/Sygcp3JBTq2LPI3-G1DWSw