Comprendere le letture e le scritture su larga scala

Comprendere le letture e le scritture su larga scala

Leggi questo documento per prendere decisioni consapevoli su come progettare l'architettura delle tue applicazioni per ottenere prestazioni e affidabilità elevate. Questo documento include argomenti avanzati di Firestore. Se hai appena iniziato a utilizzare Firestore, consulta la guida rapida.

Firestore è un database flessibile e scalabile per lo sviluppo di dispositivi mobili, web e server da Firebase e Google Cloud. È molto facile iniziare a utilizzare Firestore e scrivere applicazioni complete e potenti.

Per assicurarti che le applicazioni continuino a funzionare bene con le dimensioni del database e l'aumento del traffico, è utile comprendere i meccanismi delle letture e delle scritture nel backend Firestore. Devi anche comprendere l'interazione delle letture e delle scritture con il livello di archiviazione e i vincoli sottostanti che potrebbero influire sul rendimento.

Consulta le sezioni seguenti per le best practice prima di progettare l'architettura dell'applicazione.

Informazioni sui componenti di alto livello

Il seguente diagramma mostra i componenti di alto livello coinvolti in una richiesta API Firestore.

SDK e librerie client di Firestore

Firestore supporta gli SDK e le librerie client per diverse piattaforme. Mentre un'app può effettuare chiamate HTTP e RPC dirette all'API Firestore, le librerie client forniscono un livello di astrazione per semplificare l'utilizzo dell'API e implementare le best practice. Potrebbero anche fornire funzionalità aggiuntive come accesso offline, cache e così via.

Google Front End (GFE)

Si tratta di un servizio di infrastruttura comune a tutti i servizi Google Cloud. Il GFE accetta le richieste in arrivo e le inoltra al servizio Google pertinente (in questo contesto, il servizio Firestore). Fornisce inoltre altre importanti funzionalità, tra cui la protezione dagli attacchi DoS.

Servizio Firestore

Il servizio Firestore esegue controlli sulla richiesta dell'API, che include autenticazione, autorizzazione, controlli delle quote e regole di sicurezza, nonché gestisce le transazioni. Questo servizio Firestore include un client di archiviazione che interagisce con il livello di archiviazione per le letture e le scritture dei dati.

Livello di archiviazione Firestore

Il livello di archiviazione di Firestore è responsabile dell'archiviazione sia dei dati e dei metadati sia delle funzionalità di database associate fornite da Firestore. Le sezioni seguenti descrivono come vengono organizzati i dati nel livello di archiviazione di Firestore e come il sistema si scala. Scoprire come sono organizzati i dati può aiutarti a progettare un modello dei dati scalabile e a comprendere meglio le best practice in Firestore.

Intervalli e suddivisioni delle chiavi

Firestore è un database NoSQL orientato ai documenti. Archivi i dati in documenti, organizzati in gerarchie di raccolte. La gerarchia della raccolta e l'ID documento vengono tradotti in una singola chiave per ogni documento. I documenti vengono archiviati in modo logico e ordinati in ordine alfabetico in base a questa singola chiave. Utilizziamo il termine intervallo di chiavi per fare riferimento a un intervallo di chiavi lessicograficamente contiguo.

Un tipico database Firestore è troppo grande per essere inserito in un'unica macchina fisica. Esistono anche scenari in cui il carico di lavoro sui dati è troppo elevato per essere gestito da una macchina. Per gestire carichi di lavoro elevati, Firestore suddivide i dati in parti separate che possono essere archiviate e pubblicate da più macchine o server di archiviazione. Queste partizioni vengono create nelle tabelle del database in blocchi di intervalli di chiavi denominati split.

Punto chiave: comprendere in che modo Firestore gestisce gli intervalli e le suddivisioni di chiavi è importante per la modellazione scalabile dei dati.

Replica sincrona

