Como criar aplicativos escalonáveis com o Firestore

Neste documento, você verá quando usar o Firestore para criar aplicativos grandes. Neste documento, apresentamos soluções para administradores de infraestrutura que gerenciam sistemas de banco de dados para aplicativos grandes. O uso do Firestore com outros produtos no Google Cloud simplifica o provisionamento e a manutenção de um banco de dados. Assim, você se concentra no desenvolvimento do seu app em vez do planejamento da capacidade.

Recursos e limitações do Firestore

O Firestore foi projetado para aplicativos de dispositivos móveis e da Web e para armazenar dados transacionais hierárquicos que tenham um esquema flexível e não relacional. Ao avaliar o Firestore como uma possível solução de banco de dados, verifique se as cotas e limites dele são apropriados para seus casos de uso. O Firestore é versátil e aplicável em muitas instâncias, mas outros produtos de banco de dados do Google Cloud podem ser melhores em determinados cenários. Ao decidir se usará o Firestore ou uma solução diferente, considere os fatores a seguir.

Armazenamento

O Firestore pode hospedar qualquer quantidade de armazenamento de dados. Ele processa quantidades de dados que vão de kilobytes a petabytes da mesma maneira, sem afetar o desempenho.

Atualizações em tempo real

O Firestore fornece atualizações em tempo real, permitindo que os clientes detectem um documento e usem consultas para receber atualizações em tempo real. Você envia um callback que cria imediatamente um snapshot do documento com o conteúdo atual de um único documento. Cada vez que o conteúdo do documento é alterado, outra chamada atualiza o snapshot dele.

Permanência de dados off-line

O Firestore fornece permanência de dados off-line com suporte off-line completo para clientes de dispositivos móveis e da Web. É possível acessar e atualizar seus dados enquanto estiver off-line e, em seguida, sincronizar automaticamente as alterações na nuvem quando você estiver on-line novamente. O suporte off-line integrado usa um cache local para exibir e armazenar dados. Portanto, o aplicativo permanece responsivo, independentemente da latência da rede ou da conectividade com a Internet.

Transações

O Firestore é compatível com transações em conformidade com vários documentos e ACID. O termo ACID é a abreviação de atomicidade, consistência, isolamento e durabilidade (em inglês).

Consultas

O Firestore oferece consultas com consistência forte em todo o banco de dados. Além dos índices principais, o Firestore é compatível com índices secundários e compostos para pesquisar rapidamente os locais dos itens solicitados em uma consulta.

As consultas do Firestore são limitadas das seguintes maneiras:

  • O Firestore é um banco de dados não relacional e, portanto, não é compatível com esquemas ou consultas relacionais que usem a semântica SQL. Em particular, o Firestore não aceita operações de mesclagem, filtragem de desigualdade em várias propriedades ou filtragem em dados com base nos resultados de uma subconsulta.
    • Se o aplicativo exigir compatibilidade com SQL para escalas não horizontais, use o Cloud SQL.
    • Se o aplicativo exigir compatibilidade com SQL para escalas horizontais e globais maiores, use o Cloud Spanner.
  • O Datastore é otimizado para processamento de transações on-line (OLTP, na sigla em inglês).

Segurança

O Firestore criptografa todos os dados automaticamente antes de gravá-los em disco. O Firestore oferece gerenciamento e autenticação de acesso robustos por meio dos seguintes métodos, dependendo das bibliotecas de cliente usadas:

Escalonamento automático

O Firestore faz o escalonamento automático, sem inatividade. Esse mecanismo de escalonamento permite que o Firestore atenda a milhares de solicitações por segundo e milhões de conexões simultâneas. Você paga apenas pelo uso real com base no tamanho do armazenamento e no número de operações. Para mais informações, consulte Preços do Firestore.

