이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Firestore 실시간 데이터베이스와 함께 Cloud Firestore 사용

앱에서 Firebase Realtime Database 및 Cloud Firestore를 모두 사용할 수 있습니다. 니즈에 맞게 각 데이터베이스 솔루션의 이점을 활용할 수 있습니다. 예를 들어 Realtime Database의 인지도 지원을 활용하는 것이 좋습니다. 자세한 내용은 Cloud Firestore에서의 접속 상태 구축.

데이터베이스 간 차이점을 자세히 알아보세요.

데이터를 Cloud Firestore로 이동 중

일부 데이터를 Realtime Database에서 Cloud Firestore인 경우 다음 흐름을 고려하세요. 데이터베이스마다 고유한 요구사항과 구조적 고려사항이 있기 때문에 이전 경로가 자동화되어 제공되지는 않습니다. 대신 이 같은 일반적인 진행 절차를 따르면 됩니다.

Realtime Database의 데이터 구조 및 보안 규칙을 Cloud Firestore Realtime Database와 Cloud Firestore는 모두 Firebase 인증을 사용합니다. 앱의 사용자 인증을 변경할 필요가 없습니다. 그러나 보안 규칙과 데이터 모델은 다르기 때문에 데이터를 클라우드로 이전하기 전에 이러한 불일치를 고려하세요. Firestore로 이동합니다
이전 데이터를 이동합니다. Cloud Firestore에서 새 데이터 구조를 설정할 때 다음 작업을 할 수 있습니다. 기존 데이터를 매핑하고 Realtime Database에서 새 Cloud Firestore로 이동 인스턴스를 만들 수 있습니다 그러나 앱에서 두 데이터베이스를 모두 사용하는 경우 Realtime Database 밖으로 이전 데이터를 이동할 필요가 없습니다.
새로운 데이터를 실시간으로 Firestore에 미러링합니다. Cloud Functions를 사용하여 새 Cloud Firestore에 새 데이터 쓰기 Realtime Database에 추가될 때 데이터베이스에 저장됩니다.
Cloud Firestore을(를) 마이그레이션된 데이터의 기본 데이터베이스로 설정합니다. 일부 데이터를 이전한 후에는 Cloud Firestore을 사용합니다. 기본 데이터베이스로 설정하고 마이그레이션에 사용되는 Realtime Database를 줄입니다. 데이터입니다. 앱에 여전히 연결된 앱 버전을 고려합니다. 해당 데이터에 대한 Realtime Database 및 이 데이터를 계속 지원할 계획

결제 비용을 반영해야 합니다. Realtime Database 모두에 대해 및 Cloud Firestore입니다.

데이터 매핑

Realtime Database의 데이터는 단일 트리로 구조화되는 반면 Cloud Firestore는 문서, 컬렉션 및 API를 통해 보다 명시적인 데이터 계층 구조를 하위 컬렉션을 볼 수 있습니다. 일부 데이터를 Realtime Database에서 다음으로 이동하는 경우 Cloud Firestore입니다. 다른 아키텍처를 사용하는 것이 좋습니다. 제공합니다

고려해야 할 주요 차이점

기존 Realtime Database 트리에서 Cloud Firestore로 데이터를 이동하는 경우 문서 및 컬렉션과 컬렉션 간의 다음 주요 차이점에 Cloud Firestore에서 데이터를 구조화하는 방법에 영향을 미칠 수 있는 데이터베이스는 다음과 같습니다.

얕은 쿼리는 계층적 데이터 구조에 더 많은 유연성을 제공합니다.
복잡한 쿼리는 더 세분화된 기능을 제공하고 중복 데이터의 필요성을 줄여줍니다.
쿼리 커서는 더욱 강력한 페이지화 성능을 제공합니다.
트랜잭션 시 모든 데이터에 대해 공통 루트를 사용할 필요가 없어 더 효율적입니다.
Realtime Database~Cloud Firestore의 결제 비용이 다릅니다. 여러 Cloud Firestore가 Realtime Database보다 비쌀 수 있습니다. 특히 여러 소규모 작업에 의존하는 경우 더 그렇습니다 데이터베이스 작업 횟수를 줄이고 불필요한 쓰기를 피하세요. Kubernetes와 Realtime Database 간 결제 및 Cloud Firestore.

