Panoramica delle interfacce di query
Questa pagina descrive le diverse interfacce disponibili per accedere ai dati in un database Firestore in modalità Native.
Interfacce di operazioni
La modalità Native supporta due interfacce per l'accesso ai dati:
Operazioni pipeline
L'interfaccia di query più recente per Firestore. Le operazioni della pipeline supportano una sintassi componibile basata sulle fasi. Costruisci un'operazione definendo una serie di fasi sequenziali che vengono eseguite in ordine. Ciò consente operazioni complesse, come il filtraggio in base al risultato di un'aggregazione, che in precedenza non era possibile nell'interfaccia originale (operazioni di base).
Le operazioni della pipeline sono disponibili solo nella versione Firestore Enterprise e si trovano nella fase di lancio anteprima.
Operazioni principali
Le operazioni di base sono l'interfaccia originale per Firestore.
Le operazioni di base utilizzano una sintassi di concatenazione dei metodi (.where(), .orderBy(), .get())
sui riferimenti a documenti o raccolte per recuperare i documenti.
L'ordinamento delle fasi della query è implicito e il supporto dell'aggregazione è limitato.
Le operazioni di base sono disponibili sia nelle versioni Enterprise che Standard, ma i valori predefiniti dell'indice sono molto diversi tra le versioni. Per maggiori dettagli, consulta la sezione successiva.
Differenze dell'interfaccia tra le versioni
Con l'introduzione del supporto della modalità Native nella versione Enterprise, sono disponibili sia le operazioni di base di Firestore che quelle della pipeline. Quando utilizzi le operazioni principali in Enterprise, il nuovo comportamento dell'indice e il modello di prezzo rimuovono molte delle limitazioni di Standard.
| Funzionalità | Versione Standard | Versione Enterprise |
| Operazioni supportate | Limitato alle operazioni di Firestore Core. | Supporta le operazioni principali e di pipeline di Firestore e le operazioni di compatibilità MongoDB di Firestore. |
| Requisito di indicizzazione | Tutte le query richiedono indici. | Gli indici non sono obbligatori per le query. |
| Creazione dell'indice | Gli indici automatici vengono creati per i singoli campi. Puoi creare manualmente indici composti. | Non vengono creati indici automatici. Gli indici devono essere gestiti manualmente. |
| Campi indicizzati | Se non è già presente, viene aggiunto automaticamente un campo __name__ ai campi indicizzati. | __name__ non viene aggiunto automaticamente ai campi indicizzati. Se è importante per la tua applicazione, devi specificare esplicitamente __name__ nei campi indicizzati. |
| Normalizzazione dell'ordine di ordinamento | La clausola ORDER BY della query viene normalizzata aggiungendo i campi di disuguaglianza e il campo __name__ alla fine (se non è già presente). Ciò garantisce un ordinamento univoco e deterministico dei risultati, indipendentemente dagli altri campi presenti nella clausola ORDER BY. | Nessuna normalizzazione dell'ordinamento. Un ordine di ordinamento come sort a ASC garantisce solo che i risultati siano ordinati in base al campo a. Firestore utilizzerà gli indici esistenti per restituire i risultati nell'ordine più efficiente possibile. Pertanto, se a non è univoco nel set di risultati, l'ordine dei risultati può variare da query a query a seconda della configurazione dell'indice, delle strategie di esecuzione e così via. Per garantire un ordinamento univoco e deterministico dei risultati, devi aggiungere un campo univoco come __name__ all'ordine di ordinamento. |
| Rendimento e costo delle query | Le query sono generalmente efficienti grazie ai requisiti di indice. | Ottimizza le prestazioni e i costi delle query creando indici. Puoi identificare gli indici mancanti utilizzando Query Explain e Query Insights.
Le query senza indici potrebbero rischiare di essere inefficienti e costose man mano che il set di dati cresce, richiedendo monitoraggio e ottimizzazione. |
| Costo generale di indicizzazione | Nessun addebito per le scritture di indice, poiché gli indici sono automatici. | La scrittura delle voci di indice consuma unità di scrittura quando viene scritto un documento associato (1 unità di scrittura per 1 KiB di dimensione della voce di indice). Risparmi sui costi di archiviazione perché non crei voci di indice per ogni campo. |
| Modello di fatturazione (letture/scritture/eliminazioni) | Addebito per ogni operazione di lettura, scrittura ed eliminazione di documenti. | Addebito per lettura e scrittura (tranche). Le letture vengono addebitate in unità di lettura (tranche da 4 KiB). Le scritture e le eliminazioni vengono unite in unità di scrittura (tranche da 1 KiB). |
| Prezzi base (per milione)
I prezzi mostrati si riferiscono alla regione us-central1 |
Letture: 0,03$ogni 100.000 documenti (o 0,30 $per milione).
Scrittura: 0,09$ogni 100.000 documenti (o 0,90 $per milione). Eliminazioni: 0,01$ogni 100.000 documenti (o 0,10 $per milione) |
Unità di lettura: 0,05$per 1 milione di unità di lettura.
Unità di scrittura: 0,26$per 1 milione di unità di scrittura. I prezzi sono generalmente inferiori se i documenti sono inferiori a 4 KiB rispetto al costo di lettura standard. |
| Aggiornamenti in tempo reale
I prezzi mostrati si riferiscono alla regione us-central1 |
Gli aggiornamenti in tempo reale sono inclusi e vengono fatturati come letture a 0,03 $ogni 100.000 documenti. | Gli aggiornamenti in tempo reale hanno una nuova SKU separata (unità di aggiornamento in tempo reale), addebitata per tranche di 4 KiB. Gli aggiornamenti in tempo reale costano 0,30$per milione di unità di lettura. |