FireBase / NoSQL / FireStore

FireBase

• Firebase는 웹과 모바일 개발에 필요한 기능을 제공하는 BaaS(Backend as a Service)입니다. 쉽게말해 백엔드 개발을 통해 서버를 따로 설계, 구현하지 않고 프론트엔드 개발에 집중할 수 있도록 도와주는 서비스입니다.
• 기능으로는 실시간 데이터베이스, 간편한 사용자 인증, 클라우드 저장소, 호스팅, 앱 테스트와 수익 창출을 도와주는 등 다양한 기능을 제공해줍니다. 
• FireBase는 다른 데이터 베이스 들과 다르게 RTSP(Real Time Stream Protocol) 방식의 데이터베이스를 지원하고 있습니다. 

 

 

---

NoSQL

• NoSQL 데이터베이스는 조인이 필요없도록 설계한다. 중복을 허용하되 중첩을 배제해도록 설계
• NoSQL은 테이블과 스키마의 개념이 없다. RDB는 유연성과 확장성이 떨어지지만 NoSQL은 많이 유연하다. RDB는 C, R, U, D 가 기본적인 명령어지만 Firebase는 Set, update, remove, 그리고 R에 해당하는 on, once 메소드가 그 역할을 대신한다. 그마저도 1:1로 대응하는 기능은 아니다.
• 문제는 NoSQL은 Json 구조적 특성때문에 검색 기능이 빈약하다는 것이다.

---

FireStore

• Cloud Firestore는 NoSQL 문서 중심의 데이터베이스입니다. SQL 데이터베이스와 달리 테이블이나 행이 없으며, 컬렉션으로 정리되는 문서에 데이터를 저장합니다.
• 각 문서에는 키-값 쌍이 들어 있습니다. Cloud Firestore는 작은 문서가 많이 모인 컬렉션을 저장하는 데 최적화되어 있습니다.
• 모든 문서는 컬렉션에 저장되어야 합니다. 문서는 하위 컬렉션 및 중첩 개체를 포함할 수 있으며, 둘 다 문자열 같은 기본형 필드나 목록 같은 복합 개체를 포함할 수 있습니다.
• 컬렉션과 문서는 Cloud Firestore에서 암시적으로 생성됩니다. 사용자는 컬렉션 내의 문서에 데이터를 할당하기만 하면 됩니다. 컬렉션 또는 문서가 없으면 Cloud Firestore에서 자동으로 생성합니다.
• Cloud Firestore의 저장소 단위는 문서입니다. 문서는 값에 매핑되는 필드를 포함하는 간단한 레코드입니다. 각 문서는 이름으로 식별됩니다. , 일반적으로는 문서를 간단한 JSON 레코드로 취급해도 무방합니다.
• 문서는 컬렉션에 저장되며, 컬렉션은 단순히 문서의 컨테이너입니다.
• 파이어베이스와 앱이 소켓으로 연결되어 실시간 서비스를 구축하기 용이하다.

 

https://firebase.google.com/docs/firestore/data-model?authuser=0

Cloud Firestore 데이터 모델  |  Firebase

FireStore : 글로벌 앱을 위해 구축된 NoSQL 데이터베이스

RealtimeDB는 서버확장이 자동적으로 지원되지 않음. 따라서 DB를 추가로 생성해야함.

파이어스토어는 서버확장도 알아서 진행되기 때문에 사용자가 많아질 경우 서버 확장에 대한 걱정을 놓을 수 있음.

*무료저장공간 : 1GB

 

Firebase의 장점

소켓으로 연결되어 실시간 서비스를 구축하기 용이하다.

실시간 접속 수 상한 없음.

 

단점

느리다

쿼리가 구리다

---

Cloud Firestore로 실시간 업데이트 가져오기

onSnapshot() 메서드로 문서를 수신 대기할 수 있습니다. 소켓으로 연결되어 있기 때문이다. 사용자가 제공하는 콜백이 최초로 호출될 때는 단일 문서의 현재 내용으로 문서 스냅샷이 즉시 생성됩니다. 그런 다음 내용이 변경될 때마다 콜백이 호출되어 문서 스냅샷을 업데이트합니다.

 

데이터의 변경을 실시간으로 감지할 수 있다.

---

소켓

