[Firestore] 1편 - 개념/구조/모델

Firestore api와 Firestore security rules 막상 사용하려니 부족한 부분마다 가이드를 찾아 들어가고 있는 것을 느껴 다시 정독하여 싹 정리해보려고 한다.

 

https://firebase.google.com/docs/firestore/data-model

Cloud Firestore 데이터 모델  |  Firebase Documentation

 

컬렉션이나 문서가 없을 때, 데이터를 할당하면 자동으로 컬렉션과 문서가 생성되면서 데이터가 write된다.

---

JSON과 비슷하지만 문서는 추가 데이터 타입을 지원하고, 문서의 사이즈는 1MB로 제한된다.

경량 JSON으로 볼 수 있다.파이어스토어는 컬렉션, 문서라는 개념이 존재한다.

데이터는 JSON형식과 비슷하다.

다른점은 데이터는 문서에만 포함될 수 있는데 문서 하나당 1MB제한이 있으므로 데이터는 1MB를 넘을 수 없다.

또한 추가적인 데이터 타입 몇가지를 더 제공한다.

---

데이터는 컬렉션이 아닌 문서에만 저장될 수 있다.

그렇기 때문에 컬렉션 바로 하위에 데이터를 조작할 수 없으면 중간에 문서를 꼭 만들어 줘야 한다.

컬렉션- 데이터 (x)

문서- 데이터(o)

---

일반적으로는 컬렉션 하위에 여러문서들을 배치하지만 다음과 같이 문서 하위에 여러 컬렉션들을 포함시킬 수도 있다.

 

컬렉션 대한민국- 문서 서울시 - 컬렉션 중구     - 문서 xx동   - 데이터

                                                              - 문서 xx동2 - 데이터

                                     - 컬렉션 동대문구  - 문서 oo동   - 데이터

                     - 문서 경기도 - ......

---

데이터베이스의 바로 하위에는 컬렉션부터 생성해야 한다. 문서를 배치할 수 없다(루트 컬렉션)

루트- 컬렉션 - 문서 - 데이터 (o)

루트- 문서 - 데이터 (x)

---

또한 문서 하위에 바로 문서를 만들 수 없고 컬렉션이 중간에 존재해야 한다.

---

어렵게 말했는데 위의 내용들을 종합하면 컬렉션과 문서는 교차로만 배치될 수 있다.

 

컬렉션1 - 문서1 - 데이터

                      - 컬렉션2 - 문서2 - 데이터

                                    - 문서3 - 컬렉션3 - 문서4 - 데이터

 

                                  

- 컬렉션 path는 홀수만 된다.

컬렉션1  (1)

컬렉션1/문서1/컬렉션2 (3)

 

- 문서 path는 짝수만 된다.

컬렉션1 /문서1 (2)

컬렉션1 /문서1/ 컬렉션2/ 문서2 (4)

모든 데이터는 문서에만 저장되기 때문에 이 짝수 path를 통해 데이터를 read, write할 수 있다.

 

Firestore 콘솔에서 데이터를 추가시켜 보면 + 버튼을 제공해주는 것을 통해 어느 것이 포함될 수 있는가 확인 가능하다.

---

컬렉션 바로 하위에 포함된 문서들은 이름이 중복될 수 없다.

문서 바로 하위에 포함된 컬렉션들은 이름이 중복될 수 없다.

 

컬렉션1 - 문서1

           - 문서1 (x)  //이름 중복

 

컬렉션1 - 문서1 - 컬렉션2 - 문서1 (o) //컬렉션1 바로 하위만 아니면 중복된 이름 문서1을 사용 가능

 

컬렉션의 경우도 같다.

컬렉션1 - 문서1 - 컬렉션2 -문서2 - 데이터

                      - 컬렉션2 -... (x)  //컬렉션 이름 중복

 

콘솔에서 동일이름의 문서를 추가시키면 빨간색 오류가 나타나고,

동일이름의 컬렉션을 추가시키면 추가가 아닌 기존에 존재하는 컬렉션으로 선택된다. 

---

