할당량 및 한도, 비용
•
필드 값 최대 크기: 1Mib ()
•
document 최대 크기 : 1Mib
쿼리 결과로 읽어온 document 갯수에 따라 비용이 청구됨
사용량 대시보드 불일치
•
가져오기 / 내보내기 작업은 대시보드에 포함되지 않음
•
노옵스 쓰기
데이터베이스가 변경되지 않는 작업(필드 값을 변경하지 않는 업데이트, 삭제된 문서에 쓰기 등)도 청구 대상 작업에 포함된다. But 대시보드에는 포함되지 않음
•
축소된 쓰기
동일 문서에 여러번의 쓰기 작업이 연속으로 빠르게 발생하는 경우 대시보드에서는 한 번의 쓰기로 축소하여 계산
•
0개의 결과를 반환하는 쿼리
읽기작업 1회에 대한 비용이 발생하나, 대시보드에는 표시되지 않음
쿼리
단일 쿼리 가능하지만 복합 쿼리 불가능 (지원하지 않음)
ex) date가 오늘인 document 가져오기 O
date가 오늘이면서 keyword가 “샌드박스”인 document 가져오기 X
→ 이런 경우는 pandas를 사용해 데이터를 필터해야함
자동 생성된 id 사용하여 업데이트하기
.document().set()
firestore 구조 변경
비용, 속도를 고려하여 개선
firestore 기본 구조
문서의 중첩 데이터
document 내 field 안에 데이터를 저장하는 방법
•
장점: 데이터 구조의 간소화. 비용 절감 가능
•
단점: 데이터 양이 증가하면 확장성 부족, 문서가 커지면서 문서 검색 속도가 느려질 수 있음
최근 키워드
- 특정 사용자의 검색 키워드가 계속 쌓이는 형태. 계속 증가함
→ 장점: document 하나면 불러오면 되므로 비용 절감 가능
단점: document 크기 한도 문제 (날짜별이 아닌 전체적으로 쌓이기 때문에 시간이 지날수록 크기가 커짐)
최다 키워드
- 하루마다 검색된 키워드가 쌓이는 형태.
→ 장점: 최근 키워드와 동일하게 비용 절감 가능
단점: document 크기 한도 문제 (전체 사용자의 검색어를 카운트… 용량이 부족할 경우가 생기지 않을까?)
하위 컬렉션
document 내 서브 컬렉션 생성하여 document를 저장하는 방법
•
장점: 데이터가 시간에 따라 증가하더라도 상위 document 크기는 그대로. firestore의 쿼리 사용가능
•
단점: 하위 컬렉션 삭제가 어려움. document 수 증가. 복합 쿼리 불가 → 가져와야하는 document 수 증가 → 비용 증가
최근 키워드
→ 장점: document를 단일 쿼리 사용하여 가져오기 가능
단점: groupby 지원 x, document 수 증가 → 비용 증가
루트 수준 컬렉션
데이터베이스 루트 수준에 컬렉션을 만들어 상이한 데이터 세트 정리
•
장점: 다대다 관계에 적합함. 쿼리 사용 가능
•
단점: 계층 구조를 가진 데이터를 가져오기가 복잡해짐
검색 키워드 저장
→ 장점:
단점: document 수 증가. 복합쿼리 불가
최다 키워드는 날짜별 document 저장 → 한번 읽어올 때 약 14개의 document를 읽어옴
최근 키워드를 하위 컬렉션으로 변경한다면 불러와야하는 document가 증가. but 개인 한명이 15일 이내 검색한 키워드이므로 document 갯수가 크지 않을 것으로 생각됨