Realtime Database
- 데이터를 하나의 큰 JSON 트리로 저장
- 단순한 데이터 → 매우 쉽게 저장
- 복잡한 계층적 데이터 → 대규모로 정리하기 어려움
- 로컬에 저장하고 있다가 네트워크가 연결되면 저장했던 데이터를 동기화 시켜 오프라인 상태에서 데이터 유지 (Apple, Android)
- 클라이언트의 접속 상태 지원됨
- 제한적인 정렬 및 필터링 기능을 갖춘 깊은 쿼리
- 쿼리에서 속성을 정렬 또는 필터링할 수 있으나, 두 가지를 함께 진행하는 것은 불가
- 깊은 쿼리가 수행되어 항상 전체 하위 트리를 반환
- 불필요하게 큰 데이터까지 매번 가져와야 하기 때문에 매우 심각한 성능 저하 발생 가능성 O
- 확장을 하려면 DB를 여러 개로 나눠야 함(샤딩)
- 한 번에 많은 사용자와 데이터를 주고 받는 것이 가능하지만, 초당 데이터를 업데이트 하는 횟수가 초당 약 1000번으로 제한됨
- 각 DB는 독립적으로 동작하므로 개별 데이터에 빠르게 쓸 수 있음
Cloud Firestore
- 비교적 최근 모델
- 데이터를 문서 컬렉션으로 저장
- 단순한 데이터 → 문서에 쉽게 저장 (JSON과 매우 비슷)
- 복잡한 계층적 데이터 → 문서에 있는 하위 컬렉션을 사용해 대규모로 쉽게 정리
- 비정규화 및 데이터 평면화가 덜 필요
- 로컬에 저장하고 있다가 네트워크가 연결되면 저장했던 데이터를 동기화 시켜 오프라인 상태에서 데이터 유지 (Apple, Android, 웹 클라이언트)
- 클라이언트의 접속 상태 지원 X (기본적으로는 불가능하나, 지원을 활용할 수도 있음)
- 복합 정렬 및 필터링 기능을 갖출 색인화된 쿼리
- 필터링과 정렬을 결합(동시사용) 가능
- 쿼리가 얕아 특정 컬렉션이나 컬렉션이 가진 문서만 반환
- 불필요한 하위 데이터까지 반환하는 성능 문제 발생 X
- 자동으로 확장이 이루어짐
- 많은 동시연결과 초당 데이터 업데이트를 처리할 수 있음 (초당 약 10000번까지 가능)
- 개별 문서나 색인에는 데이터 쓰기 속도 제한 O
Realtime Database vs Cloud Firestore
- 큰 단위의 데이터 요청이 자주 발생한다면 firestore가 유리
- 가벼운 데이터지만 문서에 대한 CRUD작업이 자주 발생한다면 realtime database가 유리
'Study' 카테고리의 다른 글
[Protocol] HTTP 정리 (0) | 2023.10.16 |
---|---|
[HTTP] HTTP message (0) | 2023.10.13 |
[Web] Stateful / Stateless 차이 (2) | 2023.10.11 |
[JSON] JSON 정리 (1) | 2023.10.11 |