실행 권장사항

다음 예에는 데이터베이스 간에 데이터를 이동할 때 고려할 수 있는 몇 가지 사항이 나와 있습니다. 얕은 읽기를 활용하고 더 자연스러운 데이터 구조를 위한 쿼리 기능을 Realtime Database를 사용합니다.

사용자가 전 세계 도시의 주목할 만한 명소를 쉽게 찾을 수 있도록 도와주는 도시 가이드 앱을 예로 들어 보겠습니다. Realtime Database에는 얕은 읽기가 없으므로 2개의 최상위 노드에 데이터를 다음과 같이 구조화할 수 있습니다.

// /cities/$CITY_KEY
{
  name: "New York",
  population: 8000000,
  capital: False
}

// /city-landmark/$CITY_KEY/$LANDMARK_KEY
{
  name: "Empire State Building",
  category: "Architecture"
}

Cloud Firestore는 얕은 읽기를 수행하므로 컬렉션의 문서를 쿼리해도 하위 컬렉션의 데이터를 가져오지 않습니다. 따라서 하위 컬렉션에 랜드마크 정보를 저장할 수 있습니다.

// /cities/$CITY_ID
{
  name: "New York",
  population: 8000000,
  capital: False,
  landmarks: [... subcollection ...]
}

문서의 최대 크기는 1MB이기 때문에 중첩된 목록으로 문서의 크기를 늘리기 보다는 각 도시 문서의 용량을 작게 유지하면서 하위 컬렉션으로 랜드마크를 저장해야 합니다.

Cloud Firestore의 고급 쿼리 기능은 공통 액세스 패턴을 위한 중복 데이터 모든 수도를 인구 통계 순으로 나열하여 보여주는 도시 가이드 앱의 화면을 예로 들어보겠습니다. Realtime Database에서 이를 실행하는 가장 효율적인 방법은 별도의 다음과 같이 cities 목록의 데이터를 복제하는 수도 목록입니다.

{
   cities: {
    // ...
   },

   capital-cities: {
     // ...
   }
}

Cloud Firestore로는 수도 목록을 순서대로 표현할 수 있습니다. 모집단을 단일 쿼리로 집계할 수 있습니다.

db.collection('cities')
    .where('capital', '==', true)
    .orderBy('population')

Cloud Firestore 데이터 모델에 관해 자세히 알아보고 Google의 솔루션을 참조하여 Cloud Firestore 데이터베이스

데이터 보안

다음 용도로 Cloud Firestore Security Rules를 사용하는지 여부 Android, Apple, 웹 클라이언트 또는 Identity Access Management (IAM) 서버의 데이터는 Cloud Firestore에서도 보호해야 합니다. Realtime Database 형식으로 입력하세요. 사용자 인증은 두 데이터베이스 모두의 인증을 통해 처리됩니다. 따라서 처음 시작할 때 인증 구현을 변경할 필요가 없습니다. Cloud Firestore 사용.

고려해야 할 주요 차이점

모바일 및 웹 SDK는 Cloud Firestore Security Rules를 사용하는 반면, 서버 SDK는 IAM (Identity Access Management)을 사용하여 데이터를 보호합니다.
Cloud Firestore Security Rules는 와일드 카드를 사용하지 않는 한 하위로 전파되지 않습니다. 문서와 컬렉션은 규칙을 상속받지 않습니다.
더 이상 데이터를 별도로 검증할 필요가 없음 (Realtime Database에서와 동일)
Cloud Firestore는 쿼리를 실행하기 전에 사용자에게 쿼리에서 반환된 모든 데이터에 대한 적절한 액세스 권한이 있어야 합니다.

이전 데이터를 Cloud Firestore(으)로 이동

