Panoramica delle interfacce di query
Questa pagina illustra le diverse interfacce disponibili per accedere ai dati in un database Firestore in modalità nativa.
Interfacce delle operazioni
La modalità nativa supporta due interfacce per l'accesso ai dati:
Operazioni pipeline
La nuova interfaccia di query per Firestore. Le operazioni pipeline supportano una sintassi componibile basata su fasi. Per creare un'operazione, devi definire una serie di fasi sequenziali che vengono eseguite in ordine. In questo modo, puoi eseguire operazioni complesse, come il filtraggio sul risultato di un'aggregazione, che in precedenza non era possibile nell'interfaccia originale (operazioni di base).
Le operazioni pipeline sono disponibili solo nella versione Enterprise di Firestore e sono in fase di lancio in anteprima.
Operazioni di base
Le operazioni di base sono l'interfaccia originale per Firestore.
Le operazioni di base utilizzano una sintassi di concatenamento 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 per l'aggregazione è limitato.
Le operazioni di base sono disponibili sia nella versione Enterprise sia in quella Standard, ma i valori predefiniti degli indici sono molto diversi tra le versioni. Consulta la sezione seguente per ulteriori dettagli.
Differenze tra le interfacce delle versioni
Con l'introduzione del supporto della modalità nativa nella versione Enterprise, sono disponibili sia le operazioni di base di Firestore sia le operazioni pipeline. Quando utilizzi le operazioni di base nella versione Enterprise, il nuovo comportamento dell'indice e il modello di prezzi rimuovono molte delle limitazioni della versione Standard.
| Funzionalità | Versione Standard | Versione Enterprise |
| Operazioni supportate | Limitato alle operazioni di base di Firestore. | Supporta le operazioni di base e 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 di indici | Gli indici automatici vengono creati per i singoli campi. Puoi creare manualmente indici compositi. | 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. |
| Sparso degli indici | Tutti gli indici sono sparsi. Una voce di indice esiste solo se tutti i campi definiti nell'indice sono presenti nel documento. | Il valore predefinito è denso, dove una voce di indice esiste anche se nel documento non sono presenti campi definiti nell'indice.
Inoltre, puoi attivare gli indici sparsi, dove una voce di indice esiste se nel documento è presente almeno un campo nell'indice. |
| Normalizzazione dell'ordinamento | La clausola order by della query viene normalizzata aggiungendo i campi di disuguaglianza e il __name__ campo alla fine (se non è già presente). In questo modo, viene garantito un ordinamento univoco e deterministico dei risultati, indipendentemente dagli altri campi presenti nella clausola order by. | Nessuna normalizzazione dell'ordinamento. Un 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'ordinamento. |
| Rendimento e costo delle query | Le query sono generalmente efficienti grazie ai requisiti degli indici. | Ottimizza il rendimento e i costi delle query creando indici. Puoi identificare gli indici mancanti utilizzando Query Explain e Query Insights.
Le query senza indici potrebbero essere inefficienti e costose man mano che il set di dati aumenta, richiedendo monitoraggio e ottimizzazione. |
| Costo generale dell'indicizzazione | Non sono previsti addebiti per le scritture di indici, 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 dimensioni della voce di indice). Risparmi sui costi di archiviazione non creando voci di indice per ogni campo. |
| Modello di fatturazione (letture/scritture/eliminazioni) | Addebito per 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 indicati si riferiscono alla regione us-central1 |
Letture: 0,03$per 100.000 documenti (o 0,30 $per milione).
Scritture: 0,09$per 100.000 documenti (o 0,90 $per milione). Eliminazioni: 0,01$per 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 indicati si riferiscono alla regione us-central1 |
Gli aggiornamenti in tempo reale sono inclusi nella fatturazione come letture a 0,03 $per 100.000 documenti. | Gli aggiornamenti in tempo reale hanno un nuovo SKU separato (unità di aggiornamento in tempo reale), addebitato per tranche da 4 KiB. Gli aggiornamenti in tempo reale costano 0,30$per milione di unità di lettura. |