Visão geral das interfaces de consulta

Esta página explica as diferentes interfaces disponíveis para acessar dados em um banco de dados do Firestore no modo nativo.

Interfaces de operação

O modo nativo é compatível com duas interfaces para acessar dados:

Operações de pipeline

A interface de consulta mais recente para o Firestore. As operações de pipeline aceitam uma sintaxe combinável baseada em estágios. Você cria uma operação definindo uma série de estágios sequenciais que são executados em ordem. Isso permite operações complexas, como filtrar o resultado de uma agregação, o que não era possível antes na interface original (operações principais).

As operações de pipeline estão disponíveis apenas na edição Enterprise do Firestore e estão no estágio de lançamento da prévia.

Operações principais

As operações principais são a interface original do Firestore. As operações principais usam uma sintaxe de encadeamento de métodos (.where(), .orderBy(), .get()) em referências de documentos ou coleções para recuperar documentos. A ordem das etapas da consulta é implícita, e o suporte à agregação é limitado.

As operações principais estão disponíveis nas edições Enterprise e Standard, mas os padrões de índice são muito diferentes entre as edições. Veja mais detalhes na próxima seção.

Diferenças na interface entre as edições

Com a introdução do suporte no modo nativo na edição Enterprise, as operações do Firestore Core e do pipeline estão disponíveis. Ao usar as operações principais na edição Enterprise, o novo comportamento de indexação e o modelo de preços removem muitas das restrições da edição Standard.

Recurso Standard edition Enterprise edition
Operações compatíveis Limitado às operações do Firestore Core. Oferece suporte a operações do Firestore Core e de pipeline, além de operações de compatibilidade do Firestore com o MongoDB.
Requisito de indexação Todas as consultas exigem índices. Os índices não são necessários para consultas.
Criação de índice Os índices automáticos são criados para campos únicos. É possível criar índices compostos manualmente. Nenhum índice automático é criado. Os índices precisam ser gerenciados manualmente.
Campos indexados Um campo __name__ adicional é anexado automaticamente aos campos indexados, se ainda não estiver presente. __name__ não é anexado automaticamente aos campos indexados. Você precisa especificar explicitamente __name__ nos campos indexados se isso for importante para seu aplicativo.
Normalização da ordem de classificação A cláusula "ORDER BY" da consulta é normalizada anexando campos de desigualdade e o campo __name__ no final (se ainda não estiver presente). Isso garante uma ordenação única e determinista dos resultados, independentemente de quais outros campos estejam na cláusula "ORDER BY". Sem normalização da ordem de classificação. Uma ordem de classificação como sort a ASC garante apenas que os resultados sejam classificados pelo campo a. O Firestore vai usar seus índices atuais para retornar resultados na ordem mais eficiente possível. Portanto, se a não for exclusivo no conjunto de resultados, a ordem deles poderá variar de consulta para consulta, dependendo da configuração do índice, das estratégias de execução etc. Para garantir uma ordenação exclusiva e determinista dos resultados, adicione um campo exclusivo, como __name__, à ordem de classificação.
Performance e custo da consulta As consultas geralmente têm bom desempenho devido aos requisitos de índice. Otimize a performance e os custos das consultas criando índices. É possível identificar índices ausentes usando o Query Explain e o Query Insights.

Consultas sem índices podem ser ineficientes e caras à medida que o conjunto de dados cresce, exigindo monitoramento e ajuste.
Custo de sobrecarga de indexação Não há cobrança por gravações de índice, já que os índices são automáticos. A gravação de entradas de índice consome unidades de gravação quando um documento associado é gravado (uma unidade de gravação por 1 KiB de tamanho da entrada de índice). Você economiza nos custos de armazenamento ao não criar entradas de índice para todos os campos.
Modelo de faturamento (leituras/gravações/exclusões) Cobrança por leitura, gravação e exclusão de documento. Cobrado por leitura e gravação (parcela). As leituras são cobradas em unidades de leitura (tranches de 4 KiB). As gravações e exclusões são combinadas em unidades de gravação (incrementos de 1 KiB).
Preço base (por milhão)

Os preços mostrados são para a região us-central1.

 		Leituras: US$ 0,03 por 100.000 documentos (ou US$ 0,30 por milhão).

Gravações: US$ 0,09 por 100.000 documentos (ou US$ 0,90 por milhão).

Exclusões: US$ 0,01 por 100.000 documentos (ou US$ 0,10 por milhão)

Unidades de leitura: US$ 0,05 por 1 milhão de unidades de leitura.

Unidades de gravação: US$ 0,26 por 1 milhão de unidades de gravação. Os preços são geralmente menores se os documentos tiverem menos de 4 KiB em comparação com o custo de leitura padrão.
Atualizações em tempo real

Os preços mostrados são para a região us-central1.

 As atualizações em tempo real são incluídas e cobradas como leituras a US$ 0,03 por 100.000 documentos. As atualizações em tempo real têm uma nova SKU separada (unidades de atualização em tempo real), cobrada por parcela de 4 KiB. As atualizações em tempo real custam US$ 0,30 por milhão de unidades de leitura.

A seguir