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 tra operazioni di lettura e scrittura con il livello di archiviazione e i vincoli sottostanti che potrebbero influire sulle prestazioni.

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 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 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. GFE accetta le richieste in arrivo e le inoltra al servizio Google pertinente (servizio Firestore in questo contesto). 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 Firestore è responsabile dell'archiviazione sia dei dati che dei metadati, nonché 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. 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 dei tasti

Firestore è un database NoSQL orientato ai documenti. I dati vengono archiviati 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 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 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 mantenerle disponibili anche quando una zona diventa inaccessibile. Una replica coerente nelle diverse copie della suddivisione è gestita dall'algoritmo Paxos per ottenere il consenso. Una replica di ogni suddivisione viene eletta come leader Paxos, responsabile della gestione delle scritture nella suddivisione. La replica sincrona ti offre la possibilità di leggere sempre la versione più recente dei dati da 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à 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 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. 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 su un singolo documento richiede l'aggiornamento sia del documento sia delle voci di indice associate a livello atomico 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 generali in una transazione di scrittura

Quando il client Firestore emette una scrittura o esegue il commit di una transazione, utilizzando uno dei metodi descritti in precedenza, internamente questa operazione 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 di indicizzazione archivia 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.

Comprendere una transazione di scrittura nel livello di archiviazione

Come già detto, una scrittura in Firestore implica 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 divisione ha un leader Paxos, che potrebbe trovarsi in una zona diversa a seconda dei tempi intermedi.

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 accade durante la scrittura:

1. Creare 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 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 decrescente e 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. È presente una transazione distribuita che include 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 suddivisioni 3 e 6 sono i partecipanti di questa transazione. Uno dei partecipanti viene scelto come coordinatore, ad esempio Dividi 3. Il compito del coordinatore è assicurarsi che la transazione venga eseguita o venga 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 raggiunto 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 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 è stato eseguito il commit della transazione. 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, c'è un solo partecipante alla transazione e il commit in due fasi menzionato in precedenza non è richiesto, rendendo così le scritture più veloci.

Scritture in più regioni

In un deployment multiregionale, la distribuzione delle repliche tra regioni aumenta la disponibilità, ma ha 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 di leadership 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 multi-split).

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 Comprendere le 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 fare quanto segue per ridurre il numero di partecipanti:

• La distribuzione dell'indice elevato si verifica quando è necessario scrivere molte voci dell'indice. Il fanout con indice elevato per la scrittura di un documento aumenta il numero di righe di database o di database da modificare, con conseguente aumento del numero di partecipanti. Interrompi esplicitamente l'indicizzazione dei campi non utilizzati per le query.
• Il numero di partecipanti aumenta di pari passo con il 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.

Comprendere il 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 di intervallo sulla tabella Indici
2. Ricerche per punto nella tabella Documenti in base ai risultati 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 hanno blocchi. Funzionano invece scegliendo un timestamp, quindi eseguendo tutte le letture in quel timestamp. Poiché non acquisiscono blocchi, non bloccano le transazioni simultanee di lettura e scrittura. 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 lettura e il modo in cui vengono elaborati nel livello di archiviazione in 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 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 partizione 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)
  • La suddivisione 3 potrebbe sapere, grazie al suo stato interno, di avere informazioni sufficienti per eseguire la lettura e la suddivisione lo fa.
  • La suddivisione 3 non è sicura di aver visualizzato 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ò continuare.

Firestore quindi restituisce la risposta al client.

Lettura multi-diviso

Se le letture devono essere eseguite da più suddivisioni, viene utilizzato lo stesso meccanismo per tutte le suddivisioni. Una volta restituiti i dati 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 inattive

Le letture efficaci 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 perché i dati si trovavano in read_time ed è molto probabile che la replica più vicina abbia già verificato di disporre dei dati per il valore read_time specificato. Per ottenere prestazioni notevolmente migliori, 15 secondi è un valore di inattività ragionevole. Anche per le letture inattive, le righe restituite sono coerenti tra loro.

Punto chiave: letture efficaci assicurano che le letture visualizzino i dati più recenti. Tuttavia, può essere dovuto all'overhead di latenza di round trip aggiuntivo dovuto a una replica, che deve comunicare con il leader e potenzialmente dover attendere l'applicazione delle transazioni di scrittura. Per prestazioni migliori, utilizza letture che consentono la restituzione di dati obsoleti.

Evita gli hotspot

Le partizioni 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 si risolve. Quindi, in caso di 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 di cui tenere conto, come illustrato di seguito.

La suddivisione dello spazio di archiviazione e del caricamento 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 consente di scalare il database in modo ottimale per soddisfare il 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 un carico maggiore, Firestore può suddividere un intervallo di chiavi solo fino a quando non pubblica 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 elevate e prolungate su un singolo documento, ti consigliamo di modificare il modello di 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 di spostamento potrebbero essere creati anche nello spazio di indice di un campo di documento che contiene un valore crescente o decrescente in modo sequenziale come 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 l'hotspotting, puoi utilizzare gli ID documento automatici di Firestore che utilizzano un algoritmo di dispersione in modo che siano distribuiti a livello didattico.

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 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