Creazione di applicazioni scalabili con Firestore

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.
Last reviewed 2020-05-18 UTC

Questo documento descrive quando utilizzare Firestore per creare applicazioni di grandi dimensioni. Questo documento offre soluzioni per gli amministratori di infrastruttura che gestiscono i sistemi di database per applicazioni di grandi dimensioni. L'uso di Firestore insieme ad altri prodotti in Google Cloud semplifica il provisioning e la gestione di un database, in modo che tu possa concentrarti sullo sviluppo dell'app anziché sulla pianificazione della capacità.

Funzionalità e limitazioni di Firestore

Firestore è progettato per applicazioni mobile e web e per l'archiviazione di dati transazionali gerarchici che hanno uno schema flessibile e non relazionale. Quando valuti Firestore come una potenziale soluzione di database, assicurati che le relative quote e i limiti siano appropriati per i tuoi casi d'uso. Firestore è versatile e applicabile in molti casi, ma altri prodotti con database Google Cloud potrebbero essere migliori per alcuni scenari. Nel decidere se utilizzare Firestore o una soluzione diversa, considera i fattori riportati di seguito.

Archiviazione

Firestore può ospitare qualsiasi quantità di spazio di archiviazione dati. Gestisce quantità di dati da kilobyte a petabyte nello stesso modo, senza influire sulle prestazioni.

Aggiornamenti in tempo reale

Firestore fornisce aggiornamenti in tempo reale consentendo ai client di ascoltare un documento e utilizzare le query per ottenere aggiornamenti in tempo reale. Fornisci un callback che crea immediatamente uno snapshot di documenti con i contenuti correnti di un singolo documento. Ogni volta che i contenuti del documento cambiano, un'altra chiamata aggiorna lo snapshot del documento.

Persistenza dati offline

Firestore fornisce la persistenza dei dati offline con il supporto offline completo per i client web e per dispositivi mobili. Puoi accedere ai tuoi dati e aggiornarli mentre sei offline e quindi sincronizzare automaticamente le modifiche sul cloud quando sei di nuovo online. Il supporto offline integrato utilizza una cache locale per pubblicare e archiviare i dati, in modo che l'app rimanga reattiva a prescindere dalla latenza di rete o dalla connettività a Internet.

Transazioni

Firestore supporta transazioni multidocumenti conformi a ACID. Il termine ACID è abbreviato di atomicità, coerenza, isolamento e durabilità.

Query

Firestore offre query a elevata coerenza in tutto il database. Oltre agli indici principali, Firestore supporta gli indici secondari e compositi per cercare rapidamente le posizioni degli elementi che richiedi in una query.

Le query Firestore sono limitate nei seguenti modi:

  • Firestore è un database non relazionale, quindi non supporta schemi relazionali o query che usano la semantica SQL. In particolare, Firestore non supporta le operazioni di join, filtro di uguaglianza su più proprietà o filtro sui dati basato sui risultati di una sottoquery.
    • Se l'app richiede il supporto SQL per le scale non orizzontali, utilizza Cloud SQL.
    • Se l'app richiede il supporto SQL per scale orizzontali e globali più ampie, utilizza Cloud Spanner.
  • Firestore è ottimizzato per l'elaborazione delle transazioni online (OLTP).

Sicurezza

Firestore cripta tutti i dati automaticamente prima di scriverli su disco. Firestore offre gestione e autenticazione efficaci degli accessi tramite i seguenti metodi, a seconda delle librerie client che utilizzi:

Scalabilità automatica

Firestore offre scale up automatici, senza tempi di inattività. Questo meccanismo di scalabilità consente a Firestore di gestire migliaia di richieste al secondo e milioni di connessioni simultanee. Paghi solo il tuo utilizzo effettivo in base alle dimensioni dello spazio di archiviazione e al numero di operazioni. Per ulteriori informazioni, consulta la pagina relativa ai prezzi di Firestore.