데이터 및 보안 구조를 Cloud Firestore의 데이터를 추가할 수 있습니다. Realtime Database에서 앱을 이전한 후 이전 데이터를 쿼리하려는 경우 Cloud Firestore하려면 기존 데이터의 내보내기를 새 Cloud Firestore 데이터베이스 Realtime Database와 Cloud Firestore 앱에서 이 단계를 건너뛸 수 있습니다.

새로운 데이터를 이전 데이터로 덮어쓰지 않으려면 이전 데이터를 먼저 추가해야 할 수 있습니다. 두 데이터베이스 모두에 새 데이터를 동시에 추가하면 새 데이터를 우선순위에 두어 목록에 추가된 새 데이터를 Cloud Functions의 Cloud Firestore입니다.

이전 데이터를 Cloud Firestore로 이전하려면 다음 단계를 따르세요.

Realtime Database에서 데이터 내보내기 또는 최근 백업 사용
1. 다음으로 이동: Realtime Database 섹션 (Firebase 콘솔에서 확인)
2. 데이터 탭에서 데이터베이스의 루트 레벨 노드를 선택하고 메뉴에서 JSON 내보내기를 선택합니다.
Cloud Firestore에 새 데이터베이스를 만듭니다. 데이터를 추가하세요.

일부 데이터를 Cloud Firestore로 이동할 때는 다음 전략을 고려하세요.
- 데이터를 포트하는 맞춤 스크립트를 작성합니다. 모든 광고 단위를 데이터베이스마다 요구사항이 다르므로 Slack 채널의 Cloud Firestore 전문가 또는 Stack Overflow 스크립트를 검토하거나 특정 상황에 대한 조언을 제공할 수 있습니다.
- 서버 SDK (Node.js, Java, Python 또는 Go)를 사용하여 데이터 직접 쓰기 Cloud Firestore님에게 전송됩니다. 서버 SDK 설정에 대한 안내는 다음을 참고하세요. 시작하기
- 대규모 데이터 이전을 신속하게 처리하려면 일괄 쓰기를 사용하고 단일 네트워크 요청으로 최대 500개의 작업을 전송합니다.
- Cloud Firestore 비율 제한을 넘지 않도록 하려면 다음 안내를 따르세요. 작업을 각 컬렉션의 초당 500회 쓰기로 제한합니다.

Cloud Firestore에 새 데이터 추가

데이터베이스를 일치시키려면 두 데이터베이스 모두에 새로운 데이터를 실시간으로 추가해야 합니다. Cloud Functions를 사용하여 Cloud Firestore에 쓰기 트리거 클라이언트가 Realtime Database에 쓸 때마다 Cloud Firestore Cloud Functions에서 수신되는 새 데이터가 쓰기보다 우선 적용됨 수행할 수 있는 몇 가지 작업을 요약해 보겠습니다

새 데이터나 변경 중인 데이터를 Cloud Firestore에 쓰는 함수를 만듭니다. 클라이언트가 Realtime Database에 데이터를 쓸 때마다 기록됩니다. 다음에 대해 자세히 알아보기 Cloud Functions의 Realtime Database 트리거

Cloud Firestore을(를) 마이그레이션된 데이터의 기본 데이터베이스로 설정

일부 서비스의 기본 데이터베이스로 Cloud Firestore을(를) 사용하기로 결정한 경우 이전에 사용한 데이터 미러링 함수를 Cloud Firestore Security Rules를 설정하고 확인합니다.

Cloud Functions를 사용하여 데이터베이스 간 패리티를 유지한 경우 동일한 쓰기 작업을 수행하는 두 개의 데이터베이스에 걸쳐 합니다. 단일 데이터베이스에 쓰도록 함수를 전환하거나 쓰기 기능을 단계적으로 중단하고 여전히 Realtime Database에 연결된 앱의 이전된 데이터 앱에서 이 문제를 처리하는 방법은 구체적인 요구사항과 사용자에 따라 다릅니다.
데이터가 올바르게 보호되는지 확인합니다. Cloud Firestore Security Rules 확인 IAM 설정을 관리할 수 있습니다