컬렉션 위치인 CollectionReference, 문서 위치인 DocumentReference

Firestore 데이터베이스의 위치를 나타내는 reference들은 단순히 나타내고 있는 위치이다.

컬렉션,문서가 존재하든 안하든 이 reference들을 생성할 수 있다.이 reference를 생성하는 것은 문서나, 컬렉션을 생성하는 네트워크 오퍼레이션을 하는 것이 아니다.(단순히 Java File 처럼 추상경로에 해당됨)

---

문서 하나는 1MB 제한을 가진다.

개인적으로 궁금했던 부분이 있었는데

문서 하위에 컬렉션들이 많이 존재하고 , 그 컬렉션들에 많은 문서들이 포함되어 있는 경우, 상위 문서의 데이터로 포함되는 것으로 간주되어 1MB가 금방 넘어버리지 않을까 였다.

 

문서 하위에 포함된 컬렉션들의 데이터들은 문서의 데이터에 포함되지 않고 위치 linking만 된다.

 

다음과 같이 rooms(채팅방)컬렉션에 roomA(A방), roomB(B방)의 문서가 있다.

만약 A방의 채팅메세지들을 roomA문서의 데이터에 축적시키면, 채팅메세지가 조금만 쌓여도 roomA의 문서가 1MB를 넘어버릴 것이다. 가이드라인에서는 문서는 경량으로 사용해야 한다면서 서브 컬렉션을 통해 메세지 데이터를 저장할 것을 권하고 있다.

 

roomA 문서에 서브 컬렉션 messages를 만들고 메세지 하나마다 문서하나에 해당되도록 생성

 

이것을 통해 유추해보면 문서하위의 컬렉션들의 데이터들은 문서에 포함되지 않는 것으로 해석할 수 있다.

(messages 컬렉션의 모든 데이터들은 roomA문서에 포함되지 않고, 단순히 문서에 포함되어 있는 것)

---

 

서브 컬렉션을 가지고 있는 상위 문서를 삭제하면 하위 서브 컬렉션은 삭제되지 않는다.

 

Firestore api를 사용하는 것은 밑이나 다음 포스팅에서 다룰 것이다.

일단 하위 컬렉션을 포함하고 있는 문서를 삭제해보자.

문서 하위에 포함된 서브 컬렌션이 남아있는 것을 확인할 수 있다.

 

다른 것을 선택하고 해당 컬렉션을 다시 확인해보면 삭제된 문서는 이탈릭체로 적용되어있다.

콘솔에서는 남아있는 것처럼 보이지만 쿼리나 문서데이터를 확인해보면 나타나지 않는다고 한다.

 

그렇다면 딸랑 남아있는 컬렉션은 어떻게 지울까 확인해봤다.

클라이언트에서 추천되지 않는다며 스닙셋이 없었다.

해당 페이지에서 또 들어가니 Cloud Function을 사용하라고 되어있다.

Cloud Function은 일단 유료기 때문에 , Firebase CLI(데스크탑에 설치하여 커맨드라인)나 Firebase 콘솔을 통해 지워야 할 것 같다.

---

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

데이터 구조 선택  |  Firebase Documentation

참고

파이어스토어는 SQL을 모방한 쿼리기능을 Query 클래스가 제공하는데 CollectionReference가 상속받고 있다.

Query클래스를 통해 컬렉션 하위에 쿼리 조건에 해당하는 문서들 여러개를 가져올 수 있다.

 

• 문서 내에서 중첩 데이터 사용

데이터들이 늘어나지 않는 경우에 사용해야함(문서는 사이즈가 제한되어있다)

 

• 서브 컬렉션을 사용

위의 문서 내에서 중첩 데이터를 사용할 때의 단점의 해결책으로 문서 하위에 서브 컬렉션을 생성하면 parent문서의 데이터로 포함이 되지 않는다.

서브 컬렉션에도 풀 쿼리가 된다고 한다. 이후의 포스팅어딘가에서 적어본다.

 

• 루트 컬렉션을 사용

분리된 목적의 데이터를 편성할 때 사용