🧾NoSQL이 뭐야?

배경

메인 DB를 선택하는 과정에서 크게 RDB를 사용할지 아니면 다른 DB를 사용할지에 대한 부분이 고민이었습니다. 그런 상황에서 RDB가 아닌 다른 DB는 지식이 없어 배워보고자 정리했습니다.

과정

NoSQL은 뭘까?

이 부분은 노마드 코더의 니콜라스쌤의 내용을 정리했습니다.

https://www.youtube.com/watch?v=Q_9cFgzZr8Q

NoSQL은 말 그대로 SQL이 아닙니다. → 그게 뭐야 장난해?

진짜 뜻이 Not Only SQL 또는, Not SQL 입니다.

말 그대로 SQL이 아닌 DB를 NoSQL이라고 합니다. 이렇게 된 이유는 가장 흔하게 쓰는 DB가 RDB이라서 그걸 뺀 나머지라는 의미를 가지게 된 것 입니다.

그렇다면 NoSQL은 하나가 아니라는 뜻을 가지기도 합니다.

실제로 NoSQL에는 그 종류에 따라 사용하는 DB가 결정됩니다.

대표적으로는 Document DB, Key Value DB 그리고 Graph DB가 있습니다.

Document VS Key Vs Graph

• DocumentDB(Mongo DB)

  • JSON 형태로 데이터를 저장합니다.
  • RDB처럼 행과 열을 통한 스키마 형태가 아닙니다.
  • 즉 사용자가 원하는 어떠한 데이터도 저장이 가능합니다.
  • 그래서 데이터의 구조가 엄청 유연합니다.

• Key Value DB(Cassandra DB, DynamoDB)

  • 엄청 빠르고 읽고 쓰기 위해 key value를 사용합니다
  • Cassandra DB는 읽고 쓰는 과정이 매우 빠릅니다.(실제로 넷플릭스, 인스타그램 또는, 우버 등에서 사용하고 있습니다.)
  • dynamo db
  • 빠르지만 SQL 처럼 쿼리문을 지정하지 못합니다.
  • 그래서 저장하기 전에 어떻게 데이터를 얻을 지에 대한 고민이 필요합니다.

• GraphDB

  • 각 노드 간의 관계를 알아야 할 때 사용합니다.(페이스북=Tao)
  • Document와 Key Value DB 와는 다르게 각각의 엔티티를 저장하고 이를 관계망으로 연결합니다.

음… 감이 잡히지 않네요…..

밑의 글은 노마드 코더의 니콜라스 쌤의 개인적인 의견을 제 생각대로 정리했습니다.(개인적의 개인적인 의견)

💡 평범한 프로젝트는 SQL로 거의 대부분 커버가 가능하다. 실제로 인스타도 처음에는 SQL로 구현을 했다.

그래서 그냥 SQL로 해라. 나중에 고민해봐도 좋다

즉 나중에 특이한 케이스의 경우 필요에 의해 NoSQL을 도입하는 것도 좋은 생각이다.

그렇다면 그냥 많이 사용하니까 SQL을 사용하는 것이 맞을까요?

왜 가 항상 중요한 개발자로서는 넘어가기 좀 꺼림직합니다.

네이버는 왜 Mongo DB를 사용했을까?

그래서 더 찾아봤습니다.

밑의 글은 네이버 클라우드에서 실제로 배포하는 Mongo DB 서비스를 발표하는 영상입니다.

https://www.youtube.com/watch?v=V_Zs1BmAFoI

네이버의 실제 사례를 예시로 들며 설명해주셨습니다. 간단하게 정리해보자면

• 현재 네이버의 Mongo DB 사용량은 엄청 많아짐
• 스마트 스토어, 네이버 쇼핑, 네이버 웹툰 뿐만 아니라 다른 다양한 서비스에도 Mongo DB를 사용하고 있음

다음에는 왜 Mongo DB를 사용할 수 밖에 없었는 지에 대해 설명해주셨습니다.

