Firebase fattura i dati archiviati nel database e tutto il traffico di rete in uscita al livello di sessione (livello 5) del modello OSI. Lo spazio di archiviazione è fatturato in 5 $ per ogni GB al mese, valutato ogni giorno. La fatturazione non è influenzata dalla località del tuo database. Il traffico in uscita include l'overhead di connessione e crittografia da tutte le operazioni del database e dai dati scaricati tramite le letture dei database. Entrambi le letture e le scritture del database possono comportare costi di connessione in fattura. Tutti traffico da e verso il tuo database, incluse le operazioni negate dalla sicurezza generano costi fatturabili.
Ecco alcuni esempi comuni di traffico fatturato:
- Dati scaricati: quando i clienti ricevono i dati dal tuo database, Firebase addebita i costi per i dati scaricati. In genere, costituisce la maggior parte delle larghezza di banda, ma non è l'unico fattore in fattura.
- Overhead del protocollo:traffico aggiuntivo tra il server e i client. necessarie per stabilire e mantenere una sessione. A seconda della struttura questo traffico potrebbe includere: dati in tempo reale di Firebase Realtime Database l'overhead del protocollo, l'overhead WebSocket e l'overhead dell'intestazione HTTP. Ogni volta che viene connessione Internet, questo overhead, combinato con qualsiasi crittografia SSL l'overhead generale contribuisce ai costi della connessione. Anche se non si tratta di molti larghezza di banda per una singola richiesta, può essere una parte considerevole della se i tuoi payload sono ridotti o se effettui connessioni brevi e frequenti.
- L'overhead della crittografia SSL:la crittografia SSL è soggetta a un costo dell'overhead di crittografia necessario per le connessioni sicure. In media, questo costo è di circa 3, 5 kB per l'handshake iniziale e di circa decine byte per le intestazioni dei record TLS su ciascun messaggio in uscita. Per la maggior parte delle app, si tratta di una piccola percentuale della fattura. Tuttavia, questo può diventare una percentuale elevata se il tuo caso specifico richiede molti handshake SSL. Ad esempio, i dispositivi che non supportano i ticket di sessione TLS potrebbero richiedere un numero elevato di handshake di connessione SSL.
- Dati della console Firebase: anche se in genere non sono significativi parte dei costi di Realtime Database, Firebase addebita i dati che leggi e e scrivere dalla console Firebase.
Stima l'utilizzo fatturato
Per visualizzare le connessioni e l'utilizzo dei dati Realtime Database attuali, controlla la scheda Utilizzo nella console Firebase. Puoi controllare l'utilizzo nel periodo di fatturazione attuale ciclo di vita, gli ultimi 30 giorni o le ultime 24 ore.
Firebase mostra le statistiche sull'utilizzo per le seguenti metriche:
- Connessioni:il numero di connessioni simultanee, attualmente aperte e in tempo reale connessioni al tuo database. Sono inclusi i seguenti dati in tempo reale connessioni: WebSocket, lungo polling ed eventi HTML inviati dal server. Non non includono le richieste RESTful.
- Archiviazione:la quantità di dati archiviati nel database. Non sono incluse: Firebase Hosting o dati archiviati attraverso altri prodotti Firebase.
- Download:tutti i byte scaricati dal tuo database, incluso il protocollo. e l'overhead della crittografia.
- Caricamento: questo grafico mostra la quantità di database in uso, in fase di elaborazione in un dato intervallo di 1 minuto. Potresti riscontrare problemi di prestazioni man mano che il database si avvicina al 100%.
Ottimizzare l'utilizzo
Esistono alcune best practice che puoi adottare per ottimizzare l'utilizzo del database e per la larghezza di banda.
- Utilizza gli SDK nativi:se possibile, utilizza gli SDK che corrispondono la piattaforma dell'app, anziché l'API REST. Gli SDK rimangono aperti di connessione, riducendo i costi della crittografia SSL che in genere si sommano a l'API REST.
- Controlla la presenza di bug: se i costi della larghezza di banda sono inaspettatamente elevati, verifica indica che l'app non sincronizza più dati o non esegue più spesso la sincronizzazione rispetto all'origine previsto. Per individuare i problemi, utilizza lo strumento profiler per misurare le operazioni di lettura e attivare il logging di debug Android Objective-C e Web tramite SDK. Controlla i processi in background e di sincronizzazione dell'app per assicurarti tutto funzioni come previsto.
- Riduci le connessioni: se possibile, prova a ottimizzare la connessione. e larghezza di banda. Le richieste REST di piccole dimensioni e frequenti possono essere più costose una connessione continua usando l'SDK nativo. Se usi l'API REST, prendi in considerazione l'utilizzo di un'istruzione keep-alive HTTP eventi inviati dal server, il che può ridurre i costi degli handshake SSL.
- Utilizza ticket di sessione TLS: riduci i costi generali della crittografia SSL al ripristino di connessioni rilasciando Ticket di sessione TLS. Ciò è particolarmente utile se hai bisogno di connessioni frequenti e sicure. al database.
- Query di indicizzazione:indicizzazione dei dati. riduce la larghezza di banda totale utilizzata per le query, con il doppio vantaggio di ridurre i costi e aumentare le prestazioni del database. Utilizza la profiler per trovare le query non indicizzate in del database.
- Ottimizza gli ascoltatori: aggiungi query per limitare i dati restituiti dalle operazioni di ascolto e utilizza ascoltatori che scaricano solo gli aggiornamenti dei dati, ad esempio
on()anzichéonce(). Inoltre, posiziona gli ascoltatori il più possibile in fondo al percorso per limitare la quantità di dati che sincronizzano. - Riduzione dei costi di archiviazione: esegui job di pulizia periodici e riduci eventuali duplicati presenti nel database.
- Regole di utilizzo: impedisci operazioni non autorizzate e potenzialmente costose sul database. Ad esempio, l'utilizzo di Firebase Realtime Database Security Rules potrebbe evitare uno scenario un utente malintenzionato scarica ripetutamente l’intero database. Scopri di più su utilizzando le regole di Firebase Realtime Database.
Il piano di ottimizzazione migliore per la tua app dipende dal caso d'uso specifico. Non si tratta di un elenco esaustivo delle best practice, ma puoi trovare gli altri consigli e suggerimenti dagli esperti di Firebase nel nostro Canale Slack o su Stack Overflow.