SQL? NoSQL?
무얼 써야 하나요
cover 출처 및 참고 article: http://bigdatahadooppro.com/sql-vs-nosql-all-you-need-to-know/
처음 웹 프로젝트를 접했을 때, 그리고 매 번 프로젝트를 시작할 때마다 고민되던 것이 바로 mySQL과 같은 SQL database를 쓸 것이냐, 아니면 mongoDB와 같은 NOSQL을 쓸것이냐였다.
처음엔 큰 고민 없이 그냥 초기 프로젝트에선 mySQL을 쓰곤 했는데 (knex, bookshelf와 같은 ORM을 같이 썼다. 부끄럽게도 아직 raw query문에는 익숙하지 않다는...) NOSQL의 장점에 대해 듣게 되면서 mongoDB에 관심을 가지게 되었고, 이후 내가 만들던 서비스에는 mongoDB를 적용했다.
그러나 조금 더 각 방식의 장단점을 파악해야 하겠다는 생각이 들어, 적당한 블로그 글 하나를 요약/의역/번역/참조해 가며 정리해보고자 한다. 나와 같이 아직 웹 데이터베이스 선택에 고민이 많은 주니어 개발자에게 도움이 되기를 바라며 시작!
데이터베이스 기술의 세계에는 두 가지 타입이 존재한다. SQL과 NoSQL. 간단하게 보면
- Databse SQL: SQL은 Structured Query Language의 약자이다. 아주 오래전부터 사용되던 방식이라 DB라 한다면 SQL을 의미하는 경우가 많다. 관계형 DB(RDS, Relational DataBase라고 부르기도)
- No SQLDatabase: Non-SQL, 혹은 Not Only SQL, non-relational database라고도 부른다. (뭐가 맞는 거야) 관계형 테이블로 서로 이루어진 SQL과 달리 데이터 저장을 위한 메커니즘이 다르다. unstructured 된 방대한 데이터를 저장하기에 좋다. SQL과 같이 관계형 모델을 '모사'할 수도 있다.
SQL vs NoSQL Database: 차이점
출처: Couchbase - https://blog.couchbase.com그럼 무엇을 사용해야 하나?
SQL, NoSQL은 서로 반대의 개념도, 경쟁상대도 아니다. 많은 회사들이 두 타입 모두 동시에 사용하기도 한다. 하나의 시스템이 모든 경우를 만족시키지 않기 때문이다. 만약 여러분의 데이터가 급격하게 늘어나는 형태라면 NoSQL이 도움이 될 수 있다.
여기서 잠깐! 개인적으론 Scale-Out 개념과 Scale-Up의 개념이 이 두 타입의 데이터베이스를 이해하기에 많은 도움이 되었다.
출처: https://www.slideshare.net/samuelberthe/confrence-nosql-et-scalabilit'NoSQL이 스케일링에 좋다고 하던데요'라는 게 무슨 말일까?
SQL의 경우엔 시스템이 커져가면서 Scale-Up의 형태로 DB를 증설하게 된다. 관계를 가지는 테이블들이 수평적으로 더 커진다는 말이다. 그렇게 되면 기존에 사용하던 DB시스템보다 고성능의 DB시스템이 필요할 수 있고 이는 굉장히 덩치가 큰 DB 시스템이 된다는 말이다. (관리가 어려워질 수 있다.)
반면, NoSQL의 경우 Scale-Out의 형태로 증설을 할 수 있게 되는데 고성능의 DB를 갖추는 게 아니라 여러 DB 시스템으로 추가할 수 있다는 말이다. 숫자는 무한대로 늘려갈 수 있는데 이는 SQL의 Scale-Up이 무제한적으로 늘려갈 수 없는 것과 비교해 장점이 될 수 있다.
NoSQL은 유연한 DB Schema를 가지고 있다. 따라서 스타트업과 같이 짧은 시간 안에 DB 구조등이 자주 변하는 형태라면 적합할 수 있다. 유연하다는 말은, 예를 들어 내가 '국가'라는 collection을 만들었는데 국가의 속성엔 국가 이름, 인구수, 면적 등을 저장해야 한다고 약속한다. 그런데 정의된 속성 이외에 '기후'정보와 같이 추가해서 저장해도 NoSQL에선 저장이 된다. 그러나 이렇게 자주 변하는 구조에서 시간이 흐르다 보면 데이터들의 구조가 어디는 살이 없고 어디는 있는, 뭔가 좀비와 같은 완전하지 않는 데이터들을 가지고 있게 될 수도 있다.
반면 SQL의 경우 DB Schema를 한 번 fix 하게 되면 Data 및 구조의 완전성을 보장할 수 있지만 유연하진 않다. 금융 산업과 같이 시스템의 형태가 급격하게 자주 변하지 않는 보수적인 시스템에서 장점을 가질 수 있겠다.
웹 개발을 하면서 각 개인마다 선호하는 DB형태가 있다는 것을 알게 되었다. 어떤 분들은 NoSQL로 모든 것을 할 수 있다고 자신하시고, 반면 어떤 분들은 SQL은 신뢰할 수 없기 때문에 오랫동안 신뢰를 쌓아온 SQL만을 써야 한다고 하신다. 개인적으론 아직 어떤 특정 타입을 선호하지 않고 있다. (경험이 적어서 그런가...) 둘 모두 잘 사용하고 싶은 욕심이 있는데 일단 현재 하고 있는 프로젝트에선 SQL -> NoSQL로 바꾸겠다는 협의가 이루어졌다. 개인적으로 NoSQL을 선호해서가 아니라, 이 프로젝트의 성격에선 NoSQL이 더 합리적이라고 판단했기 때문이다.
누가 mongoDB 쉽다고 했습니까!!!
mongoDB(대표적인 NoSQL) 이 쉽다고 다들 노래를 불렀다. 물론 처음 적용하기엔 SQL 보다 접근성이 좋은 것 같기도 하다. Schema가 유연하니깐. 그러나 query 가 복잡해지면서 전혀 쉬워 보이지 많은 않았다. 어떤 타입의 DB를 사용하더라도 간결한 query로 data를 똑똑하게 뽑아내고 잘 가공해서 보내주는 건 그냥 그 사람의 실력인 것 같다. 이번 프로젝트를 통해서 NoSQL에 좀 더 익숙해지는 것을 목표로!!
===
혁신적인 코딩 부트캠프, 코드스테이츠에서 일하고 있습니다.
