🧾NoSQL이 뭐야?

배경

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

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

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

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

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

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

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

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

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를 사용할 수 밖에 없었는 지에 대해 설명해주셨습니다.

개인화 영역의 방대한 데이터 처리 필요
- 모바일 기능의 활성에 따른 모바일 서비스 사용량 증가
- 모바일에서 보던 기록을 PC에서도 똑같이 사용하고 싶음
- 기존에 사용하던 로컬에 저장하던 방식을 개인화 영역에서 처리 필요
- 다른 NoSQL에 비해 Mongo DB는 Secondary Index를 지원하기 때문에 방대한 데이터를 처리하기 용이했음
Flexable schema
- 같은 기능을 여러 서비스 팀에서 만들 필요가 있었음(댓글 기능 같은 경우)
- 공통된 기능을 만드는 개발팀이 따로 있고 이 공통 플랫폼을 가져와 사용하는 방식을 채택
- 하지만 RDB를 사용하면 스키마가 고정되어 여러 시스템에서 사용하기 힘든 부분이 존재
- 그래서 이런 부분은 Mongo DB를 통해 사용(유연한 구조)

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

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

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

Mongo DB를 선택한 이유

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

뭔가 조작을 한다 → My SQL

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

이유는 다음과 같습니다.

스키마의 수정이 적다. 데이터의 정규화 과정이 필요한 RDB 특성 상 데이터 구조의 변경이 있으면 정규화 등의 과정을 거쳐야합니다. 처음하는 프로젝트와 협업인 만큼 스키마의 수정이 잦을 것으로 생각이 되고 이 때 빠른 문제 해결을 위해 스키마 수정이 적은 Document DB 즉 몽고 디비를 메인 데이터베이스로 선택했습니다.
읽고 쓰기의 빠름 물론 상황에 따라 다르겠지만 테이블의 관계를 맺고 빈번하게 JOIN을 통해 비용을 가져가는 것 보다는 단순하게 데이터를 읽고 씀으로써 속도의 이점을 가져가고자 했습니다. 당연하겠지만 이 부분에 대해서는 비교가 필요하겠지만 이는 프로젝트가 끝난 후 리팩토링 시간에 할 생각입니다.
기술적 도전 사실 이건 개인적인 이유이지만 원래 MongoDB를 사용해보고 싶었습니다. 이전에는 MySQL을 통해 프로젝트를 했기 때문에 비관계형 DB를 사용해서 프로젝트를 해보고 싶었습니다. 그래도 좋은 기회가 되서 사용해볼 수 있어서 좋은 것 같습니다.