Firebase Firestore 정리

요 며칠 Firestore 관련해서 삽질을 많이 했다. 느낀 점을 정리해본다. 

1. 읽고 , 쓰기 속도는 좀 걸린다. 

- 최소 1~2초정도 걸린다. 이점을 고려해서 설계를 해야 할것 이다. 

2. 모델링시 방법이 많은데 대략 3가지를 소개하고 있다. 

https://firebase.google.com/docs/firestore/manage-data/structure-data?hl=ko

문서의 중첩 데이터

문서 내에 배열(맵) 등의 복합 개체를 중첩할 수 있습니다.

장점: 문서 안에 단순한 고정 데이터 목록을 보관하려는 경우 데이터 구조를 손쉽게 설정하고 간소화할 수 있습니다. 한계: 중첩 목록에 대해 쿼리를 실행할 수 없습니다. 또한 시간에 따라 데이터가 증가하는 경우 다른 옵션보다 확장성이 부족합니다. 목록이 커지면 문서도 커지므로 문서 검색 속도가 느려질 수 있습니다. 가능한 사용 사례: 예를 들어 채팅 앱에서 사용자가 가장 최근에 입장한 대화방 3개를 프로필에 중첩 목록으로 저장할 수 있습니다.

class alovelace     name :       first : "Ada"       last : "Lovelace"     born : 1815     rooms :       0 : "Software Chat"       1 : "Famous Figures"       2 : "Famous SWEs"

하위 컬렉션

데이터가 시간에 따라 증가할 가능성이 있다면 문서 내에 컬렉션을 만들 수 있습니다.

장점: 목록이 커져도 상위 문서의 크기는 그대로입니다. 또한 하위 컬렉션에 대해 모든 쿼리 기능을 사용할 수 있습니다. 한계: 하위 컬렉션을 삭제하거나 여러 하위 컬렉션을 대상으로 복잡한 쿼리를 수행하기가 어렵습니다. 가능한 사용 사례: 동일한 채팅 앱에서 채팅방 문서 안에 사용자 또는 메시지의 컬렉션을 만들 수 있습니다.

collections_bookmark science class software   name : "software chat" collections_bookmark users class alovelace     first : "Ada"     last : "Lovelace" class sride     first : "Sally"     last : "Ride"` class astrophysics ...

루트 수준 컬렉션

데이터베이스 루트 수준에 컬렉션을 만들어 상이한 데이터 세트를 정리합니다.

장점: 루트 수준 컬렉션은 최대한의 유연성과 확장성을 발휘하며 각 컬렉션 내에서 강력한 쿼리 기능을 사용할 수 있습니다. 한계: 데이터베이스가 커지면 본질적인 계층구조를 갖는 데이터를 가져오기가 점점 복잡해질 수 있습니다. 가능한 사용 사례: 동일한 채팅 앱에서 사용자 컬렉션 하나와 채팅방 및 메시지 컬렉션 하나를 만들 수 있습니다.

collections_bookmark users class alovelace     first : "Ada"     last : "Lovelace"     born : 1815 class sride     first : "Sally"     last : "Ride"     born : 1951 collections_bookmark rooms class software collections_bookmark messages class message1     from : "alovelace"     content : "..." class message2     from : "sride"     content : "..."

3. 그리고 컬렉션이 아니라 내부 맵(배열)에서 검색이 가능하다. 

https://firebase.google.com/docs/firestore/solutions/arrays?hl=ko

내부적으로 맵을 넣어서 계층 검색을 할 수가 있다. 

즉 members -> document id(컬렉션) -> member(객체들) 

이런 구조이면 member 안에 map 형태를 넣어서 할수 있다.

예를 들어 map( key : photo , value : "path") 맵을 넣어서 

whereEqualTo(member.photo , "path") 로 쿼리 가능 하다는 것이다. 

4. 그리고 레퍼런스도 넣을 수 있다. 

DocumentReferecne 를 객체에 삽입해서 넣을 수 있다. 

하지만 가져올땐 계층적으로 못 가져오고 DocumentReference 를 가져오긴 한다. 흠..별 필요가 있는지?? ㅋㅋ

단점..

아직 서버쪽 어드민에서 Firestore를 지원 안해준다.. ㅠㅠ 

관리를 어떻게 해야할지 막막하다..

아직 베타라서 그런지 서비스가 지원안되는게 좀 있다는 점?

속도가 중요한 앱은 설계를 잘 해야 할 것 같다.  

1~2초씩 기본적으로 걸린다..