La scalabilità automatica di Firestore è limitata nei seguenti modi:

  • La modalità nativa di Firestore può scalare le operazioni di aggiornamento dei documenti fino a un massimo di 10.000 scritture al secondo e oltre un milione di connessioni. Se la tua app supera questi limiti di frequenza di scrittura, ti consigliamo di utilizzare la modalità Datastore, che consente di fare lo scale up fino a milioni di scritture al secondo. Per scoprire di più sulle differenze tra queste modalità, consulta la sezione Scegliere tra la modalità nativa e la modalità Datastore.
  • Firestore è in grado di gestire operazioni su vasta scala. Tuttavia, per supportare funzionalità complesse come la replica e le transazioni, Firestore esegue alcuni compromessi che potrebbero rallentare le prestazioni delle app che dovrebbero supportare carichi estremi.
    • Se la tua app ha una capacità di scrittura estremamente elevata, valuta la possibilità di utilizzare Cloud Bigtable per maggiori funzionalità di importazione dati, a discapito delle transazioni e degli indici secondari.
    • Se la tua app mostra spesso le stesse informazioni agli utenti, ad esempio una classifica dei giocatori nei giochi, prendi in considerazione la memorizzazione nella cache lato client per ridurre il carico evitando richieste non necessarie al server.

Latenza

Firestore dà la priorità a durabilità e disponibilità rispetto alla latenza eseguendo scritture sincrone tra aree geografiche o zone. Se l'app richiede una latenza coerente inferiore a 10 millisecondi durante la lettura o la scrittura di dati, valuta la possibilità di utilizzare un database in memoria come Memorystore for Redis.

Ridondanza e disponibilità

Firestore offre i seguenti livelli di ridondanza multi-location che si basano su diversi meccanismi di replica:

  • La replica regionale è la scelta migliore se la tua priorità è raggiungere una bassa latenza di scrittura. Quando utilizzi la replica a livello di regione, i dati vengono replicati nella stessa area geografica. Per garantire la latenza più bassa possibile, ti consigliamo di posizionare la tua app nella stessa area geografica.
  • La replica in più aree geografiche è la soluzione migliore se la tua priorità è garantire la disponibilità. Quando utilizzi la replica su più aree geografiche, i dati vengono replicati in più zone in almeno due aree geografiche diverse, quindi il database è resiliente alle interruzioni a livello di area geografica. La replica su più aree geografiche offre maggiore disponibilità e ridondanza, ma ha una latenza di scrittura più elevata. Viene eseguito il deployment di un nodo di testimoni in una terza regione che funge da tie-break tra le due regioni replicate, come mostrato nella Figura 1.

Schema di replica di un database a più aree geografiche.

Figura 1. Diagramma di un database a più aree geografiche in Firestore.

Librerie client

I client web e per dispositivi mobili possono accedere direttamente a Firestore utilizzando le librerie client Android, iOS o web. Inoltre, Firestore si integra perfettamente con la piattaforma Firebase, che fornisce funzionalità come report sui arresti anomali, autenticazione degli utenti, consegna dei messaggi e analisi degli eventi utente.

Quando utilizzare Firestore

Le funzionalità di Firestore lo rendono adatto a un'ampia gamma di casi d'uso, tra cui:

  • Profili utente: gestisci i profili utente per personalizzare l'esperienza utente in base alle attività e alle preferenze passate. Puoi utilizzare lo schema flessibile di Firestore per far evolvere la struttura dei profili utente. Ad esempio, puoi aggiungere nuove proprietà per supportare nuove funzionalità nella tua app. Le modifiche allo schema vengono applicate senza tempi di inattività e le prestazioni non si riducono anche con l'aumentare del numero di utenti.
  • Inventario in tempo reale: utilizza oggetti avanzati e nidificati di Firestore per archiviare grandi quantità di dati sparsi non omogenei per prodotti diversi senza specializzare la struttura. Ad esempio, puoi creare un catalogo dei prodotti per un rivenditore.
  • Gestione delle sessioni utente: il supporto di Firestore per le transazioni ACID aiuta a garantire che gli utenti possano bloccare uno o più documenti fino al completamento della transazione. Ad esempio, puoi creare carrelli degli acquisti per le transazioni di vendita al dettaglio o un modulo di elaborazione in più parti per gli eventi di prenotazione.
  • Variazioni di stato: utilizza le transazioni ACID di Firestore per propagare le mutazioni in un numero elevato di utenti simultanei. Ad esempio, puoi mantenere uno stato coerente per tutti i giocatori in un'app di gioco.
  • Cache write-through permanente: l'elevata disponibilità e durabilità di Firestore fornisce uno stato permanente e impedisce una potenziale perdita di dati causata da un arresto anomalo dell'app. Firestore offre funzionalità come un archivio chiave-valore semplice da utilizzare. Tuttavia,Firestore non dispone di una durata (TTL) incorporata o di un meccanismo di scadenza della cache.
  • Sincronizzazione dei dati cross-device: gli aggiornamenti in tempo reale di Firestore garantiscono che tutti i dispositivi connessi visualizzino sempre lo stato più recente. Ad esempio, Firestore fornisce uno stato coerente per le app per dispositivi mobili multiutente e le app in cui è possibile connettersi da più dispositivi.
  • Gestione IoT e monitoraggio degli asset: la persistenza dei dati offline di Firestore ti consente di registrare punti dati anche quando i dispositivi perdono la connettività di rete. Ad esempio, puoi impostare il monitoraggio GPS in tempo reale di dispositivi mobili e veicoli.
  • Funzionalità in tempo reale: gli aggiornamenti in tempo reale di Firestore consentono di configurare analisi e messaggi in tempo reale. Puoi tenere aggiornati i grafici e i grafici, come le dashboard visive interattive, e impostare forum di discussione e stanze virtuali in tempo reale.
  • Contatori distribuiti: configura i contatori distribuiti per visualizzare le interazioni con i documenti, ad esempio il numero di Mi piace su un post o i preferiti di un elemento specifico.

