[데이터베이스: MySQL VS NoSQL] 우리 백엔드팀은 왜 MySQL을 쓰기로 결정했을까?

https://academind.com/tutorials/sql-vs-nosql을 보고 이해한 내용을 바탕으로 작성한 글입니다.

 

spring에서는 MySQL

django에서는 SQLite

node.js에서는 NoSQL

을 사용한다고들 하는데 왜, 대체 왜 그렇게 쓰는 건지 궁금해서 쓰게 된 글입니다. 써보고 싶은 거 쓸 수도 있는 거 아니냐고요...

 

💡Summary
MySQL vs NoSQL
= SQL vs NoSQL
= Schema, Relationship vs No Schema, No Relationship
= 다 있는 애 vs 다 없는 애

 

[SQL: Structured Query Language]

'구조화된 쿼리 언어' = 데이터베이스와 의사소통하는 언어! 라는 뜻입니다.

그럼 어떤 데이터베이스와만 대화를 하는가하면, 관계형 데이터베이스와 대화를 하는 친구입니다.

[Relational Database]

어디서 많이 본 relation이죠? 맞습니다. 앞선 요약에서의 MySQL과 같은 SQL에 대해 이야기하는 중입니다.

이 친구로 데이터 검색, 저장, 수정, 삭제 등을 해달라고 대화하는 겁니다.

서로 다른 언어를 쓰는 사람들이 만나서 영어로 소통하듯이, 인간은 관계형 데이터베이스와 소통할 때 이 언어를 사용하는 거죠.

 

이 친구에게는 2가지 특징이 있어요.

1. Schema

이전 포스팅에서 관계형 데이터베이스를 이용한 데이터베이스 구축하기를 한 적이 있어 좋은 예시가 될 거 같아요.

링크를 달아둔 포스팅에서 영화를 언급했었으니 그걸 빌려오도록 할게요.

우리 영화를 보기 위한 웹사이트에 가입을 하죠. 그럼 거기서 얻을 수 있는 데이터로는 회원들의 정보나 영화의 정보들이 있겠죠? 그걸 저장해주는 집의 이름이 Table이에요.

Table집에는 Columns란 제목을 단 규칙에 따라 데이터 친구들이 Rows 형태로 방을 나누어 살고 있답니다.

Table집에 들어갈 수 있는 데이터 친구들은 정해져 있어서 여기에 해당하는 애들 빼고는 세입자로 들어올 수 있다는 계약을 할 수 없거든요. 그래서 정해진 겁니다. 굉장히 엄격하죠.

그러면 이 조건에 맞는 친구들이 그냥 중구난방 우르르 들어가는 게 아니라 Rows의 형태로 들어가 각자의 방을 가지고 살 수 있는 거예요.

 

2. Relation

이전 포스팅을 클릭해보셨다면 아시겠지만, Table이란 집이 하나만 존재하는 게 아니에요.

이렇게 다양하죠. 이웃사촌들끼리의 관계가 좋아야 동네 분위기도 치안도 좋고 정도 존재할 거 아닙니까.

그래서 각 Table 간의 관계는 무시할 수 없는 거예요. 인간은 사회적 동물이라 같이 살아가야 하거든요...

자 여러분 이 관계라는 거 속에 홍길동이가 있다고 쳐봅시다. 길동이는 첫째고요, 집에 의자를 가지고 있어요.

이럴 때 Users Table에 사는 길동이가 Orders Table에서는 첫째로 표시가 되어도 이 길동이가 길동이임은 알아볼 수 있죠. 그리고 이 길동이의 Products Table에는 의자가 있는 거예요. 그래도 길동이가 의자를 가지고 있다는 것을 알아볼 수 있죠.

이렇게 집집마다 관계를 맺어주는 거예요. 그래야 의자가 길동이거구나~ 하고 알 수 있는 거니까요.

 

=> 이런 조건들을 갖춘 친구들이 바로 MySQL, Oracle 등 SQL=RDBMS를 사용하는 친구들인 거예요.

 

[NoSQL: Non-Relational Operational DataBase]

말그대로입니다. 관계? 없어요. 스키마? 없어요. 앞의 저 No가 진짜로 No 입니다. 아니래요.

여기에도 위와 같은 rows가 있어요. 이 세상에서는 document라고 불립니다.

뭔가 다르니까 이름도 다르지 않을까요!

무엇이 다르냐면, schema가 없다는 겁니다. schema가 없으면 어때요? relation도 없는 겁니다. 그럼 어떻게 돼요? 아무나 들어와서 살 수 있는 겁니다!!

그러면 이런 형태가 되는데요. 아까 SQL에서는 지금 혼자 사는 길동이는 본가 가면 첫째가 되고, 얘는 사실 다른 집에 의자를 가지고 있다는 식으로, 다 연결할 수 있었잖아요?

NoSQL은 그렇게 흘러가지 않아요. relation이 없으니까요!!

새로 이사온 이웃사촌이 이 집 길동이가 저 집 첫째고 다른 집에 의자를 가지고 있는 걸 어떻게 알겠어요!! 그러니 그냥 다 복제해서 한 번에 넣어두는 겁니다. {이 집 첫째, 홍길동, 저 집 의자 소유, ...} 이런 식으로요. 이런 형태를 JSON이라고 불러요.

데이터를 복제해야 하니까 한 번 저장한 걸 바꾸려면 여기저기 다 바꿔야만 하긴 해요.

대신에 이웃사촌일 뿐인 길동이를 하나 알면 열을 알듯이 줄줄줄 복잡하게 알아갈 필요는 없게 돼죠.

그래서 자주 변하지 않는 정보일 때 굉장히 효과적이에요.

 

[그래서 우리 백엔드팀은?]

💡SQL vs MySQL

- SQL
관계를 맺고 있는 데이터가 자주 변경/수정되어야 하는 경우
명확한 스키마가 사용자와 데이터에게 중요한 경우

-MySQL
정확한 데이터 구조를 알 수 없거나 변경/확장 가능한 경우
read(읽기)처리를 자주하지만, update(변경)은 자주 하지 않는 경우
데이터베이스를 수평으로 확장해야 하는 경우(: 정말 많은 데이터 사용)

 

그래서 이번 프로젝트에서 우리 백엔드팀은 CI/CD 방식+ PM/FE/DA팀의 협업으로 진행되어 update 해야 하는 상황이 많이 발생할 것으로 예상되어 NoSQL을 선택하는 것보다는 애자일 스프린트 방식에 맞게 변경되어야 한다면 SQL을 사용하는 것이 용이하다고 생각해 MySQL을 데이터베이스 기술 스택으로 채택하기로 결정했답니다.