È importante notare che il database viene sempre replicato automaticamente e in modo sincrono. Le suddivisioni dei dati hanno repliche in zone diverse per mantenerli disponibili anche quando una zona diventa inaccessibile. La replica coerente alle diverse copie della suddivisione è gestita dall'algoritmo Paxos per il consenso. Una replica di ogni suddivisione viene eletta come leader Paxos, responsabile della gestione delle scritture nella suddivisione. La replica sincrona ti consente di leggere sempre la versione più recente dei dati di Firestore.

Il risultato complessivo è un sistema scalabile e altamente disponibile che offre latenze ridotte sia per le letture che per le scritture, indipendentemente dai carichi di lavoro elevati e su larga scala.

Punto chiave: comprendere come Firestore gestisce la replica è importante per comprendere la coerenza, la disponibilità e l'affidabilità di Firestore.

Layout dei dati

Firestore è un database di documenti senza schema. Tuttavia, internamente organizza i dati principalmente in due tabelle in stile database relazionale nel livello di archiviazione come segue:

• Tabella Documenti: i documenti vengono archiviati in questa tabella.
• Tabella Indici: in questa tabella vengono memorizzate le voci dell'indice che consentono di ottenere risultati in modo efficiente e ordinati in base al valore dell'indice.

Il seguente diagramma mostra l'aspetto delle tabelle per un database Firestore con le suddivisioni. Le suddivisioni vengono replicate in tre zone diverse e a ogni suddivisione è assegnato un leader Paxos.

Regione singola o multiregione

Quando crei un database, devi selezionare una regione o più regioni.

Una singola località regionale rappresenta una località geografica specifica, ad esempio us-west1. Le suddivisioni dei dati di un database Firestore hanno repliche in zone diverse all'interno della regione selezionata, come spiegato in precedenza.

Una località multiregionale è composta da un insieme definito di regioni in cui sono archiviate le repliche del database. In un deployment multiregionale di Firestore, due regioni hanno replica complete di tutti i dati nel database. Una terza regione include una replica di test che non gestisce un set completo di dati, ma partecipa alla replica. Replicando i dati tra più regioni, i dati sono disponibili per essere scritti e letti anche in caso di perdita di un'intera regione.

Per ulteriori informazioni sulle posizioni di una regione, consulta Sedi di Firestore.

Punto chiave: la scelta tra configurazioni monoregione e multiregione comporta compromessi importanti in termini di prestazioni, disponibilità e costi.

Comprendere la vita di una scrittura in Firestore

Un client Firestore può scrivere dati creando, aggiornando o eliminando un singolo documento. Una scrittura in un singolo documento richiede l'aggiornamento atomico sia del documento sia delle relative voci dell'indice nel livello di archiviazione. Firestore supporta anche operazioni atomiche costituite da più letture e/o scritture in uno o più documenti.

Per tutti i tipi di scritture, Firestore fornisce le proprietà ACID (atomicità, coerenza, isolamento e durabilità) dei database relazionali. Firestore fornisce inoltre la serializzabilità, il che significa che tutte le transazioni appaiono come se fossero eseguite in un ordine seriale.

Passaggi di alto livello in una transazione di scrittura

Quando il client Firestore esegue una scrittura o esegue il commit di una transazione utilizzando uno dei metodi menzionati in precedenza, internamente viene eseguita come transazione di lettura/scrittura del database nel livello di archiviazione. La transazione consente a Firestore di fornire le proprietà ACID menzionate in precedenza.

Come primo passaggio di una transazione, Firestore legge il documento esistente e determina le mutazioni da apportare ai dati nella tabella Documenti.

Ciò include anche gli aggiornamenti necessari alla tabella Indici come segue:

• I campi che vengono aggiunti ai documenti richiedono inserimenti corrispondenti nella tabella Indici.
• I campi rimossi dai documenti devono essere eliminati nella tabella Indici.
• I campi in fase di modifica nei documenti devono essere eliminati (per i valori precedenti) e inseriti (per i nuovi valori) nella tabella Indici.