Architetture di riferimento

Questa sezione fornisce architetture di riferimento per creare app web di grandi dimensioni che combinano Firestore con altri prodotti Google Cloud, tra cui:

  • Esportazioni giornaliere
  • Memorizzazione nella cache
  • Elaborazione dei dati
  • Modelli di addestramento per il machine learning

Queste architetture non sono prescrittive. ma sottolineano l'ampia gamma di possibili utilizzi di Firestore nella creazione di app web scalabili. Puoi riorganizzare e adattare le architetture per creare una tua app web che soddisfi i tuoi requisiti.

Videogiochi

Una piattaforma di gioco supporta l'accesso simultaneo di decine di migliaia di giocatori. I servizi di frontend del gioco utilizzano Firestore per archiviare miliardi di documenti con dati gerarchici degli stati di tutto il mondo. Firestore contiene anche dati utente come la configurazione, gli abbonamenti a feste, le gilde, gli elenchi di amici e i dati sulla presenza. Questo caso d'uso incorpora altri prodotti Google Cloud come segue:

  • Spanner offre un database coerente a livello globale in grado di conservare l'inventario o la cronologia delle corrispondenze per un numero elevato di giocatori di tutto il mondo.
  • Per velocizzare l'accesso ai dati utilizzati di frequente, viene eseguito il deployment su Memorystore di Red di una cache in memoria a livello di regione.
  • Gli eventi vengono registrati in Bigtable, dove gli sviluppatori o il personale di assistenza possono accedervi per la risoluzione dei problemi.
  • I dati provenienti dai database frontend e backend vengono regolarmente importati in BigQuery per eseguire le pipeline di analisi dei dati. Queste pipeline contribuiscono a scoprire gli exploit o a scoprire le meccaniche di gameplay che richiedono un aggiornamento prima che influiscano sulla community del gioco e respingano i giocatori.

La Figura 2 mostra l'architettura del caso d'uso dei giochi:

Architettura del caso d'uso dei giochi.

Figura 2. Esempio di architettura di piattaforme di gioco.

Internet of Things

Un'app web interattiva mostra informazioni sulla telemetria in tempo reale generate dai dispositivi IoT (Internet of Things). I dispositivi misurano e raccolgono regolarmente la temperatura e il battito cardiaco dell'utente, quindi elabora i dati come segue:

  1. Ogni misurazione viene inviata immediatamente a IoT Core tramite bridge MQTT e HTTP.
  2. IoT Core pubblica ogni misurazione come messaggio singolo in Pub/Sub.
  3. Il messaggio Pub/Sub attiva Cloud Functions che estrae informazioni pertinenti dai messaggi non elaborati e salva i risultati in Firestore per l'archiviazione a lungo termine.
  4. Un'interfaccia utente web interattiva ospitata su Firebase Hosting e basata su Angular ascolta gli aggiornamenti direttamente da Firestore. Ogni aggiornamento viene inviato automaticamente all'interfaccia utente web per visualizzare le informazioni più recenti in tempo reale.

La Figura 3 mostra la pipeline di dati per le informazioni di telemetria in questo scenario:

Architettura del caso d'uso delle app IoT.

Figura 3. Esempio di architettura di app IoT.

Vendita al dettaglio