소켓(Socket)은, 프로세스가 네트워크를 통해서 데이터를 주고받으려면 반드시 열어야 하는 창구 같은 것이다.

​

 

컴퓨터 세계관에서는 프로세스가 데이터를 보내고 싶다고 해서 막 보낼 수 있는 게 아니고, 그들만의 법칙이 있는데, 바로 보내는 쪽도 받는 쪽도 소켓을 열어야 한다는 점이다. 보내는 쪽이 소켓이라는 창구를 열고 소켓을 통해서 데이터를 보내면 네트워크 모델에 따라 목적지 호스트에 데이터가 도착하게 되고, 데이터를 담은 봉투에 써진 도착지의 포트 넘버와 같은 포트를 할당받은 프로세스를 찾아서, 그 프로세스의 소켓을 통해 해당 프로세스에 데이터를 전달한다.

​

소켓을 열기 위해선 호스트에 할당된 IP 주소, 포트 넘버, 프로토콜(Protocol) 등이 필요하며, 이 세 가지가 소켓을 정의한다.

 

http://blog.naver.com/PostView.nhn?blogId=myca11&logNo=221389847130

소켓(Socket) 포트(Port) 뜻과 차이

 

https://www.samsungsds.com/global/ko/support/insights/1195843_2284.html

BaaS (Backend as a Service)

보통, 우리가 모바일 혹은 웹 애플리케이션을 만들게 될 때, 백엔드 서버개발을 진행하게 됩니다. 엄청 단순하게 생각하자면, 계산기, 혹은 그림판 수준으로 프론트엔드 쪽 코드로만 충분히 이뤄질 수 있다면, 백엔드 서버를 만들 필요가 없겠죠. 하지만, 데이터를 저장하고, 다른 기기에서도 접근하고, 공유하기 위해서는, 백엔드 개발은 필수적입니다.

서버 개발을 하다보면, 고려할 사항이 꽤 많죠. 유저가 늘어나게 된다면 서버의 확장도 고려해야 하고, 보안성 또한 고려해야 하죠. 그래서 탄생한 서비스가, Firebase 같은 BaaS 입니다. 이 시스템에서는, 앱 개발에 있어서 필요한 다양한 기능들 (데이터베이스, 소셜서비스 연동, 파일시스템 등)을 API로 제공해 줌으로서, 개발자들이 서버 개발을 하지 않고서도 필요한 기능을 쉽고 빠르게 구현 할 수 있게 해주고, 비용은 사용 한 만큼 나가게 되죠. 서버의 이용자가 순식간에 늘어나게 되어도, 따로 대비를 안해주어도 알아서 확장이 됩니다.

현존하는 BaaS 중 가장 대중화 되어있는것은 Firebase 이기 때문에, 이 포스트에선 Firebase 를 사용한다는 가정하에 장점과 단점들을 나열해보도록 하겠습니다.

BaaS를 사용함에 있어서, 가장 큰 장점은 개발 시간의 단축 (회사 입장으로서 생각한다면, 인건비), 서버 확장 작업의 불필요함입니다. 백엔드에 대해서 지식이 별로 없더라도, 아주 빠른 속도로 개발이 가능합니다. 특히, Firebase 에서는 실시간 데이터베이스를 사용하여 데이터가 새로 생성되거나, 수정되었을 때 소켓을 사용하여 클라이언트에게 바로 반영시켜주는 기능이 있는데요, 이러한 기능은 직접 개발하게 된다면 구조 설정에 꽤 많은 시간이 필요 할 수도 있는데 이를 단지 코드 몇줄만으로 구현 할 수 있게 해주는 멋진 기능들을 지니고 있습니다. 추가적으로, 일정 사용량 만큼 무료로 사용 할 수 있기 때문에 토이 프로젝트, 소규모 프로젝트의 경우 백엔드로서 매우 유용하게 사용 할 수 있습니다.

하지만, 무조건 장점만 있는것은 아닙니다. BaaS를 사용함으로서, 발생하는 대표적인 단점으로는 다음과 같은것들이 있습니다.

1. 클라이언트 위주의 코드

이 부분은 어떻게 관리하냐에 따라 다르긴 하겠지만, BaaS 를 사용함으로서, 백엔드 로직들이 클라이언트쪽에 구현이 됩니다. 예를들어 이메일 발송, 결제 처리 등의 작업들을 클라이언트에서 수행하고 싶지는 않겠죠?

