É possível usar o Firebase Realtime Database e o Cloud Firestore no app e aproveitar os benefícios de cada solução de banco de dados para atender às suas necessidades. Por exemplo, você pode aproveitar o suporte do Realtime Database para presença, conforme descrito em Criar presença no Cloud Firestore.
Saiba mais sobre as diferenças entre os bancos de dados.
Mover dados para Cloud Firestore
Se você decidiu migrar alguns dos 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. Ao configurar sua nova estrutura de dados no Cloud Firestore, é possível mapear e mover dados existentes do Realtime Database para a 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. Usar o Cloud Functions para gravar novos dados no novo Cloud Firestore conforme é adicionado ao Realtime Database.
Tornar Cloud Firestore seu banco de dados principal para os dados migrados. Depois de migrar alguns dos seus dados, use o Cloud Firestore como seu banco de dados principal e reduza o uso do Realtime Database para os dados migrados. Considere 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
Os dados no Realtime Database são estruturados como uma árvore única, enquanto o Cloud Firestore dá suporte a hierarquias de dados mais explícitas por meio de documentos, coleções e subcoleções. Se você transferir alguns dos seus dados do Realtime Database para o Cloud Firestore, considere usar uma arquitetura diferente para seus dados.
Principais diferenças a serem consideradas
Se você mover dados da sua árvore do Realtime Database para documentos e coleções do Cloud Firestore, lembre das principais diferenças entre os bancos 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, principalmente 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 em 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 comuns. 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 do cities, da seguinte maneira:
{
cities: {
// ...
},
capital-cities: {
// ...
}
}
No Cloud Firestore, é possível expressar uma lista de capitais em ordem de população como uma única consulta:
db.collection('cities')
.where('capital', '==', true)
.orderBy('population')
Leia mais sobre o modelo de dados do Cloud Firestore e confira nossas Soluções para mais ideias sobre como estruturar o banco de dados do Cloud Firestore.
Proteger seus dados
Se você usa o Cloud Firestore Security Rules para clientes Android, Apple ou Web ou Identity Access Management (IAM) para servidores, não se esqueça de proteger seus dados no Cloud Firestore e também Realtime Database. 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 o Cloud Firestore Security Rules, enquanto os SDKs do servidor usam o Identity and Access Management (IAM) para proteger os dados.
- As Cloud Firestore Security Rules 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 Cloud Firestore. Se você planeja usar o Realtime Database e oCloud Firestore no app, pule esta 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.
- Acesse a seção do Realtime Database no console do Firebase.
- Na guia Dados, selecione o nó do nível de raiz do banco de dados e selecione Exportar JSON no menu.
Crie um novo banco de dados no Cloud Firestore e adicione seus dados.
Considere as seguintes estratégias ao mover alguns dos 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 nosso 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 não ultrapassar os 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 no Cloud Firestore sempre que um cliente gravar no Realtime Database. Confira se o Cloud Firestore dá precedência a novos dados provenientes do Cloud Functions sobre qualquer gravação na migração de dados históricos.
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 Gatilhos Realtime Database para o Cloud Functions.
Tornar o Cloud Firestore seu 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, considere todas as funções de espelhamento de dados que você configurou e valide as Cloud Firestore Security Rules.
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 a configuração do Cloud Firestore Security Rules ou do IAM.