티스토리 뷰

2021/01/19 -  [Firebase] Firestore ① NoSQL Database란

2021/01/20 - [Firebase] Firestore ② Firestore의 구조

 

Cloud Firestore는 NoSQL database입니다. (NoSQL이 무엇인지 아시는 분은 영상의 10분대로 넘어가시거나 다음 글로 넘어가시면 됩니다~) 그래서 이번 글은 NoSQL에 대해 다뤄보려고 합니다. Firebase의 공식 유튜브에서 제공하는 영상을 번역하는 형식으로 진행해볼까 합니다! 커피 한 잔은 와방 큰 힘이 됩니다? 깔깔>< 혹시나 오류 발견 시 댓글로 꼭 말씀해주세요! 시작해볼까요?

 

donaricano-btn

 

관계형 DB는 테이블 형태로 구성이 되어 있죠? 각 테이블의 행(row)은 정해진 규칙을 따라 채워나가게 됩니다. 예를 들어서 아래의 테이블에서 feeling은 문자열을 담을 수 있는데 -1과 같은 정수가 나오면 규칙에 위반되는 것이죠.

이런 까다로운 성질 때문에 주로 하나의 대상을 표현하기 위해서 하나의 테이블이 필요합니다. "레스토랑의 리뷰 앱"을 예를 들어보면 레스토랑을 위한 테이블, 사용자 테이블, 리뷰 테이블 등이 필요하겠죠? 그리고 이 객체들은 서로 어떤 relation을 가지고 있을테니 주로 다른 테이블의 primary_key를 foreign_key로 갖게끔 해서 table join하고~ 쿼리를 해왔을겁니다. 

예를 들어 특정 레스토랑의 리뷰를 볼 수 있는 화면에 필요한 데이터를 모아볼까요?

SELECT * FROM restaurants, reviews, users
WHERE restaurant.id = 24
AND reviews.retaurant_fk = restaurant.id
AND reviews.author_fk = user.id

좀 간단하긴 했지만 우린 여태 이런식으로 관계형 DB를 사용해오고 있었습니다.

NoSQL은 조금 달라요!

조금씩 다르긴 하지만 데이터를 테이블 형태로 보관하는 것이 아니라 key-value로 저장을 한다던지, realtime database처럼 중첩 트리(nested tree) 형태를 띈다던지 json객체의 모음 등으로 저장할 수 있습니다. 그러나 이들 모두는 schema-less 하다는 공통점을 가지고 있습니다. 즉, 언제 어떤 종류의 데이터를 저장해야한다는 규칙이 없습니다. 위의 레스토랑의 Restaurants 테이블과 비교해보자면 City에 문자열이 올 수도, 배열이 올 수도(프렌차이즈 일 수도 있잖슴?ㅎㅎ) 있고 어떤 레스토랑은 소음크기라는 필드를 더 추가할 수도 있는거구요. 즉 DB를 자유롭게 순회하며 필요한 필드를 추가하거나 삭제할 수 있고, 새로운 필드를 추가한다고 추가 이전의 데이터를 채울 필요도 없습니다.

물론 방어적으로 코드를 짜야한다는 단점이 존재합니다. 보안 규칙 설정과는 별개로 내가 요청한 데이터가 항상 올바르게 도착한다는 보장이 없기 때문에 client-side에서 확인을 해야합니다. 받아 온 데이터가 맞는지, 아니라면 error handling은 어떻게 할 것인지 등. 하지만 방어적으로 코드를 짜는 것은 중요합니다. 사용자가 사용하는 버전이 최신이 아닐 수도 있으니까요!


계속해서 NoSQL 특징을 살펴보면 SQL이 없다는 것. 보통은 데이터들이 다른 테이블들에 펴져있었기 때문에 이 테이블에서 이 정보, 저 테이블에서 저 정보를 가져와 합치기 위해 SQL을 썼습니다. 그러나 NoSQL은 이런 방식으로 동작하지 않습니다. 대신 데이터를 저장할 때 한 번 요청하면 다 부를 수 있도록 한 곳에 둡니다. 물론! 같은 데이터를 여러 DB에 중복 저장을 하는 상황이 만들어질 수 있겠죠? 아까와 같은 예시를 들어보겠습니다. 예를 들어 ID == 24인 레스토랑의 후기를 보고 싶어요. 후기를 n명의 사람들이 썼겠죠? 각 사용자는 이름과 프로필 사진 정보를 갖고 있을겁니다. 그러면 Josh(아래 그림 참고)라는 사람이 리뷰를 남긴 모든 리뷰 종류에 User(Josh, Image)를 다 복사해두는 거죠.

관계형 DB가 익숙한 사람들은 아마 "저게 머임...??" 이라고 생각할수도 있습니다. 당연하죠 Normalization을 하며 데이터 저장의 중복을 없애는데 많은 공을 들였으니까요. (3NF, BCNF 열심히 외웠었다...) 물론 예를 들어 사용자가 닉네임을 Josh에서 Joshua로 바꾸기로 한다면 Reviews를 하나씩 순회하며 찾아서 바꿔야 하는 번거로움이 있을 수 있겠죠. 그러다가 덜 바꾼/까먹고 못 바꾼/실수로 놓친 곳도 있을 수 있겠죠? 이것만으로 충분히 안 좋아 보이는데 왜 NoSQL이 핫할까요? 그건 바로...

Write 횟수 <<< Read 횟수

이기 때문입니다. 가령 이런거죠? 100명의 사용자가 하루에 한번씩만 접속해도 총 100번의 리뷰를 읽어와야하는데 프로필 사진을 바꾸는 사람이 얼마 되겠어요?

또 다른 특징이자 장점으로는 데이터를 여러 기계에 배포를 쉽게 할 수 있다는 것입니다. 관계형 DB를 사용할 때 더 큰 데이터 셋으로 키우려면 더 큰 기기가 필요했죠?(= Scaling Vertically = 수직적 확장) 반면에 NoSQL은 여러 서버에 걸쳐 키워나갈 수 있습니다.(= Scaling Horizontally = 수평적 확장)

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
글 보관함