Utilizza le best practice elencate qui come riferimento rapido quando crei un'applicazione che utilizza Cloud Firestore.
Località del database
Quando crei l'istanza del database, seleziona la posizione del database più vicina agli utenti e alle risorse di calcolo. Gli hop di rete di vasta portata sono più soggetti a errori e aumentano la latenza delle query.
Per massimizzare la disponibilità e la durabilità della tua applicazione, seleziona una posizione multiregionale e inserisci le risorse di calcolo critiche in almeno due regioni.
Seleziona una località regionale per costi inferiori, per una latenza di scrittura inferiore se la tua applicazione è sensibile alla latenza o per la collocazione con altre risorse Google Cloud.
ID documento
- Evita gli ID documento
.e... - Evita di utilizzare le barre
/negli ID documento. Non utilizzare ID documento in aumento monotono, ad esempio:
Customer1,Customer2,Customer3, ...Product 1,Product 2,Product 3, ...
Questi ID sequenziali possono portare a hotspot che influiscono sulla latenza.
Nomi campi
Evita i seguenti caratteri nei nomi dei campi perché richiedono un'interpretazione letterale aggiuntiva:
.punto[parentesi quadra aperta]parentesi quadra chiusa*asterisco`accento grave
Indici
Riduci la latenza di scrittura
Il principale fattore che contribuisce alla latenza di scrittura è l'espansione dell'indice. Le best practice per ridurre la ramificazione dell'indice sono:
Imposta le esenzioni dell'indice a livello di raccolta. Un'impostazione predefinita semplice è disattivare l'indicizzazione decrescente e degli array. La rimozione dei valori indicizzati non utilizzati ridurrà anche i costi di archiviazione.
Riduci il numero di documenti in una transazione. Per scrivere un numero elevato di documenti, valuta la possibilità di utilizzare uno strumento di scrittura collettiva anziché quello di scrittura batch atomica.
Esenzioni dell'indice
Per la maggior parte delle app, puoi fare affidamento sull'indicizzazione automatica e su eventuali link ai messaggi di errore per gestire gli indici. Tuttavia, potresti voler aggiungere esenzioni per un singolo campo nei seguenti casi:
| Richiesta | Descrizione |
|---|---|
| Campi stringa grandi | Se hai un campo stringa che spesso contiene valori stringa lunghi che non utilizzi per le query, puoi ridurre i costi di archiviazione esentando il campo dall'indicizzazione. |
| Frequenze di scrittura elevate in una raccolta contenente documenti con valori sequenziali | Se indicizzi un campo che aumenta o diminuisce in sequenza tra i documenti di una raccolta, ad esempio un timestamp, la frequenza massima di scrittura nella raccolta è di 500 scritture al secondo. Se non esegui query in base al campo con valori sequenziali, puoi esentare il campo dall'indicizzazione per aggirare questo limite. In un caso d'uso IoT con una frequenza di scrittura elevata, ad esempio, una raccolta contenente documenti con un campo timestamp potrebbe avvicinarsi al limite di 500 scritture al secondo. |
| Campi TTL |
Se utilizzi policy TTL (time-to-live), tieni presente che il campo TTL deve essere un timestamp. L'indicizzazione nei campi TTL è attivata per impostazione predefinita e può influire sul rendimento a tassi di traffico più elevati. Come best practice, aggiungi esenzioni a campo singolo per i campi TTL. |
| Campi di array o mappe di grandi dimensioni | I campi di array o mappa di grandi dimensioni possono avvicinarsi al limite di 40.000 voci di indice per documento. Se non esegui query in base a un array o un campo mappa di grandi dimensioni, devi esentarlo dall'indicizzazione. |
Operazioni di lettura e scrittura
La frequenza massima esatta con cui un'app può aggiornare un singolo documento dipende molto dal carico di lavoro. Per saperne di più, vedi Aggiornamenti a un singolo documento.
Utilizza le chiamate asincrone, se disponibili, anziché quelle sincrone. Le chiamate asincrone riducono al minimo l'impatto della latenza. Ad esempio, considera un'applicazione che ha bisogno del risultato di una ricerca di documenti e dei risultati di una query prima di generare una risposta. Se la ricerca e la query non hanno una dipendenza dai dati, non è necessario attendere in modo sincrono il completamento della ricerca prima di avviare la query.
Non utilizzare offset. Utilizza invece i cursori. L'utilizzo di un offset evita solo di restituire i documenti ignorati all'applicazione, ma questi documenti vengono comunque recuperati internamente. I documenti ignorati influiscono sulla latenza della query e alla tua applicazione vengono addebitate le operazioni di lettura necessarie per recuperarli.
Tentativi di transazione
Gli Cloud Firestore SDK e le librerie client riprovano automaticamente le transazioni non riuscite per gestire gli errori temporanei. Se la tua applicazione accede a Cloud Firestore tramite le API REST o RPC direttamente anziché tramite un SDK, la tua applicazione deve implementare i tentativi di ripetizione delle transazioni per aumentare l'affidabilità.
Aggiornamenti in tempo reale
Per le best practice relative agli aggiornamenti in tempo reale, vedi Comprendere le query in tempo reale su larga scala.
Progettazione per la scalabilità
Le seguenti best practice descrivono come evitare situazioni che creano problemi di contesa.
Aggiornamenti a un singolo documento
Quando progetti la tua app, considera la velocità con cui aggiorna i singoli documenti. Il modo migliore per caratterizzare le prestazioni del carico di lavoro è eseguire test di carico. La frequenza massima esatta con cui un'app può aggiornare un singolo documento dipende molto dal carico di lavoro. I fattori includono la velocità di scrittura, la contesa tra le richieste e il numero di indici interessati.
Un'operazione di scrittura di documenti aggiorna il documento e tutti gli indici associati e Cloud Firestore applica in modo sincrono l'operazione di scrittura a un quorum di repliche. A frequenze di scrittura sufficientemente elevate, il database inizierà a riscontrare contese, latenza più elevata o altri errori.
Tassi elevati di lettura, scrittura ed eliminazione in un intervallo di documenti ristretto
Evita frequenze di lettura o scrittura elevate per documenti vicini in ordine lessicografico, altrimenti la tua applicazione riscontrerà errori di contesa. Questo problema è noto come hotspotting e la tua applicazione può riscontrarlo se esegue una delle seguenti operazioni:
Crea nuovi documenti a una velocità molto elevata e alloca i propri ID in aumento monotono.
Cloud Firestore alloca gli ID documento utilizzando un algoritmo di dispersione. Non dovresti riscontrare hotspotting nelle scritture se crei nuovi documenti utilizzando ID documento automatici.
Crea nuovi documenti a un ritmo elevato in una raccolta con pochi documenti.
Crea nuovi documenti con un campo in aumento monotono, come un timestamp, a una velocità molto elevata.
Elimina i documenti in una raccolta a una velocità elevata.
Scrive nel database a una velocità molto elevata senza aumentare gradualmente il traffico.
Evitare di saltare i dati eliminati
Evita le query che ignorano i dati eliminati di recente. Una query potrebbe dover saltare un numero elevato di voci dell'indice se i primi risultati della query sono stati eliminati di recente.
Un esempio di carico di lavoro che potrebbe dover saltare molti dati eliminati è quello che tenta di trovare gli elementi di lavoro in coda più vecchi. La query potrebbe avere il seguente aspetto:
docs = db.collection('WorkItems').order_by('created').limit(100)
delete_batch = db.batch()
for doc in docs.stream():
finish_work(doc)
delete_batch.delete(doc.reference)
delete_batch.commit()
Ogni volta che viene eseguita, questa query esegue la scansione delle voci di indice per il campo created in tutti i documenti eliminati di recente. In questo modo le query vengono rallentate.
Per migliorare il rendimento, utilizza il metodo start_at per trovare il punto di partenza migliore. Ad esempio:
completed_items = db.collection('CompletionStats').document('all stats').get()
docs = db.collection('WorkItems').start_at(
{'created': completed_items.get('last_completed')}).order_by(
'created').limit(100)
delete_batch = db.batch()
last_completed = None
for doc in docs.stream():
finish_work(doc)
delete_batch.delete(doc.reference)
last_completed = doc.get('created')
if last_completed:
delete_batch.update(completed_items.reference,
{'last_completed': last_completed})
delete_batch.commit()
NOTA: l'esempio precedente utilizza un campo che aumenta monotonicamente, il che è un anti-pattern per le frequenze di scrittura elevate.
Aumento graduale del traffico
Devi aumentare gradualmente il traffico verso nuove raccolte o documenti vicini in ordine lessicografico per dare a Cloud Firestore il tempo sufficiente per preparare i documenti a un aumento del traffico. Ti consigliamo di iniziare con un massimo di 500 operazioni al secondo in una nuova raccolta e poi aumentare il traffico del 50% ogni 5 minuti. Puoi aumentare in modo simile il traffico di scrittura, ma tieni presente i limiti standard di Cloud Firestore. Assicurati che le operazioni siano distribuite in modo relativamente uniforme nell'intervallo di tasti. Questa è chiamata la regola "500/50/5".
Migrazione del traffico a una nuova raccolta
L'aumento graduale è particolarmente importante se esegui la migrazione del traffico delle app da una raccolta a un'altra. Un modo semplice per gestire questa migrazione è leggere dalla vecchia raccolta e, se il documento non esiste, leggere dalla nuova raccolta. Tuttavia, ciò potrebbe causare un improvviso aumento del traffico verso documenti vicini in ordine lessicografico nella nuova raccolta. Cloud Firestore potrebbe non essere in grado di preparare in modo efficiente la nuova raccolta per un aumento del traffico, soprattutto se contiene pochi documenti.
Un problema simile può verificarsi se modifichi gli ID documento di molti documenti all'interno della stessa raccolta.
La strategia migliore per eseguire la migrazione del traffico a una nuova raccolta dipende dal modello di dati. Di seguito è riportato un esempio di strategia nota come letture parallele. Dovrai determinare se questa strategia è efficace per i tuoi dati e un aspetto importante da considerare sarà l'impatto sui costi delle operazioni parallele durante la migrazione.
Letture parallele
Per implementare le letture parallele durante la migrazione del traffico a una nuova raccolta, leggi prima dalla vecchia raccolta. Se il documento non è presente, leggi dalla nuova raccolta. Un elevato tasso di letture di documenti inesistenti può portare all'hotspotting, quindi assicurati di aumentare gradualmente il carico nella nuova raccolta. Una strategia migliore è copiare il vecchio documento nella nuova raccolta e poi eliminare il vecchio documento. Aumenta gradualmente le letture parallele per assicurarti che Cloud Firestore possa gestire il traffico verso la nuova raccolta.
Una possibile strategia per aumentare gradualmente le letture o le scritture in una nuova raccolta consiste nell'utilizzare un hash deterministico dell'ID utente per selezionare una percentuale casuale di utenti che tentano di scrivere nuovi documenti. Assicurati che il risultato dell'hash dell'ID utente non sia distorto dalla tua funzione o dal comportamento degli utenti.
Nel frattempo, esegui un job batch che copia tutti i dati dai vecchi documenti alla nuova raccolta. Il tuo job batch deve evitare scritture su ID documento sequenziali per evitare hotspot. Al termine del job batch, potrai leggere solo dalla nuova raccolta.
Un perfezionamento di questa strategia consiste nel migrare piccoli batch di utenti alla volta. Aggiungi un campo al documento utente che monitora lo stato della migrazione dell'utente. Seleziona un batch di utenti da migrare in base a un hash dell'ID utente. Utilizza un job batch per eseguire la migrazione dei documenti per quel batch di utenti e utilizza letture parallele per gli utenti a metà della migrazione.
Tieni presente che non puoi eseguire facilmente il rollback a meno che non esegui la doppia scrittura delle entità precedenti e nuove durante la fase di migrazione. In questo modo aumenterebbero i costi sostenuti per Cloud Firestore.
Privacy
- Evita di archiviare informazioni sensibili in un ID progetto cloud. Un ID progetto Cloud potrebbe essere conservato oltre la durata del progetto.
- Come best practice per la conformità dei dati, ti consigliamo di non archiviare informazioni sensibili nei nomi dei documenti e nei nomi dei campi dei documenti.
Prevenire l'accesso non autorizzato
Impedisci operazioni non autorizzate sul tuo database con Cloud Firestore Security Rules. Ad esempio, l'utilizzo delle regole potrebbe evitare uno scenario in cui un utente malintenzionato scarica ripetutamente l'intero database.
Scopri di più sull'utilizzo di Cloud Firestore Security Rules.