Firebase 의 경우에는 서버쪽에서도 사용이 가능하긴 합니다. Firebase SDK 를 불러와서 사용하는거죠. 일부 로직을 직접 서버측에서 구현할 바에, 그냥 모든 로직을 직접 구현하는건 어떨까요?

추가적으로, 데이터단의 로직이 변경되면… 클라이언트 코드의 수정이 이뤄지게됩니다. 그러면, 재배포를 해야되겠죠? 웹어플리케이션이라면 JS 를 새로 받아야하는데, 이건 별로 큰 일은 아니지만, 모바일 앱이라면, 앱 업데이트를 해야합니다. 그리고 상황에 따라서 구버전 사용자를 강제 업데이트해야 하는일이 발생 할 수도 있겠죠.

2.가격

Firebase 의 경우엔 초반엔 무료입니다. 이는 소규모 프로젝트에는 정말 매력적으로 다가 올 수 있는 장점인데요, 하지만 앱의 규모가 커지면, 가격이 꽤 비쌉니다. 실시간 데이터베이스에 10G 가 쌓이고, 한달 전송되는 데이터의 양이 20G 정도면 데이터베이스 비용으로만 $70 가 발생합니다.

참고로 클라우드 컴퓨팅 호스팅을 해주는 서비스 Vultr 의 가격대를 보면, $10 면 40GB SSD, 2000GB 월 대역폭을 사용 할 수 있습니다.

따라서, 사용자가 별로 없을 것 같은 서비스면 Firebase 는 정말 좋은 선택입니다. 하지만, 서비스의 규모가 커질수록 직접 구현을 했을 때 대비 지출되는 비용이 늘어날 것입니다.

3. 복잡한 쿼리가 불가능함

Firebase 는 데이터베이스가 하나의 큰 JSON 객체로 구조화 되어있습니다. RDBMS 의 테이블, 관계 같은 개념이 존재하지 않기 때문에 최대한 데이터베이스 모델을 비정규화 하여 사용하는 것이 좋습니다. 예를들어서 게시글을 조회한다고 가정해봅시다.

Firebase 를 통하여 다음과 같은 작업은 할 수 있습니다

• 2018년 1월 1일 ~1월 31일 사이에 작성된 글 조회
• velopert 가 작성한 글 조회

그런데 이런건 못합니다.

• velopert 가 1월 1일 이후에 작성한 글 조회

그래서, 이러한 작업을 하려면 모델링을 할 때 다음과 같이 username_date 라는 필드를 만들어야 합니다.

{ username: 'velopert', date: '20180101', username_date: 'velopert_20180101' }

그렇게 하고 나서, username_date 를 가지고 쿼리를 해야합니다.
불가능한건 아닌데… 이렇게 까지 해야하나 싶죠. 저는 맘에 안듭니다.

저의 경우엔 Firebase 를 사용하여 특정 유저를 팔로우하고, 팔로우한 유저의 글을 모아보는 기능을 구현하다가 Firebase 만으로는 해결 할 수 없는 한계를 느껴 때려치고 백엔드 개발을 처음부터 다시 한 경험이 있습니다.

정리

정리를 하자면, Firebase 는 어떠한 개발자들은 매우 강력한 도구로서 사용 하는 반면에, 저를 비롯한 어떠한 개발자들은 Firebase 의 구조를 불편해하고, 한계를 느끼는 사람들도 있습니다. 그리고 분명히, 그러한 한계는 이런저런 꼼수를 사용하여 극복할 수 있다고 생각하지만, 굳이 그렇게해야하나 싶습니다.

실시간 데이터베이스가 정말로 필요한 서비스라면, 일부 기능에서 Firebase 를 사용하는것은 정말 좋은 선택일 수도 있습니다. 비용이 비싸질 수도 있지만 그러한 기능을 구현하기 위해서 들어가는 많은 개발 공수가 절약 될 수도 있습니다. 참고로, 실시간 기능을 최소 공수로 구현하고 싶다면 Feather.js 라는 것도 있으니 참고해보시길 바랍니다! (아, 물론 이건 서버가 필요합니다.)

 

NoSQL이란 무엇인가? 대량데이터 동시처리위한 DBMS 종류와 특징