Per calcolare le mutazioni menzionate in precedenza, Firestore legge la configurazione di indicizzazione del progetto. La configurazione dell'indicizzazione memorizza le informazioni sugli indici di un progetto. Firestore utilizza due tipi di indici: a campo singolo e composti. Per una comprensione dettagliata degli indici creati in Firestore, consulta Tipi di indici in Firestore.

Una volta calcolate le mutazioni, Firestore le raccoglie in una transazione e poi esegue il commit.

Punto chiave: Firestore utilizza internamente sempre le transazioni per fornire proprietà ACID per le scritture.

Informazioni su una transazione di scrittura nel livello di archiviazione

Come discusso in precedenza, una scrittura in Firestore comporta una transazione di lettura-scrittura nel livello di archiviazione. A seconda del layout dei dati, una scrittura potrebbe comportare una o più suddivisioni come illustrato nel layout dei dati.

Nel seguente diagramma, il database Firestore ha otto suddivisioni (contrassegnate da 1 a 8) ospitate su tre diversi server di archiviazione in un'unica zona e ogni suddivisione viene replicata in 3 (o più) zone diverse. Ogni suddivisione ha un leader Paxos, che potrebbe trovarsi in una zona diversa per suddivisioni diverse.

Considera un database Firestore con la raccolta Restaurants come segue:

Il client Firestore richiede la seguente modifica a un documento nella raccolta Restaurant aggiornando il valore del campo priceCategory.

I seguenti passaggi generali descrivono cosa succede durante la scrittura:

1. Crea una transazione di lettura/scrittura.
2. Leggi il documento restaurant1 nella raccolta Restaurants dalla tabella Documenti del livello di archiviazione.
3. Leggi gli indici del documento dalla tabella Indici.
4. Calcola le mutazioni da apportare ai dati. In questo caso, ci sono cinque mutazioni:
   • M1: aggiorna la riga per restaurant1 nella tabella Documenti in modo che rifletta la modifica del valore del campo priceCategory.
   • M2 e M3: elimina le righe per il valore precedente di priceCategory nella tabella Indici per gli indici in ordine decrescente e in ordine crescente.
   • M4 e M5: inserisci le righe per il nuovo valore di priceCategory nella tabella Indici per gli indici in ordine decrescente e in ordine crescente.
5. Esegui il commit di queste mutazioni.

Il client di archiviazione nel servizio Firestore cerca le suddivisioni proprietarie delle chiavi delle righe da modificare. Supponiamo che il segmento 3 serva M1 e il segmento 6 M2-M5. Esiste una transazione distribuita che coinvolge tutte queste suddivisioni come partecipanti. Le suddivisioni dei partecipanti possono includere anche qualsiasi altra suddivisione da cui i dati sono stati letti in precedenza nell'ambito della transazione di lettura/scrittura.

I passaggi seguenti descrivono cosa succede durante il commit:

1. Il client di archiviazione emette un commit. Il commit contiene le mutazioni M1-M5.
2. Le frazioni 3 e 6 sono i partecipanti a questa transazione. Uno dei partecipanti viene scelto come coordinatore, ad esempio il gruppo 3. Il compito del coordinatore è assicurarsi che la transazione venga confermata o interrotta a livello atomico tra tutti i partecipanti.
   • Le repliche dei leader di queste suddivisioni sono responsabili del lavoro svolto dai partecipanti e dai coordinatori.
