Usar o Cloud Firestore com o Firebase Realtime Database

Você pode usar o tanto o Firebase Realtime Database quanto o Cloud Firestore no seu app e aproveitar os benefícios de cada solução de banco de dados para atender às suas necessidades. Por exemplo, talvez você queira aproveitar a compatibilidade do Realtime Database com presença, conforme descrito em Criar presença no Cloud Firestore.

Saiba mais sobre as diferenças entre os bancos de dados.

Como mover dados para o Cloud Firestore

Se você decidiu migrar alguns de seus dados do Realtime Database para o Cloud Firestore, considere o fluxo a seguir. Como cada banco de dados tem necessidades e considerações estruturais únicas, não há um caminho de migração automatizado. Em vez disso, você pode seguir esta progressão geral:

Mapear a estrutura de dados e as regras de segurança do Realtime Database para o Cloud Firestore. O Realtime Database e o Cloud Firestore dependem do Firebase Authentication para que você não precise alterar a autenticação do usuário no seu app. Ainda assim, as regras de segurança e o modelo de dados são diferentes, e é importante considerar cuidadosamente essas diferenças antes de começar a mover dados para o Cloud Firestore.
Mover dados históricos. Conforme você configura sua nova estrutura de dados no Cloud Firestore, é possível mapear e mover dados existentes do Realtime Database para sua nova instância do Cloud Firestore. No entanto, se você estiver usando os dois bancos de dados em seu aplicativo, não precisa mover dados históricos do Realtime Database.
Espelhar novos dados para o Firestore em tempo real. Use o Cloud Functions para gravar novos dados no seu novo banco de dados do Cloud Firestore conforme ele é adicionado ao Realtime Database.
Fazer do Cloud Firestore seu banco de dados principal para os dados migrados. Depois de migrar alguns dos seus dados, use o Cloud Firestore como banco de dados principal e reduza o uso do Realtime Database para os dados migrados. Leve em consideração as versões do app que ainda estão vinculadas ao Realtime Database para esses dados e como você planeja continuar a compatibilidade com elas.

Contabilize os custos de faturamento do Realtime Database e do Cloud Firestore.

Mapear seus dados

No Realtime Database, os dados são estruturados como uma árvore única, enquanto o Cloud Firestore é compatível com hierarquias de dados mais explícitas por meio de documentos, coleções e subcoleções. Se você mover alguns de seus dados do Realtime Database para o Cloud Firestore, pode ser útil considerar uma arquitetura diferente para eles.

Principais diferenças a serem consideradas

Se você mover os dados da sua árvore existente do Realtime Database para os documentos e coleções do Cloud Firestore, lembre das principais diferenças entre os tipos de banco de dados que podem afetar a forma como você estrutura dados no Cloud Firestore:

Consultas superficiais oferecem mais flexibilidade em estruturas hierárquicas de dados.
Consultas complexas oferecem mais granularidade e reduzem a necessidade de dados duplicados.
Cursores de consulta oferecem uma paginação mais robusta.
As transações não exigem mais uma raiz comum para todos os seus dados e são mais eficientes.
Os custos de faturamento diferem entre o Realtime Database e o Cloud Firestore. Em muitos casos, o Cloud Firestore pode ser mais caro que o Realtime Database, especialmente se você realizar muitas operações pequenas. Considere reduzir o número de operações no seu banco de dados e evitar gravações desnecessárias. Saiba mais sobre as diferenças de faturamento entre o Realtime Database e o Cloud Firestore.

Práticas recomendadas em ação

O exemplo a seguir reflete algumas das considerações necessárias ao mover seus dados entre bancos de dados. Aproveite leituras superficiais e recursos de consulta aprimorados para estruturas de dados mais naturais em comparação às que você talvez usava com o Realtime Database.

Pense em um app de guia de cidade que ajude os usuários a encontrar pontos de referência em cidades ao redor do mundo. Como o Realtime Database não tem leituras superficiais, pode ser necessário estruturar os dados em dois nodes de nível superior, da seguinte maneira:

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

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

O Cloud Firestore tem leituras superficiais. Isso significa que a consulta de documentos em uma coleção não extrai dados de subcoleções. Consequentemente, você pode armazenar informações de ponto de referência em uma subcoleção:

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

Os documentos têm um tamanho máximo de 1 MB, outro motivo para armazenar pontos de referência como uma subcoleção, mantendo cada documento de cidade pequeno em vez de lotar documentos com listas aninhadas.

Os recursos avançados de consulta do Cloud Firestore reduzem a necessidade de duplicar dados para padrões de acesso comum. Por exemplo, pense em uma tela no app de guia de cidade que mostre todas as capitais ordenadas pela população. No Realtime Database, a maneira mais eficiente de fazer isso é manter uma lista separada de capitais que duplique os dados da lista cities, da seguinte maneira:

