Firestore 컬렉션 설계 기준과 방법

참고자료

https://simsimjae.medium.com/firestore-%EC%BB%AC%EB%A0%89%EC%85%98%EC%9D%84-%EC%84%A4%EA%B3%84%ED%95%98%EB%8A%94-%EA%B8%B0%EC%A4%80%EA%B3%BC-%EB%B0%A9%EB%B2%95-c4916aee510a

Firebase는 Collection과 Document가 있다.

Collection이 Document를 가질 수 있고,
Document도 Collection을 가질 수 있다.

Collection - Document - Collection - Document...

중첩구조 100depth까지는 Collection, Document 반복이 가능하다고 한다.

개인앱을 만들던 도중, 고민거리가 생겼다.

PushAlarm 보낼 User들을 DB에 저장하려고 하였는데,

1. PushAlarm Document의 Users 배열 필드로 유저들을 저장할지
2. PushAlarm Document(탑레벨)의 User 하위컬렉션(세컨드레벨)을 만들어서 User들을 저장할지
3. PushAlarm Collection(탑레벨)의 Users Collection(탑레벨)을 만들어서 거기에 모든 유저를 관리할지

세가지 방식중 어떤것을 선택해야 할지 판단 기준이 서지 않아 조사를 해봤다.

1번방식(필드에 저장)을 사용하게 되면
데이터 중복이 발생하지만 nosql의 장점을 최대한 활용 할 수 있다.
즉, 변화가 적고 하나의 큰 데이터를 빠르게 불러올 수 있다.

반면 rdbms는 각 도메인들이 서로 복잡하게 얽혀있고 업데이트가 자주 일어나면서 데이터 중복을 없에고 싶을때 효율적이다.

1번방식은 nosql의 데이터 중복을 허용하는 대신 빠른 read를 보장하는 장점을 최대한 활용한 방식이다.

2번방식(루트 컬렉션)을 사용하게 되면
하나의 PushAlarm에 딸린 User들을 더 적은 양의 쿼리로 검색할 수 있다. 왜냐하면, 해당 알림의 User만이 궁금하기 때문에 전체 User들을 조회할 필요가 없기 때문이다.

3번방식(루트 컬렉션)을 사용하게 되면
모든 알람들을 조회해야하는 상황에서는 굉장히 좋은 설계이다. 서비스의 모든 유저들이 Users루트 컬렉션에 모이기 때문이다.
만약 2번 방식으로 설계하였다면 서비스에 어떤 Alarm들이 있는지 조회한 다음 각 Alarm들의 하위 User컬렌션을 전부 조회해야 모든 User들을 가져 올 수 있을것이다.

결론

• 만약 서비스에서 모든 User들을 조회할것이라면 3번
• 모든 User들을 조회할일이 없으며, 각 알람에 해당하는 유저들만 조회하는 경우에는 2번방식
• 데이터 중복이 발생하더라도 빠른 read속도를 보장하고 싶다면 1번 방식을 사용하는것이 좋다.

해당 알람에 등록한 모든 User들을 호출해야 함으로 3번으로 진행하였다.