O escalonamento automático do Firestore é limitado das seguintes maneiras:

  • O modo nativo do Firestore pode escalonar operações de atualização de documentos para no máximo 10.000 gravações por segundo e mais de um milhão de conexões. Se o aplicativo exceder esses limites de taxa de gravação, recomendamos usar o modo Datastore, que escalona até milhões de gravações por segundo. Para saber mais sobre as diferenças entre esses modos, consulte Como escolher entre o modo nativo e o modo Datastore.
  • O Firestore pode gerenciar operações em grande escala. No entanto, para suportar recursos complexos, como replicação e transações, o Firestore faz algumas compensações que podem diminuir o desempenho de aplicativos que devem suportar cargas extremas.
    • Se seu aplicativo gerar gravações extremamente pesadas, considere o uso do Cloud Bigtable para maiores recursos de ingestão de dados em detrimento de transações e índices secundários.
    • Se seu aplicativo exibe com frequência as mesmas informações para os usuários, como uma tabela de classificação de jogadores, considere o armazenamento em cache no lado do cliente para reduzir a carga, evitando solicitações desnecessárias ao servidor.

Latência

O Firestore prioriza a durabilidade e a disponibilidade em relação à latência, fazendo gravações sincronizadas entre zonas ou regiões. Se o aplicativo exigir uma latência consistente abaixo de 10 milissegundos ao ler ou gravar dados, use um banco de dados na memória, como o Memorystore para Redis.

Redundância e disponibilidade

O Firestore oferece os seguintes níveis de redundância de vários locais com base em diferentes mecanismos de replicação:

  • A replicação regional é melhor se a prioridade for conseguir baixa latência de gravação. Quando você usa a replicação regional, os dados são replicados na mesma região. Para garantir a menor latência, convém colocar o aplicativo na mesma região.
  • A replicação multirregional é melhor se a prioridade for garantir a disponibilidade. Quando você usa a replicação multirregional, os dados são replicados em várias zonas em pelo menos duas regiões diferentes. Portanto, o banco de dados é resiliente a interrupções regionais. A replicação multirregional oferece maior disponibilidade e redundância, mas tem maior latência de gravação. Um nó de teste é implantado em uma terceira região para atuar como um desempatador entre as duas regiões replicadas, conforme mostrado na figura 1.

Esquema de replicação de um banco de dados multirregional.

Figura 1. Diagrama de um banco de dados multirregional no Firestore.

Bibliotecas de cliente

Clientes de dispositivos móveis e da Web podem acessar diretamente o Firestore usando as bibliotecas de cliente da Web, do Android ou iOS. O Firestore também se integra perfeitamente à plataforma do Firebase, que oferece recursos como relatórios de erros, autenticação do usuário, entrega de mensagens e análise de eventos do usuário.

Quando usar o Firestore

Os recursos do Firestore são adequados para vários casos de uso, incluindo:

  • Perfis de usuário: gerencie perfis de usuário para personalizar sua experiência com base nas atividades e preferências anteriores dos usuários. É possível usar o esquema flexível do Firestore para desenvolver a estrutura dos perfis de usuário. Por exemplo, adicione novas propriedades para compatibilidade com novos recursos no app. Mudanças de esquema são realizadas sem inatividade, e o desempenho não diminui mesmo com aumentos no número de usuários.
  • Inventários em tempo real: use os objetos ricos e aninhados do Firestore para armazenar grandes quantidades de dados esparsos não homogêneos para diversos produtos sem especializar demais a estrutura. Por exemplo, é possível criar um catálogo de produtos para um varejista.
  • Gerenciamento de sessão do usuário: a compatibilidade do Firestore com transações ACID ajuda a garantir que os usuários possam bloquear um ou mais documentos até que a transação seja concluída. Por exemplo, é possível criar carrinhos de compras para transações de varejo ou um formulário de processamento de várias partes para a realização de reservas.
  • Mutações de estado: use as transações ACID do Firestore para propagar mutações para um grande número de usuários simultâneos. Por exemplo, é possível manter um estado consistente para todos os jogadores em um app de jogos.
  • Cache de gravação permanente: a alta disponibilidade e a durabilidade do Firestore fornecem estado permanente e impede a possível perda de dados causada por uma falha do aplicativo. O Firestore oferece recursos como um armazenamento de chave-valor simples de usar. No entanto, o Firestore não tem um mecanismo de tempo de vida (TTL) ou de expiração do cache integrado.
  • Sincronização de dados entre dispositivos: as atualizações em tempo real do Firestore garantem que todos os dispositivos conectados sempre exibam o estado mais recente. Por exemplo, o Firestore fornece um estado consistente para apps colaborativos para dispositivos móveis de vários usuários e aplicativos em que você se conecta de vários dispositivos.
  • Gerenciamento de IoT e rastreamento de recursos: a permanência de dados off-line do Firestore permite registrar pontos de dados mesmo quando os dispositivos perdem a conectividade de rede. Por exemplo, é possível configurar o rastreamento de GPS em tempo real de dispositivos móveis e veículos.
  • Recursos em tempo real: com as atualizações em tempo real do Firestore, você configura análises e mensagens em tempo real. É possível manter gráficos atualizados, como painéis visuais interativos, e configurar fóruns de discussão ao vivo e salas de bate-papo.
  • Contadores distribuídos: configure contadores distribuídos para exibir interações de documentos, como uma contagem de "curtidas" de uma postagem ou de "favoritos" de um item específico.