{
   cities: {
    // ...
   },

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

No Cloud Firestore, é possível expressar uma lista de capitais classificadas por população como uma única consulta:

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

Saiba mais sobre o modelo de dados do Cloud Firestore e conheça nossas soluções para ver outras ideias sobre como estruturar o banco de dados do Cloud Firestore.

Proteger seus dados

Verifique se os dados no Cloud Firestore e no Realtime Database estão protegidos se você usa regras de segurança do Cloud Firestore para clientes Android, Apple ou Web ou o gerenciamento de identidade e acesso (IAM, na sigla em inglês) para servidores. A autenticação do usuário é processada pelo Authentication para os dois bancos de dados. Portanto, não é preciso alterar sua implementação do Authentication ao começar a usar o Cloud Firestore.

Principais diferenças a serem consideradas

Os SDKs para dispositivos móveis e Web usam as regras de segurança do Cloud Firestore para proteger dados, enquanto os SDKs do servidor usam o Identity Access Management (IAM, na sigla em inglês).
As regras de segurança do Cloud Firestore não são aplicadas em cascata, a menos que você use um caractere curinga. Caso contrário, documentos e coleções não herdam regras.
Não é preciso mais validar dados separadamente (como no Realtime Database).
O Cloud Firestore verifica as regras antes de executar uma consulta para garantir que o usuário tenha o acesso apropriado a todos os dados retornados pela consulta.

Mover dados históricos para o Cloud Firestore

Depois de mapear seus dados e estruturas de segurança para os modelos de dados e segurança do Cloud Firestore, é possível começar a adicionar seus dados. Se você planeja consultar dados históricos depois de mover seu app do Realtime Database para o Cloud Firestore, adicione uma exportação dos dados antigos ao novo banco de dados do Cloud Firestore. Se você planeja usar o Realtime Database e o Cloud Firestore no seu app, pule essa etapa.

Para evitar a substituição de novos dados por dados antigos, primeiro adicione seus dados históricos. Se você adicionar dados novos nos dois bancos de dados simultaneamente, conforme apresentado na próxima etapa, dê prioridade aos novos dados adicionados ao Cloud Firestore pelo Cloud Functions.

Para migrar dados históricos para o Cloud Firestore, siga estas etapas:

Exporte seus dados do Realtime Database ou use um backup recente.
1. Acesse a seção "Realtime Database" no Console do Firebase.
2. Na guia Dados, selecione o nó do nível de raiz do banco de dados e selecione Exportar JSON no menu.
Crie seu novo banco de dados no Cloud Firestore e adicione seus dados.

Considere as seguintes estratégias à medida que você mover alguns de seus dados para o Cloud Firestore:
- Escreva um script personalizado que porta seus dados para você. Como cada banco de dados tem necessidades específicas, não oferecemos um modelo para esse script. No entanto, os especialistas do Cloud Firestore no canal do Slack ou no Stack Overflow (páginas em inglês) podem analisar seu script ou dar conselhos sobre sua situação específica.
- Use os SDKs do servidor (Node.js, Java, Python ou Go) para gravar dados diretamente no Cloud Firestore. Para instruções sobre como configurar os SDKs do servidor, consulte Introdução.
- Para acelerar grandes migrações de dados, use gravações em lotes e envie até 500 operações em uma única solicitação de rede.
- Para ficar abaixo dos limites de taxa do Cloud Firestore, limite as operações a 500 gravações/segundo para cada coleção.

Adicionar novos dados ao Cloud Firestore

Para manter a paridade entre seus bancos de dados, adicione novos dados a ambos os bancos de dados em tempo real. Use o Cloud Functions para acionar uma gravação para o Cloud Firestore sempre que um cliente gravar no Realtime Database. Garanta que o Cloud Firestore dê prioridade aos novos dados provenientes do Cloud Functions em todas as gravações que você faz da sua migração histórica de dados.

Crie uma função para gravar novos dados ou alterá-los no Cloud Firestore sempre que um cliente gravar dados no Realtime Database. Saiba mais sobre acionamentos do Realtime Database para o Cloud Functions.

Tornar o Cloud Firestore o banco de dados principal para os dados migrados

Se você decidiu usar o Cloud Firestore como seu banco de dados principal para alguns de seus dados, leve em consideração todas as funções de espelhamento de dados que você configurou e valide as regras de segurança do Cloud Firestore.

Se você usou o Cloud Functions para manter a paridade entre seus bancos de dados, verifique se não está duplicando as operações de gravação em ambos os bancos de dados em um loop. Alterne a função para gravar em um único banco de dados ou remova a função completamente e comece a suspender a funcionalidade de gravação para os dados migrados nos apps ainda vinculados ao Realtime Database. A maneira de lidar com isso no seu app depende das necessidades específicas que você e seus usuários têm.
Verifique se os dados estão devidamente protegidos. Valide as regras de segurança do Cloud Firestore ou a configuração do IAM.