Una piattaforma di vendita al dettaglio fornisce consigli sui prodotti ai nuovi acquirenti attraverso diversi mezzi. Un'app web registra punti dati in tempo reale sugli utenti online, come referrer, area geografica e tipo di dispositivo, quindi scrive i dati raccolti in Firestore nel seguente modo:

  1. Ogni nuova creazione di record attiva una pipeline di dati in Cloud Functions che copia i dati utente in BigQuery.
  2. Un motore per suggerimenti, implementato con Spark MLlib e implementato su Dataproc, viene addestrato con i dati utente in tempo reale archiviati in BigQuery e con i metadati di prodotto archiviati in Cloud SQL.
  3. Il motore per suggerimenti fornisce le seguenti previsioni per i prodotti consigliati:
    • Previsioni in tempo reale scritte in Firestore e inviate automaticamente ai dispositivi degli utenti online.
    • Previsioni batch inviate agli utenti offline da un servizio email.

La Figura 4 mostra il flusso di dati per lo scenario della piattaforma di vendita al dettaglio:

Architettura del caso d'uso della piattaforma di vendita al dettaglio.

Figura 4. Esempio di architettura di piattaforma per la vendita al dettaglio.

Acquisizione in tempo reale delle modifiche ai dati

Un'app riceve un input utente in tempo reale che modifica lo stato globale. In Looker Studio, una dashboard monitora gli eventi in tempo reale per comprendere meglio il comportamento e le interazioni degli utenti. Quando un'azione utente aggiorna un valore di stato, si verificano i seguenti eventi:

  1. Firestore attiva una Funzione Cloud che scrive la modifica in BigQuery, inclusi i valori precedenti e nuovi.
  2. La dashboard di Looker Studio esegue query di aggregazione in tempo reale sui dati degli eventi in BigQuery.
  3. Le query generano metriche come il rapporto tra le modifiche degli eventi aggregate a diversi bucket, il tipo univoco di eventi per bucket di tempo e la latenza di importazione degli eventi.

Per una presentazione dettagliata e una dimostrazione di questa architettura, guarda il video di Cloud Next '19 Creazione di app eccezionali con Firestore.

La Figura 5 mostra l'architettura utilizzata per acquisire modifiche ai dati in tempo reale:

Architettura del caso d'uso dell'acquisizione dei dati.

Figura 5. Esempio di una semplice architettura di acquisizione dei dati.

Modifica collaborativa dei contenuti

Un sistema di gestione dei contenuti (CMS) collaborativo consente a più editor di lavorare contemporaneamente sullo stesso articolo. Ogni volta che un editor apporta una modifica, ad esempio per aggiungere o eliminare un carattere, il client dell'editor invia la modifica direttamente a Firestore.

Se più editor inviano le modifiche contemporaneamente, si verifica il seguente processo di risoluzione:

  1. Le transazioni di Firestore assicurano che solo la prima modifica ricevuta sia scritta nel database. Altre modifiche sono state rifiutate.
  2. Firestore invia automaticamente il contenuto aggiornato a tutti gli editor.
  3. Gli editor che sono stati inizialmente rifiutati riapplicano le proprie modifiche ai contenuti aggiornati, quindi inviano di nuovo le modifiche a Firestore.
  4. La stessa procedura di risoluzione dei conflitti si ripete fino a quando tutte le modifiche apportate da tutti i client non vengono accettate e scritte nel database.

Una pipeline temporanea consente agli editor di visualizzare l'anteprima dei contenuti come segue:

  1. Un cron job ospitato in Cloud Scheduler attiva una Funzione Cloud ogni secondo.
  2. La funzione copia i contenuti più recenti da Firestore nel database temporaneo ospitato su Cloud SQL.
  3. Gli editor accedono in anteprima ai contenuti temporanei sul server temporaneo ospitato su App Engine.

Quando i contenuti sono completi, un editor fa clic sul pulsante Pubblica nel CMS. Questa azione attiva una funzione Cloud Functions che copia i contenuti più recenti da Firestore nel database di produzione ospitato in Cloud SQL. I lettori possono quindi consultare i contenuti appena pubblicati sul sito web di produzione. Per un esempio reale reale di questa architettura, leggi l'articolo del New York Times Abbiamo creato la funzionalità di modifica collaborativa per il CMS di Newsroom.

La Figura 6 mostra la pipeline per la modifica, lo staging e la pubblicazione di contenuti nel caso d'uso collaborativo per la modifica dei contenuti:

Architettura del caso d'uso di modifica dei contenuti.

Figura 6. Esempio di architettura di piattaforma per l'editing dei contenuti collaborativa.

Passaggi successivi