O Firebase cobra pelos dados que você armazena no seu banco de dados e por todo o tráfego de rede de saída na camada de sessão (camada 5) do modelo OSI. A cobrança do armazenamento é de US$ 5 para 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 a sobrecarga de conexão e criptografia de todas as operações de banco de dados e dos dados transferidos usando as leituras de banco de dados. Tanto as leituras quanto as gravações de banco de dados podem gerar custos de conexão na sua fatura. Todo o tráfego enviado para o seu banco de dados e recebido dele gera custos faturáveis, incluindo operações negadas pelas regras de segurança.
Alguns exemplos comuns de tráfego faturado incluem:
- Dados transferidos: quando os clientes recebem dados do seu banco de dados, o Firebase cobra pelos dados transferidos. Normalmente, isso compõe a maior parte dos seus custos de largura de banda, mas não é o único custo presente na sua fatura.
- Sobrecarga de protocolo: é necessário um tráfego adicional entre o servidor e os clientes para estabelecer e manter uma sessão. Dependendo do protocolo, esse tráfego pode incluir: sobrecarga de protocolos em tempo real do Firebase Realtime Database, sobrecarga do WebSocket e sobrecarga do cabeçalho HTTP. Cada vez que uma conexão é estabelecida, essa sobrecarga, e qualquer sobrecarga de criptografia SSL, contribui para os custos de conexão. Essa largura de banda não é tão grande para uma única solicitação, mas ela pode ser uma parte substancial da sua fatura se os seus payloads forem pequenos ou se as conexões feitas forem frequentes e curtas.
- 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 algumas dezenas de bytes para cabeçalhos de registro de TLS em cada mensagem de saída. Para a maioria dos apps, isso representa uma porcentagem pequena da sua fatura. No entanto, ela poderá aumentar se seu caso específico precisar de muitos handshakes de SSL. Por exemplo, os dispositivos que não são compatíveis com tíquetes de sessão TLS podem precisar de vários handshakes de conexão SSL.
- Dados do console do Firebase: embora essa parcela dos custos do Realtime Database geralmente não seja significativa, o Firebase cobra pelos dados que você lê e grava no console do Firebase.
Estimar seu uso faturado
Para conferir suas conexões atuais do Realtime Database e o uso de dados, verifique a guia Uso no console do Firebase. É possível verificar o uso relativo ao período de faturamento atual, aos últimos 30 dias ou às últimas 24 horas.
O Firebase mostra estatísticas de uso para as seguintes métricas:
- Conexões: o número de conexões abertas, simultâneas e em tempo real com seu banco de dados. Isso inclui as seguintes conexões em tempo real: WebSocket, long polling e eventos enviados pelo servidor HTML. Não inclui solicitações RESTful.
- Armazenamento: a quantidade de dados armazenada no seu banco de dados. Isso não inclui Firebase Hosting ou dados armazenados usando outros produtos do Firebase.
- Downloads: todos os bytes transferidos a partir do seu banco de dados, incluindo a sobrecarga do protocolo e da criptografia.
- Carga: neste gráfico, é possível ver quanto do banco de dados está sendo usado no processamento de solicitações durante um intervalo de 1 minuto. Você pode ter problemas de desempenho à medida que seu banco de dados se aproxima de 100%.
Otimizar o uso
Veja abaixo algumas práticas recomendadas 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 REST API. Os SDKs mantêm conexões abertas, reduzindo os custos de criptografia SSL que normalmente se somam à REST API.
- Verifique se há bugs: se os seus custos de largura de banda forem inesperadamente altos, verifique se o seu app está sincronizando mais dados ou em uma frequência maior do que o planejado inicialmente. Para identificar problemas, use a ferramenta do criador de perfil. Com ela, você avalia as suas operações de leitura e ativa a geração de registros de depuração nos SDKs do Android, do Objective-C e da Web. Verifique os processos em segundo plano e de sincronização no seu app para garantir que tudo esteja funcionando conforme o planejado.
- Reduza as conexões: se possível, tente otimizar sua largura de banda de conexão. Solicitações de REST pequenas e frequentes podem ser mais caras do que uma única conexão contínua que usa o SDK nativo. Se você usa a API REST, considere utilizar um sinal de atividade HTTP para manter uma conexão aberta ou eventos enviados pelo servidor para reduzir os custos de handshakes de SSL.
- Use tíquetes de sessão da TLS: emita tíquetes de sessão da TLS para reduzir os custos com a sobrecarga de criptografia SSL nas conexões retomadas. Isso é muito útil caso você precise de conexões frequentes e seguras ao banco de dados.
- Faça a indexação de consultas: indexar os dados reduz a largura de banda total usada para consultas. Isso proporciona o duplo benefício de reduzir os custos e aumentar o desempenho do banco de dados. Use a ferramenta do criador de perfil para encontrar consultas não indexadas no banco de dados.
- Otimize seus listeners: adicione consultas para limitar os dados retornados pelas operações de detecção e use listeners que fazem o download somente das atualizações de dados. Por exemplo:
on()em vez deonce(). Além disso, coloque os listeners na última parte possível do caminho para limitar a quantidade de dados que eles sincronizam. - Reduza os custos de armazenamento: execute jobs periódicos de limpeza e reduza dados duplicados no seu banco de dados.
- Use regras: elas impedem qualquer operação potencialmente cara e não autorizada no seu banco de dados. Por exemplo, o uso de Firebase Realtime Database Security Rules pode evitar que um usuário mal-intencionado faça downloads repetidos de todo o banco de dados. Saiba mais sobre como usar as regras do Firebase Realtime Database.
O melhor plano de otimização para seu app depende do seu caso de uso específico. Esta não é uma lista completa das práticas recomendadas, mas é possível encontrar mais orientações e dicas dos especialistas em Firebase no nosso canal no Slack ou no Stack Overflow.