Arquiteturas de referência

Esta seção fornece arquiteturas de referência para a criação de apps da Web grandes que combinam o Firestore com outros produtos do Google Cloud, incluindo:

  • Exportações diárias
  • Armazenamento em cache
  • Processamento de dados
  • Como treinar modelos para aprendizado de máquina

Essas arquiteturas não são prescritivas. Em vez disso, elas destacam a amplitude dos possíveis usos do Firestore na criação de apps da Web escalonáveis. É possível reorganizar e adaptar as arquiteturas para criar um app da Web que atenda aos seus requisitos.

Jogos

Uma plataforma de jogos suporta o acesso simultâneo de dezenas de milhares de jogadores. Os serviços de front-end do jogo usam o Firestore para armazenar bilhões de documentos com dados hierárquicos do estado mundial. O Firestore também armazena dados do usuário, como configurações, participação em grupos, guildas, listas de amigos e dados de presença. Esse caso de uso incorpora outros produtos do Google Cloud da seguinte maneira:

  • O Spanner fornece um banco de dados globalmente consistente que pode manter o inventário ou o histórico de partidas para populações grandes de jogadores em qualquer lugar do mundo.
  • Um cache regional na memória é implantado no Memorystore para Redis para acelerar o acesso aos dados usados com frequência.
  • Os eventos são registrados no Bigtable, em que os desenvolvedores ou a equipe de suporte podem acessá-los para resolver problemas.
  • Os dados dos bancos de dados de front e back-end são importados regularmente para o BigQuery para executar pipelines de análise de dados. Esses pipelines ajudam a descobrir explorações ou mecanismos de jogabilidade que precisam ser atualizados antes de afetar a comunidade do jogo e afastar os jogadores.

A figura 2 mostra a arquitetura do caso de uso de jogos:

Arquitetura do caso de uso de jogos.

Figura 2. Exemplo de uma arquitetura de plataforma de jogos.

Internet das Coisas

Um app da Web interativo exibe informações de telemetria em tempo real geradas por dispositivos de Internet das coisas (IoT). Os dispositivos medem e coletam regularmente a temperatura e a frequência cardíaca do usuário e processam os dados da seguinte maneira:

  1. Cada medição é enviada instantaneamente para o IoT Core por meio de pontes MQTT e HTTP.
  2. O IoT Core publica cada medição como uma mensagem individual no Pub/Sub.
  3. A mensagem do Pub/Sub aciona Cloud Functions que extraem informações relevantes das mensagens brutas e salvam os resultados no Firestore para armazenamento de longo prazo.
  4. Uma interface do usuário da Web interativa hospedada no Firebase Hosting e com a tecnologia Angular detecta atualizações diretamente do Firestore. Cada atualização é enviada automaticamente para a interface do usuário da Web para visualizar as informações mais recentes em tempo real.

A figura 3 mostra o pipeline de dados para informações de telemetria neste cenário:

Arquitetura do caso de uso do aplicativo de IoT.

Figura 3. Exemplo de uma arquitetura de aplicativo de IoT.

Varejo

