[Firestore] 컬렉션이냐 맵이냐의 Arry냐.

개시하다

Firestore로 데이터 양이 커지지 않을 것으로 예상되는 기술 블로그의 태그 등 데이터를 관리할 때

모음으로 여러 문서 보관

Map형(대상형)의 배열로 문서에 저장

나는 어떤 방법을 취해야 할지 고려했다.
나중에 두 가지 저장 방법을 모음, 맵 정렬이라고 합니다.
!
Firestore에 저장된 문서의 크기는 1MiB입니다.
문서 크기를 계산하는 방법은 여기.입니다.
이 글에는 맵형 배열로 한 문서에 저장될 경우 데이터의 양을 대량으로 추정해도 1MiB를 넘지 않을 경우를 적었다.

구체적 예

구체적인 데이터의 예로 기술 블로그 등 라벨의 데이터를 고려한다.100개의 표시가 있다고 가정해 보세요.
다음 획득 시간의 측정에서 이 데이터를 사용하여 측정한다.
모음 예

맵형 정렬 예

비교

다음 세 가지 방법을 비교합니다.

모든 항목 획득에 걸린 시간

Firestore에서 100개의 탭 데이터를 모두 얻는 데 각각 5차례, 데이터를 얻는 데 필요한 시간을 측정했다.
모음집 (ms)
Map의 Aray(ms)
179.6
101.4
68.7
45.6
102.3
46.4
62.9
54.8
74.3
46.9
평균:97.6
평균:59.0
수치의 편차가 크다는 점에 신경을 썼지만, 컬렉션이 맵형 배열보다 2배 가까이 처리 시간이 걸리는 것으로 밝혀졌다.
실측하기 전에 한 문서만 얻는 맵형 배열에 비해 100개의 문서 수집 방식을 얻는 데 100배 가까이 걸릴 것으로 생각했지만 큰 차이가 없었다.
측정에 사용된 전선은 여기에 있다

// コレクションの全件取得
const subCollection = () => {
  const start = performance.now();

  return getDocs(collection(db, "コレクションのパス")).then((snaps) => {
    const end = performance.now();
    console.log(`subCollection: ${end - start} ms`);

    console.log(snaps.docs.map((doc) => doc.data()));
  });
};

// Map型の配列の全件取得
const mapArray = () => {
  const start = performance.now();

  return getDoc(doc(db, "ドキュメントのパス")).then((snap) => {
    const end = performance.now();
    console.log(`mapArray: ${end - start} ms`);

    console.log(snap.data()?.tags);
  });
};

for (let i = 0; i < 5; i++) {
  await subCollection();
  await mapArray();
}

Firestore 사용량

Firestore 비용 계산에 사용된'문서 읽기 횟수','문서 쓰기 횟수','하행 네트워크 사용량'을 비교했다.

모두 획득 시

소장한'문서를 읽는 횟수'는 문서의 총수(이번 예는 100)이고, 맵형의 배열은 한 번만 하면 되기 때문에 맵형의 배열이 비교적 적합하다.

1 개만 획득한 경우

'문서를 읽는 횟수' 는 모두 한 번입니다. '하행 네트워크 사용량' 은 모음에 있는 라벨의 데이터이고, 맵형 Arry에는 모든 데이터의 합계입니다.그래서 소장이 더 잘 어울려요.

새로 만들기/업데이트할 때

라벨을 업데이트하고 만들 때 사용량이 동일합니다.
여러 레이블을 취합, 제작, 업데이트할 때 한 번에 작성할 수 있는 맵형 배열이 더 적합합니다.

기타 장점과 단점

맵형 배열로 조회한 경우 클라이언트 측에서 정렬된 필터, 정렬을 모두 가져오고 정렬합니다.데이터의 건수, 조회의 계산량, 단말기의 규격에 따라 처리 시간이 비교적 길 수 있다.

각 문서에 대한 액세스는 모음에서 Firestore rule에서 제어할 수 있습니다.

총결산

지금까지의 항목에 따라 데이터 양이 1MiB를 넘지 않을 경우 이번에 예시로 설명한 태그 같은 데이터를 맵형 배열로 저장하면 좋은 점이 많다.
특히 전체 파일을 받았을 때'문서를 읽는 횟수'가 1로 바뀌면서 Firebase 요금이 크게 줄어들 수 있다는 게 중요한 장점이라고 생각한다.
한편, 데이터 필드의 양이 증가해 맵형으로 배열하면 1MiB를 넘거나 데이터의 건수가 많을 수 있고, 고객 측 조회가 어려운 상황에서Firestore Rules의 상세한 접근 제어가 필요한 경우에는 컬렉션을 해야 한다.
여기까지 읽어주셔서 감사합니다.만약 이 보도에 잘못된 부분, 오해를 일으킨 부분, 건의 등이 있다면, 반드시 평론에서 나에게 알려주세요!