3. Ogni partecipante e coordinatore esegue un algoritmo Paxos con le rispettive repliche.
   • Il leader esegue un algoritmo Paxos con le repliche. Il quorum viene ottenuto se la maggior parte delle repliche risponde con una risposta ok to commit al leader.
   • Ogni partecipante avvisa il coordinatore quando è preparato (prima fase dell'impegno in due fasi). Se un partecipante non può impegnare la transazione, l'intera transazione aborts.
4. Una volta che il coordinatore sa che tutti i partecipanti, incluso lui stesso, sono pronti, comunica l'esito della transazione accept a tutti i partecipanti (seconda fase del commit a due fasi). In questa fase, ogni partecipante registra la decisione di commit nello spazio di archiviazione stabile e la transazione viene eseguita.
5. Il coordinatore risponde al client di archiviazione in Firestore che la transazione è stata eseguita. Parallelamente, il coordinatore e tutti i partecipanti applicano le mutazioni ai dati.

Quando il database Firestore è di piccole dimensioni, può accadere che una singola suddivisione possieda tutte le chiavi nelle mutazioni M1-M5. In questo caso, la transazione ha un solo partecipante e l'commit a due fasi menzionato in precedenza non è necessario, il che rende le scritture più veloci.

Scritture in più regioni

In un deployment multi-regione, la distribuzione delle repliche nelle regioni aumenta la disponibilità, ma comporta un costo in termini di prestazioni. La comunicazione tra le repliche in regioni diverse richiede tempi di round trip più lunghi. Di conseguenza, la latenza di base per le operazioni di Firestore è leggermente superiore rispetto ai deployment in una singola regione.

Configuriamo le repliche in modo che la leadership per le suddivisioni rimanga sempre nella regione principale. La regione principale è quella da cui il traffico arriva al server Firestore. Questa decisione del leader riduce il ritardo di andata e ritorno nella comunicazione tra il client di archiviazione in Firestore e il leader della replica (o il coordinatore per le transazioni con più suddivisioni).

Ogni scrittura in Firestore comporta anche un'interazione con il motore in tempo reale di Firestore. Per saperne di più sulle query in tempo reale, consulta Informazioni sulle query in tempo reale su larga scala.

Punto chiave: Firestore utilizza le transazioni per eseguire le scritture, il che richiede l'acquisizione di blocchi condivisi per la lettura e blocchi esclusivi per la scrittura. Quando una transazione legge molte righe, nessun'altra transazione può scrivere in questo insieme di righe finché la transazione non viene eseguita o interrotta, causando latenze più elevate e/o bloccare errori di conflitto. Pertanto, cerca di evitare letture di grandi dimensioni all'interno di una transazione.

Punto chiave: la latenza di scrittura/transazione aumenta con l'aumento del numero di suddivisioni/partecipanti. Non esiste un meccanismo esplicito per controllare il numero di partecipanti. Tuttavia, puoi procedere come segue per ridurre il numero di partecipanti:

• Il fanout con indice elevato si verifica quando è necessario scrivere molte voci di indice. Un fanout dell'indice elevato per la scrittura di un documento aumenta il numero o le righe del database da modificare, il che aumenta il numero di partecipanti. Interrompi esplicitamente l'indicizzazione dei campi non utilizzati per le query.
• Il numero di partecipanti aumenta con l'aumento del numero di documenti aggiornati in una transazione di scrittura. Per una latenza minore, mantieni basso il numero di documenti aggiornati in una singola transazione di scrittura.

Informazioni sul ciclo di vita di una lettura in Firestore

Questa sezione approfondisce le letture autonome non in tempo reale in Firestore. Internamente, il server Firestore gestisce la maggior parte di queste query in due fasi principali:

1. Una singola scansione dell'intervallo nella tabella Indexes
2. Esegui ricerche in base alla tabella Documenti in base al risultato della scansione precedente

Potrebbero esserci alcune query che richiedono meno elaborazione (ad esempio, query solo chiavi per la modalità Datastore) o ulteriore elaborazione (ad esempio, query IN) in Firestore.

Le letture dei dati dal livello di archiviazione vengono eseguite internamente utilizzando una transazione di database per garantire letture coerenti. Tuttavia, a differenza delle transazioni utilizzate per le scritture, queste transazioni non richiedono blocchi. Funzionano invece scegliendo un timestamp, quindi eseguendo tutte le letture in quel timestamp. Poiché non acquisiscono blocchi, non bloccano le transazioni di lettura/scrittura simultanee. Per eseguire questa transazione, il client di archiviazione in Firestore specifica un limite di timestamp, che indica al livello di archiviazione come scegliere un timestamp di lettura. Il tipo di limite di timestamp scelto dal client di archiviazione in Firestore è determinato dalle opzioni di lettura per la richiesta di lettura.

Comprendere una transazione di lettura nel livello di archiviazione

Questa sezione descrive i tipi di letture e come vengono elaborate nel livello di archiviazione di Firestore.

Letture efficaci

Per impostazione predefinita, le letture di Firestore sono a elevata coerenza. Questa elevata coerenza indica che una lettura di Firestore restituisce l'ultima versione dei dati che riflette tutte le scritture il cui commit fino all'inizio della lettura è stato eseguito.

Lettura con suddivisione singola

Il client di archiviazione in Firestore cerca le suddivisioni proprietarie delle chiavi delle righe da leggere. Supponiamo che debba eseguire una lettura dalla suddivisione 3 della sezione precedente. Il client invia la richiesta di lettura alla replica più vicina per ridurre la latenza di andata e ritorno.

A questo punto, a seconda della replica scelta potrebbero verificarsi i seguenti casi:

• La richiesta di lettura viene inviata a una replica leader (zona A).
  • Poiché il leader è sempre aggiornato, la lettura può procedere direttamente.
• La richiesta di lettura va a una replica non leader (ad esempio, Zona B)
  • Il partizionamento 3 potrebbe sapere dal proprio stato interno di avere informazioni sufficienti per eseguire la lettura e lo fa.
  • Il segmento 3 non è sicuro di aver visto i dati più recenti. Invia un messaggio al leader per chiedere il timestamp dell'ultima transazione che deve applicare per poter pubblicare la lettura. Una volta applicata la transazione, la lettura può procedere.

Firestore quindi restituisce la risposta al client.

Lettura con più suddivisioni

Nel caso in cui le letture debbano essere eseguite da più suddivisioni, lo stesso meccanismo si verifica in tutte le suddivisioni. Una volta che i dati sono stati restituiti da tutte le suddivisioni, il client di archiviazione in Firestore combina i risultati. Firestore risponde quindi al proprio client con questi dati.

Punto chiave: l'overhead di latenza aumenta con l'aumento del numero di suddivisioni coinvolte in una lettura. Se possibile, mantieni piccoli gli insiemi di risultati delle query.

Letture non aggiornate

Le letture sicure sono la modalità predefinita in Firestore. Tuttavia, ciò ha un costo di una latenza potenzialmente maggiore dovuta alla comunicazione che potrebbe essere richiesta con il leader. Spesso l'applicazione Firestore non ha bisogno di leggere la versione più recente dei dati e la funzionalità funziona bene con dati che potrebbero essere obsoleti di alcuni secondi.

In questo caso, il client può scegliere di ricevere letture non aggiornate utilizzando le opzioni di lettura read_time. In questo caso, le letture vengono eseguite come se i dati fossero in read_time e la replica più vicina ha molte probabilità di aver già verificato di avere dati in read_time specificato. Per ottenere prestazioni notevolmente migliori, 15 secondi è un valore di inattività ragionevole. Anche per le letture non aggiornate, le righe restituite sono coerenti tra loro.

Punto chiave: le letture efficaci assicurano che le letture visualizzino i dati più recenti. Tuttavia, potrebbe comportare un sovraccarico di latenza di andata e ritorno aggiuntivo dovuto al fatto che una replica deve comunicare con il leader e anche potenzialmente dover attendere l'applicazione delle transazioni di scrittura. Per prestazioni migliori, utilizza letture che consentono la restituzione di dati obsoleti.

Evita gli hotspot

Gli spplit in Firestore vengono suddivisi automaticamente in parti più piccole per distribuire il lavoro di gestione del traffico a più server di archiviazione quando necessario o quando lo spazio della chiave si espande. Le suddivisioni create per gestire il traffico in eccesso vengono conservate per circa 24 ore anche se il traffico scompare. Pertanto, se si verificano picchi di traffico ricorrenti, le suddivisioni vengono mantenute e vengono introdotte altre suddivisioni, se necessario. Questi meccanismi aiutano i database Firestore a eseguire la scalabilità automatica in caso di aumento del carico del traffico o delle dimensioni del database. Tuttavia, ci sono alcune limitazioni da tenere presenti, come spiegato di seguito.

La suddivisione dello spazio di archiviazione e del carico richiede tempo e l'aumento del traffico troppo veloce può causare errori di alta latenza o superamento della scadenza, comunemente denominati hotspot, mentre il servizio si adatta. La best practice consiste nel distribuire le operazioni nell'intervallo di chiavi, aumentando al contempo il traffico su una raccolta in un database con 500 operazioni al secondo. Dopo questo aumento graduale, aumenta il traffico fino al 50% ogni cinque minuti. Questo processo è chiamato regola 500/50/5 e posiziona il database in modo che possa scalare in modo ottimale per soddisfare il tuo carico di lavoro.

Punto chiave: per una scalabilità ottimale, il traffico deve essere incrementato seguendo la regola 500/50/5.

Sebbene le suddivisioni vengano create automaticamente con l'aumento del carico, Firestore può suddividere un intervallo di chiavi solo fino a quando non serve un singolo documento utilizzando un insieme dedicato di server di archiviazione replicati. Di conseguenza, volumi elevati e sostenuti di operazioni simultanee su un singolo documento possono causare un hotspot su quel documento. Se riscontri latenze sostenute elevate su un singolo documento, valuta la possibilità di modificare il modello dei dati per suddividere o replicare i dati in più documenti.

Gli errori di contesa si verificano quando più operazioni tentano di leggere e/o scrivere lo stesso documento contemporaneamente.

Punto chiave: evita tassi di lettura o scrittura elevati per un singolo documento o per documenti in un intervallo di chiavi contenente pochi documenti, altrimenti la tua applicazione avrà una latenza elevata e/o errori di contesa.

Un altro caso speciale di hotspot si verifica quando viene utilizzata una chiave in aumento/diminuzione sequenziale come ID documento in Firestore e il numero di operazioni al secondo è molto elevato. La creazione di più suddivisioni non è di aiuto in questo caso, poiché l'aumento del traffico si sposta semplicemente sul segmento appena creato. Poiché Firestore indicizza automaticamente tutti i campi del documento per impostazione predefinita, questi hotspot in movimento possono essere creati anche nello spazio dell'indice per un campo del documento che contiene un valore in aumento/diminuzione sequenziale, ad esempio un timestamp.

Punto chiave: evita di creare documenti a una velocità elevata durante l'assegnazione di ID documento aumentando o diminuendo monotonicamente, in quanto ciò potrebbe creare hotspot. Per evitare l'hotspotting, puoi sfruttare gli ID documento automatici di Firestore che utilizzano un algoritmo di dispersione in modo che siano distribuiti a livello lessicografico.

Punto chiave: l'indicizzazione dei campi con valori che aumentano/diminuiscono monotonicamente, come i timestamp, può portare a hotspot che influiscono sulla latenza per le applicazioni con velocità di lettura e scrittura elevate. Se non esegui query basate sul campo con valori sequenziali, puoi escludere l'indicizzazione del campo per ignorare questo limite.

Tieni presente che seguendo le pratiche descritte in precedenza, Firestore può scalare per gestire carichi di lavoro arbitrariamente di grandi dimensioni senza che tu debba modificare alcuna configurazione.

Risoluzione dei problemi

Firestore fornisce Key Visualizer come strumento di diagnostica progettato per analizzare i pattern di utilizzo e risolvere i problemi di hotspot.

Passaggi successivi

• Scopri altre best practice
• Scopri di più sulle query in tempo reale su larga scala