• 개인화 영역의 방대한 데이터 처리 필요

  • 모바일 기능의 활성에 따른 모바일 서비스 사용량 증가
  • 모바일에서 보던 기록을 PC에서도 똑같이 사용하고 싶음
  • 기존에 사용하던 로컬에 저장하던 방식을 개인화 영역에서 처리 필요
  • 다른 NoSQL에 비해 Mongo DB는 Secondary Index를 지원하기 때문에 방대한 데이터를 처리하기 용이했음

• Flexable schema

  • 같은 기능을 여러 서비스 팀에서 만들 필요가 있었음(댓글 기능 같은 경우)
  • 공통된 기능을 만드는 개발팀이 따로 있고 이 공통 플랫폼을 가져와 사용하는 방식을 채택
  • 하지만 RDB를 사용하면 스키마가 고정되어 여러 시스템에서 사용하기 힘든 부분이 존재
  • 그래서 이런 부분은 Mongo DB를 통해 사용(유연한 구조)

이 밖에도 naver mongo DB만의 좋은 점을 많이 설명해주셨는데… 아직 지식이 얕아 전부 이해하기는 힘들었습니다…

부스트캠프 7기 슨배님들의 선택은?

그리고 저번 기수 분들은 대체적으로 어떤 DB를 사용했을까 궁금해졌습니다.

몇 개 들어가서 본 결과로는 Mongo DB를 메인 DB로 사용하는 팀이 더 많았습니다.

Mongo DB를 선택한 이유

• 단순한 I/O를 처리함에 좋다(입력과 출력을 그대로 보낼 때)
• 즉 복잡하지 않는 데이터에는 NoSQL이 좋다.
• NodeJS를 사용할 때 NoSQL은 강력하다.(Non-Blocking + Async)
• 게임의 경우 스키마를 변경해야하는 경우가 많이 발생해서 유연한 Mongo DB를 선택 MySQL을 선택한 이유
• 범용적이다.(실제 기업에서 많이 사용)
• 테이블 간 관계가 중요하다고 생각했다.
• 채팅과 같은 빠른 Write가 필요없고 관계를 맺는 테이블의 데이터가 변경될 시 NoSQL을 사용하면 수정에 문제가 생길 수 있다고 판단했다.

결론

단순히 데이터를 조회만 한다 → Mongo DB

뭔가 조작을 한다 → My SQL

라고 받아들였습니다. 물론 이 프로젝트가 끝나고 난 뒤의 생각은 또 달라지겠지만 현재 시점에서는 MongoDB를 선택했습니다.

이유는 다음과 같습니다.

1. 스키마의 수정이 적다. 데이터의 정규화 과정이 필요한 RDB 특성 상 데이터 구조의 변경이 있으면 정규화 등의 과정을 거쳐야합니다. 처음하는 프로젝트와 협업인 만큼 스키마의 수정이 잦을 것으로 생각이 되고 이 때 빠른 문제 해결을 위해 스키마 수정이 적은 Document DB 즉 몽고 디비를 메인 데이터베이스로 선택했습니다.

2. 읽고 쓰기의 빠름 물론 상황에 따라 다르겠지만 테이블의 관계를 맺고 빈번하게 JOIN을 통해 비용을 가져가는 것 보다는 단순하게 데이터를 읽고 씀으로써 속도의 이점을 가져가고자 했습니다. 당연하겠지만 이 부분에 대해서는 비교가 필요하겠지만 이는 프로젝트가 끝난 후 리팩토링 시간에 할 생각입니다.

3. 기술적 도전 사실 이건 개인적인 이유이지만 원래 MongoDB를 사용해보고 싶었습니다. 이전에는 MySQL을 통해 프로젝트를 했기 때문에 비관계형 DB를 사용해서 프로젝트를 해보고 싶었습니다. 그래도 좋은 기회가 되서 사용해볼 수 있어서 좋은 것 같습니다.