Questa pagina descrive le diverse interfacce disponibili per accedere ai dati in un database in modalità Native.
Interfacce delle operazioni
La modalità Native supporta due interfacce per l'accesso ai dati:
Operazioni pipeline
La nuova interfaccia di query per Cloud 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 filtro sul risultato di un'aggregazione, che in precedenza non era possibile nell'interfaccia originale (operazioni principali).
Le operazioni pipeline sono disponibili solo nella versione Enterprise di Firestore e si trovano nella fase di lancio dell'anteprima.
Operazioni principali
Le operazioni principali sono l'interfaccia originale per Cloud Firestore.
Le operazioni principali 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 principali sono disponibili sia nella versione Enterprise che in quella Standard, ma i valori predefiniti degli indici sono molto diversi tra le versioni. Per maggiori dettagli, consulta la sezione successiva.
Differenze tra le interfacce delle versioni
Con l'introduzione del supporto della modalità Native nella versione Enterprise, sono disponibili sia le operazioni principali di Firestore che quelle pipeline. Quando utilizzi le operazioni principali nella versione Enterprise, il nuovo comportamento degli indici e il modello di prezzi rimuovono molte delle restrizioni della versione Standard.
| Funzionalità | Versione Standard | Versione Enterprise |
| Operazioni supportate | Limitato alle operazioni principali di Firestore. | Supporta le operazioni principali e pipeline di Firestore e le operazioni di compatibilità con Firestore MongoDB. |
| Requisito di indicizzazione | Tutte le query richiedono indici. | Gli indici non sono obbligatori per le query. |
| Creazione di indici | Vengono creati indici automatici 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. |
| 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. Cloud 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 di overhead dell'indicizzazione | Non sono previsti addebiti per le scritture degli indici, in quanto 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$ogni 100.000 documenti (o 0,30 $per milione).
Scritture: 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 indicati si riferiscono alla regione us-central1 |
Gli aggiornamenti in tempo reale sono inclusi nella fatturazione come letture a 0,03 $ogni 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. |