Entenda o faturamento do banco de dados em tempo real

O Firebase fatura os dados armazenados em seu banco de dados e todo o tráfego de rede de saída na camada de sessão (camada 5) do modelo OSI. O armazenamento é cobrado em US$ 5 por cada GB/mês, avaliado diariamente. O faturamento não é afetado pela localização do seu banco de dados. O tráfego de saída inclui sobrecarga de conexão e criptografia de todas as operações de banco de dados e dados baixados por meio de leituras de banco de dados. Tanto as leituras quanto as gravações do banco de dados podem gerar custos de conexão na sua conta. Todo o tráfego de e para o seu banco de dados, incluindo operações negadas pelas regras de segurança, gera custos faturáveis.

Alguns exemplos comuns de tráfego faturado incluem:

  • Dados baixados: quando os clientes obtêm dados do seu banco de dados, o Firebase cobra pelos dados baixados. Normalmente, isso representa a maior parte dos custos de largura de banda, mas não é o único fator na sua conta.
  • Sobrecarga de protocolo: É necessário algum tráfego adicional entre o servidor e os clientes para estabelecer e manter uma sessão. Dependendo do protocolo subjacente, esse tráfego pode incluir: sobrecarga de protocolo em tempo real do Firebase Realtime Database, sobrecarga de WebSocket e sobrecarga de cabeçalho HTTP. Cada vez que uma conexão é estabelecida, essa sobrecarga, combinada com qualquer sobrecarga de criptografia SSL, contribui para os custos de conexão. Embora não seja muita largura de banda para uma única solicitação, pode ser uma parte substancial de sua conta se suas cargas forem pequenas ou se você fizer conexões curtas e frequentes.
  • Sobrecarga de criptografia SSL: Há um custo associado à sobrecarga de criptografia SSL necessária para conexões seguras. Em média, esse custo é de aproximadamente 3,5 KB para o handshake inicial e de aproximadamente dezenas de bytes para cabeçalhos de registro TLS em cada mensagem de saída. Para a maioria dos aplicativos, essa é uma pequena porcentagem da sua conta. No entanto, isso pode se tornar uma grande porcentagem se o seu caso específico exigir muitos handshakes SSL. Por exemplo, dispositivos que não suportam tickets de sessão TLS podem exigir um grande número de handshakes de conexão SSL.
  • Dados do Firebase console: embora isso geralmente não seja uma parte significativa dos custos do Realtime Database, o Firebase cobra pelos dados que você lê e grava no Firebase console.

Estime seu uso faturado

Para ver suas conexões atuais do Realtime Database e o uso de dados, verifique a guia Uso no console do Firebase. Você pode verificar o uso durante o período de faturamento atual, nos últimos 30 dias ou nas últimas 24 horas.

O Firebase mostra estatísticas de uso para as seguintes métricas:

  • Conexões: O número de conexões simultâneas, atualmente abertas e em tempo real com seu banco de dados. Isso inclui as seguintes conexões em tempo real: WebSocket, sondagem longa e eventos enviados pelo servidor HTML. Não inclui solicitações RESTful.
  • Armazenamento: quantos dados são armazenados em seu banco de dados. Isso não inclui hospedagem do Firebase nem dados armazenados por meio de outros produtos do Firebase.
  • Downloads: Todos os bytes baixados do seu banco de dados, incluindo sobrecarga de protocolo e criptografia.
  • Carga: Este gráfico mostra quanto do seu banco de dados está em uso, processando solicitações, em um determinado intervalo de 1 minuto. Você poderá ver problemas de desempenho à medida que seu banco de dados se aproxima de 100%.

Otimizar o uso

Existem algumas práticas recomendadas que você pode empregar para otimizar o uso do banco de dados e os custos de largura de banda.

  • Use os SDKs nativos: sempre que possível, use os SDKs que correspondem à plataforma do seu app, em vez da API REST. Os SDKs mantêm conexões abertas, reduzindo os custos de criptografia SSL que normalmente acompanham a API REST.
  • Verifique se há bugs: se os custos de largura de banda forem inesperadamente altos, verifique se seu aplicativo não está sincronizando mais dados ou com mais frequência do que o planejado originalmente. Para identificar problemas, use a ferramenta de criação de perfil para medir suas operações de leitura e ativar o registro de depuração nos SDKs Android , Objective-C e Web . Verifique os processos em segundo plano e de sincronização em seu aplicativo para garantir que tudo esteja funcionando conforme planejado.
  • Reduza as conexões: Se possível, tente otimizar a largura de banda da sua conexão. Solicitações REST pequenas e frequentes podem ser mais caras do que uma conexão única e contínua usando o SDK nativo. Se você usar a API REST, considere usar um keep-alive HTTP ou eventos enviados pelo servidor , que podem reduzir os custos de handshakes SSL.
  • Use tíquetes de sessão TLS: Reduza os custos indiretos de criptografia SSL em conexões retomadas emitindo tíquetes de sessão TLS . Isto é particularmente útil se você precisar de conexões seguras e frequentes com o banco de dados.
  • Consultas de indexação: a indexação de seus dados reduz a largura de banda total usada para consultas, o que tem o duplo benefício de reduzir seus custos e aumentar o desempenho do seu banco de dados. Use a ferramenta profiler para localizar consultas não indexadas em seu banco de dados.
  • Otimize seus ouvintes: adicione consultas para limitar os dados que suas operações de escuta retornam e use ouvintes que baixam apenas atualizações de dados — por exemplo, on() em vez de once() . Além disso, coloque seus ouvintes o mais longe possível no caminho para limitar a quantidade de dados que eles sincronizam.
  • Reduza os custos de armazenamento: execute trabalhos de limpeza periódicos e reduza quaisquer dados duplicados no seu banco de dados.
  • Regras de uso: evite operações não autorizadas potencialmente caras em seu banco de dados. Por exemplo, usar as regras de segurança do Firebase Realtime Database pode evitar um cenário em que um usuário mal-intencionado baixe repetidamente todo o seu banco de dados. Saiba mais sobre como usar as regras do Firebase Realtime Database .

O melhor plano de otimização para seu aplicativo depende do seu caso de uso específico. Embora esta não seja uma lista exaustiva de práticas recomendadas, você pode encontrar mais conselhos e dicas dos especialistas do Firebase em nosso canal do Slack ou no Stack Overflow .