Uma plataforma de varejo fornece recomendações de produtos para novos compradores em mídias diferentes. Um app da Web registra pontos de dados ativos sobre usuários on-line, como responsável pela indicação, região geográfica e tipo de dispositivo, e depois grava os dados coletados no Firestore da seguinte maneira:

  1. Cada nova criação de registro aciona um pipeline de dados em Cloud Functions que copia os dados do usuário para o BigQuery.
  2. Um mecanismo de recomendação, implementado com o Spark MLlib e implantado no Dataproc, é treinado com os dados do usuário ativo armazenados no BigQuery e com os metadados do produto armazenados no Cloud SQL.
  3. O mecanismo de recomendação fornece as seguintes previsões para produtos recomendados:
    • Previsões em tempo real que são gravadas no Firestore e enviadas automaticamente para os dispositivos de usuário on-line.
    • Previsões em lote que são enviadas para usuários off-line por um serviço de e-mail.

A figura 4 mostra o fluxo de dados do cenário da plataforma de varejo:

Arquitetura do caso de uso da plataforma de varejo.

Figura 4. Exemplo de arquitetura de plataforma de varejo.

Captura em tempo real das alterações de dados

Um app recebe entradas do usuário em tempo real que alteram o estado global. Um painel no Data Studio rastreia eventos em tempo real para entender melhor o comportamento e as interações do usuário. Quando uma ação do usuário atualiza qualquer valor de estado, os seguintes eventos ocorrem:

  1. O Firestore aciona uma Função do Cloud que grava a alteração no BigQuery, incluindo os valores de estado antigo e novo.
  2. O painel do Data Studio executa consultas de agregação em tempo real sobre os dados de eventos no BigQuery.
  3. As consultas geram métricas como a proporção de alterações de eventos agregadas para diferentes buckets, tipo exclusivo de eventos por bucket de tempo e latência de ingestão de eventos.

Para uma apresentação detalhada e uma demonstração dessa arquitetura, assista ao vídeo do Cloud Next '19 Como criar aplicativos incríveis com o Firestore.

A figura 5 mostra a arquitetura para capturar a alteração de dados em tempo real:

Arquitetura do caso de uso de captura de dados.

Figura 5. Exemplo de uma arquitetura de captura de dados simples.

Edição colaborativa de conteúdo

Um sistema de gerenciamento de conteúdo (CMS, na sigla em inglês) colaborativo permite que vários editores trabalhem ao mesmo tempo no mesmo artigo. Toda vez que um editor faz uma alteração, por exemplo, para adicionar ou excluir um caractere, o cliente do editor envia a alteração diretamente para o Firestore.

Se vários editores enviarem alterações ao mesmo tempo, ocorrerá o seguinte processo de resolução:

  1. As transações do Firestore garantem que apenas a primeira alteração recebida seja gravada no banco de dados. Outras alterações são rejeitadas.
  2. O Firestore envia automaticamente o conteúdo atualizado para todos os editores.
  3. Os editores inicialmente rejeitados aplicam novamente as próprias alterações com base no conteúdo atualizado e depois reenviam as alterações para o Firestore.
  4. O mesmo processo de resolução de conflitos se repete até que todas as alterações de todos os clientes sejam aceitas e gravadas no banco de dados.

Um pipeline de preparo permite que os editores visualizem o conteúdo da seguinte maneira:

  1. Um cron job hospedado no Cloud Scheduler aciona uma Função do Cloud a cada segundo.
  2. A função copia o conteúdo mais recente do Firestore para o banco de dados de preparo hospedado no Cloud SQL.
  3. Os editores visualizam o conteúdo preparado no servidor de preparo hospedado no App Engine.

Quando o conteúdo estiver concluído, um editor clicará no botão "Publicar" no CMS. Essa ação aciona uma Função do Cloud que copia o conteúdo mais recente do Firestore para o banco de dados de produção hospedado no Cloud SQL. Os leitores podem consumir o conteúdo recém-publicado no site de produção. Para ver um exemplo real semelhante dessa arquitetura, consulte o artigo (em inglês) do New York Times: We Built Collaborative Editing for Our Newsroom's CMS.

A figura 6 mostra o pipeline para editar, preparar e publicar conteúdo no caso de uso de edição colaborativa de conteúdo:

Arquitetura do caso de uso de edição de conteúdo.

Figura 6. Exemplo de uma arquitetura de plataforma de edição colaborativa de conteúdo.

Próximas etapas