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 sull'architettura delle tue applicazioni per garantire 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 tue applicazioni continuino a funzionare bene con l'aumento delle dimensioni e del traffico del database, è utile comprendere la dinamica delle letture e delle scritture nel backend di Firestore. Devi anche comprendere l'interazione delle letture e delle scritture con il livello di archiviazione e le limitazioni 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 all'API Firestore.

SDK e librerie client di Firestore

Firestore supporta SDK e librerie client per piattaforme diverse. Sebbene un'app possa 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 l'accesso offline, le 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 funzionalità importanti, tra cui la protezione contro gli attacchi di tipo Denial of Service.

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 di 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 viene scalato. Comprendere 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 di 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 contigue dal punto di vista lessicografico.

Un tipico database Firestore è troppo grande per essere ospitato su una singola macchina fisica. Esistono anche scenari in cui il carico di lavoro sui dati è troppo elevato per essere gestito da una sola macchina. Per gestire carichi di lavoro di grandi dimensioni, 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 come Firestore gestisce gli intervalli e le suddivisioni delle chiavi è importante per la definizione di modelli di dati scalabili.

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, che è 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 come potrebbero essere le tabelle di 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à a livello di regione è una posizione 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 è costituita da un insieme definito di regioni in cui sono archiviate le repliche del database. In un deployment multiregionale di Firestore, due delle regioni hanno repliche complete dell'intero insieme di dati nel database. Una terza regione ha una replica di testimone che non gestisce un insieme completo di dati, ma partecipa alla replica. Se li replichi in più regioni, i dati possono essere scritti e letti anche in caso di perdita di un'intera regione.

Per saperne di più sulle località di una regione, consulta Località di Firestore.

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

Informazioni sul ciclo di 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 le 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 offre anche la serializzazione, il che significa che tutte le transazioni vengono visualizzate 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.

Sono inclusi 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 richiedono eliminazioni corrispondenti nella tabella Indici.
• I campi che vengono modificati nei documenti richiedono sia le eliminazioni (per i valori precedenti) sia le inserzioni (per i valori nuovi) 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, Firestore le raccoglie all'interno di una transazione e poi le esegue.

Punto chiave: internamente Firestore utilizza 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 mostrato 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 della 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, sono presenti cinque mutazioni:
   • M1: aggiorna la riga relativa a restaurant1 nella tabella Documenti in modo che rifletta la variazione di valore del campo priceCategory.
   • M2 e M3: elimina le righe relative al vecchio valore priceCategory nella tabella Indici per gli indici in ordine decrescente e crescente.
   • M4 e M5: inserisci le righe per il nuovo valore di priceCategory nella tabella Indici per gli indici decrescenti e crescenti.
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 la suddivisione 3 serva M1 e la suddivisione 6 serva 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 esegue un commit. Il commit contiene le mutazioni M1-M5.
2. Le suddivisioni 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 eseguita o interrotta in modo atomico su tutti i partecipanti.
   • Le repliche 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 raggiunto se la maggior parte delle repliche risponde con una risposta ok to commit al leader.
   • Ogni partecipante comunica al coordinatore quando è pronto (prima fase del commit a due fasi). Se un partecipante non riesce a confermare 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. In parallelo, 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 percorrenza più lunghi. Di conseguenza, la latenza di base per le operazioni di Firestore è leggermente superiore rispetto ai deployment in una singola regione.

Configuramo le repliche in modo che il ruolo di leader per le suddivisioni rimanga sempre nella regione principale. La regione principale è quella da cui proviene il traffico in arrivo sul 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 quell'insieme di righe finché la transazione non viene eseguita o interrotta, causando latenze più elevate e/o errori di contesa dei blocchi. 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 nel seguente modo per ridurre il numero di partecipanti:

• La distribuzione dell'indice elevato si verifica quando è necessario scrivere molte voci dell'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 inferiore, 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 illustra le letture autonome e 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 Indici
2. Esegui ricerche in base alla tabella Documenti in base al risultato della scansione precedente

In Firestore potrebbero esserci determinate query che richiedono meno elaborazione (ad esempio, query solo chiavi per la modalità Datastore) o più elaborazione (ad esempio, query IN).

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.

Informazioni su 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 significa che una lettura di Firestore restituisce la versione più recente dei dati che riflette tutte le scritture che sono state committate fino all'inizio della lettura.

Lettura con suddivisione singola

Il client di archiviazione in Firestore cerca le suddivisioni che possiedono le chiavi delle righe da leggere. Supponiamo che debba eseguire una lettura da Split 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 viene inviata a una replica non leader (ad esempio la 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 da applicare per eseguire la lettura. Una volta applicata la transazione, la lettura può procedere.

Firestore restituisce quindi la risposta al proprio client.

Lettura con più suddivisioni

Se le letture devono essere eseguite da più suddivisioni, viene utilizzato lo stesso meccanismo per 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 della 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, comporta una potenziale latenza più elevata a causa della 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 un rendimento notevolmente migliore, 15 secondi sono 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 vengano visualizzati 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 migliorare le prestazioni, utilizza letture che consentano il ritorno di dati non aggiornati.

Evita gli hotspot

Le suddivisioni in Firestore vengono suddivise automaticamente in parti più piccole per distribuire il lavoro di invio del traffico a più server di archiviazione, se necessario o quando lo spazio delle chiavi 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 troppo rapido del traffico può causare una latenza elevata o errori di scadenza superata, comunemente noti come hotspot, durante l'adattamento del servizio. La best practice è 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 consente di scalare il database in modo ottimale per soddisfare il carico di lavoro.

Punto chiave: per una scalabilità ottimale, il traffico deve essere aumentato 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 prolungati di operazioni simultanee su un singolo documento possono portare a un hotspot in quel documento. Se riscontri latenze elevate e prolungate su un singolo documento, ti consigliamo 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 frequenze di lettura o scrittura elevate 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. In questo caso, la creazione di più suddivisioni non è utile, poiché l'aumento del traffico si sposta semplicemente nella suddivisione appena creata. 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 frequenza elevata e di assegnare ID documento in aumento/diminuzione in modo monotonico, in quanto potrebbero crearsi hotspot. Per evitare gli hotspot, puoi utilizzare gli ID documento automatici di Firestore che utilizzano un algoritmo di dispersione in modo che siano distribuiti in ordine alfabetico.

Punto chiave: l'indicizzazione dei campi con valori in aumento/diminuzione monotoni, come i timestamp, può portare a hotspot che influiscono sulla latenza per le applicazioni con tassi di lettura e scrittura elevati. Se non esegui query in base al campo con valori sequenziali, puoi esentare il campo dall'indicizzazione per aggirare questo limite.

Tieni presente che, seguendo le best practice descritte sopra, Firestore può scalare per gestire carichi di lavoro arbitrariamente grandi 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 di più sulle best practice
• Scopri di più sulle query in tempo reale su larga scala