Se il tuo progetto è associato al piano tariffario Spark senza costi, non ti verrà addebitato l'utilizzo di Realtime Database. Puoi usufruire di un utilizzo senza costi che include 1 GB di spazio di archiviazione dei dati e 10 GB al mese di download di dati.
Se esegui l'upgrade al piano tariffario Blaze con pagamento a consumo, mantieni l'utilizzo senza costi (1 GB di datastore e 10 GB/mese di download di dati) e ti verrà addebitato l'utilizzo oltre questo importo. Quando il tuo progetto è incluso nel piano tariffario Blaze, ti consigliamo di configurare gli avvisi relativi al budget per il progetto.
Il resto della pagina descrive la fatturazione in modo più dettagliato.
Come Realtime Database calcola la fatturazione
Firebase addebita i costi per i dati archiviati nel database e per tutto il traffico di rete in uscita a livello di sessione (livello 5) del modello OSI. L'archiviazione viene fatturata a 5 $ per ogni GB/mese, valutato giornalmente. La fatturazione non è influenzata dalla località del database. Il traffico in uscita include l'overhead di connessione e crittografia di tutte le operazioni del database e dei dati scaricati tramite le letture del database. Sia le letture che le scritture nel database possono comportare costi di connessione nella fattura. Tutto il traffico da e verso il tuo database, incluse le operazioni negate dalle regole di sicurezza, comporta costi fatturabili.
Alcuni esempi comuni di traffico fatturato includono:
- Dati scaricati: quando i client ricevono dati dal tuo database, Firebase addebita i costi per i dati scaricati. In genere, questo costituisce la maggior parte dei costi della larghezza di banda, ma non è l'unico fattore della fattura.
- Overhead del protocollo: per stabilire e mantenere una sessione, è necessario un traffico aggiuntivo tra il server e i client. A seconda del protocollo sottostante, questo traffico potrebbe includere: overhead del protocollo in tempo reale di Firebase Realtime Database, overhead di WebSocket e overhead dell'intestazione HTTP. Ogni volta che viene stabilita una connessione, questo overhead, combinato con l'overhead della crittografia SSL, contribuisce ai costi di connessione. Anche se non si tratta di una larghezza di banda elevata per una singola richiesta, può rappresentare una parte sostanziale della fattura se i payload sono di piccole dimensioni o se effettui connessioni brevi e frequenti.
- Overhead della crittografia SSL: esiste un costo associato all'overhead della crittografia SSL necessario per le connessioni sicure. In media, questo costo è di circa 3, 5 kB per l'handshake iniziale e di circa decine di byte per le intestazioni dei record TLS su ogni messaggio in uscita. Per la maggior parte delle app, si tratta di una piccola percentuale della fattura. Tuttavia, questa percentuale può aumentare 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 di solito non si tratta di una parte significativa dei costi di Realtime Database, Firebase addebita i dati che leggi e scrivi dalla console Firebase.
Stima l'utilizzo fatturato
Per visualizzare le connessioni Realtime Database e l'utilizzo dei dati attuali, controlla la scheda Utilizzo nella console Firebase. Puoi controllare l'utilizzo nel periodo di fatturazione corrente, negli ultimi 30 giorni o nelle ultime 24 ore.
Firebase mostra le statistiche sull'utilizzo per le seguenti metriche:
- Connessioni: il numero di connessioni in tempo reale simultanee, attualmente aperte, al tuo database. Sono incluse le seguenti connessioni in tempo reale: WebSocket, polling lungo ed eventi inviati dal server HTML. Non include le richieste RESTful.
- Spazio di archiviazione:la quantità di dati archiviati nel database. Non sono inclusi i dati di Firebase Hosting o quelli memorizzati mediante altri prodotti Firebase.
- Download: tutti i byte scaricati dal database, inclusi l'overhead di protocollo e di crittografia.
- Carico: questo grafico mostra la quantità di database in uso, che elabora le richieste, in un determinato intervallo di 1 minuto. Potresti riscontrare problemi di prestazioni man mano che il database si avvicina al 100%.
Ottimizza l'utilizzo
Esistono alcune best practice che puoi adottare per ottimizzare l'utilizzo del database e i costi della larghezza di banda.
- Utilizza gli SDK nativi:se possibile, utilizza gli SDK corrispondenti alla piattaforma della tua app anziché l'API REST. Gli SDK mantengono le connessioni aperte, riducendo i costi di crittografia SSL che in genere si sommano all'API REST.
- Verifica la presenza di bug:se i costi della larghezza di banda sono inaspettatamente elevati, verifica che la tua app non sincronizzi più dati o non esegua la sincronizzazione più spesso di quanto previsto inizialmente. Per individuare i problemi, utilizza lo strumento di profilazione per misurare le operazioni di lettura e attiva il logging di debug negli SDK Android, Objective-C e Web. Controlla i processi in background e di sincronizzazione nella tua app per assicurarti che tutto funzioni come previsto.
- Riduci le connessioni: se possibile, prova a ottimizzare la larghezza di banda della connessione. Le richieste REST frequenti e di piccole dimensioni possono essere più costose di una singola connessione continua che utilizza l'SDK nativo. Se utilizzi l'API REST, valuta la possibilità di utilizzare un keep-alive HTTP o eventi inviati dal server, che possono ridurre i costi degli handshake SSL.
- Utilizza i ticket di sessione TLS: riduci i costi di overhead della crittografia SSL sulle connessioni riprese emettendo ticket di sessione TLS. Questo è particolarmente utile se hai bisogno di connessioni frequenti e sicure al database.
- Query di indicizzazione: l'indicizzazione dei dati riduce la larghezza di banda totale utilizzata per le query, con il duplice vantaggio di ridurre i costi e aumentare le prestazioni del database. Utilizza lo strumento di profilazione per trovare le query non indicizzate nel tuo database.
- Ottimizza i listener: aggiungi query per limitare i dati restituiti dalle operazioni di ascolto e utilizza listener che scaricano solo gli aggiornamenti dei dati, ad esempio
on()anzichéonce(). Inoltre, posiziona i listener il più in basso possibile nel percorso per limitare la quantità di dati sincronizzati. - Riduci i costi di archiviazione: esegui job di pulizia periodici e riduci i dati duplicati nel database.
- Utilizza le regole:impedisci operazioni potenzialmente costose e non autorizzate sul tuo database. Ad esempio, l'utilizzo di Firebase Realtime Database Security Rules potrebbe evitare uno scenario in cui un utente malintenzionato scarica ripetutamente l'intero database. Scopri di più sull'utilizzo delle regole di Firebase Realtime Database.
Il piano di ottimizzazione migliore per la tua app dipende dal tuo caso d'uso specifico. Sebbene questo non sia un elenco esaustivo di best practice, puoi trovare altri consigli e suggerimenti degli esperti di Firebase sul nostro canale Slack o su Stack Overflow.