Se il tuo progetto utilizza il piano tariffario Spark senza costi aggiuntivi, non ti vengono addebitati costi per l'utilizzo di Realtime Database. L'utilizzo senza costi include 1 GB di spazio di archiviazione dei dati e 10 GB/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 spazio di archiviazione dei dati e 10 GB/mese di download di dati) e ti vengono addebitati costi per qualsiasi utilizzo oltre questa quantità. Se il tuo progetto utilizza il 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 al livello di sessione (livello 5) del modello OSI. L'archiviazione viene fatturata a 5 $ per ogni GB/mese, valutata quotidianamente. 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 i dati scaricati tramite le letture del database. Sia le letture che le scritture del database possono comportare costi di connessione sulla fattura. Tutto il traffico verso e dal database, incluse le operazioni negate dalle regole di sicurezza, comporta costi fatturabili.
Ecco alcuni esempi comuni di traffico fatturato:
- Dati scaricati: quando i client ricevono dati dal database, Firebase addebita i costi per i dati scaricati. In genere, questa voce rappresenta la maggior parte dei costi della larghezza di banda, ma non è l'unico fattore della fattura.
- Overhead del protocollo: è necessario un traffico aggiuntivo tra il server e i client per stabilire e mantenere una sessione. A seconda del protocollo sottostante, questo traffico potrebbe includere: l'overhead del protocollo in tempo reale di Firebase Realtime Database, l'overhead di WebSocket e l'overhead delle intestazioni HTTP. Ogni volta che viene stabilita una connessione, questo overhead, combinato con l'overhead di crittografia SSL, contribuisce ai costi di connessione. Sebbene non si tratti di una grande quantità di larghezza di banda per una singola richiesta, può rappresentare una parte sostanziale della fattura se i payload sono piccoli o se effettui connessioni brevi e frequenti.
- Overhead di crittografia SSL: è previsto un costo associato all'overhead di 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, questa voce rappresenta una piccola percentuale della fattura. Tuttavia, 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.
- Firebase dati della console: sebbene in genere non rappresenti una parte significativa dei costi di Realtime Database, Firebase addebita i costi per i dati che leggi e scrivi dalla console Firebase.
Stimare l'utilizzo fatturato
Per visualizzare le connessioni e l'utilizzo dei dati Realtime Database correnti, 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 di utilizzo per le seguenti metriche:
- Connessioni: il numero di connessioni in tempo reale simultanee e attualmente aperte al database. Sono incluse le seguenti connessioni in tempo reale: WebSocket, long polling ed eventi inviati dal server HTML. Non sono incluse le richieste RESTful.
- Archiviazione: la quantità di dati archiviati nel database. Non sono inclusi Firebase Hosting o i dati archiviati tramite altri prodotti Firebase.
- Download: tutti i byte scaricati dal database, inclusi l'overhead del protocollo e della 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 quando il database si avvicina al 100%.
Ottimizzare 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: quando 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 accumulano con l'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 in origine. Per individuare i problemi, utilizza lo strumento di profilazione per misurare le operazioni di lettura e attiva la registrazione di debug negli SDK Android, Objective-C, e web. Controlla i processi di sincronizzazione e in background 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 piccole e frequenti 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 HTTP keep-alive o eventi inviati dal server, che possono ridurre i costi degli handshake SSL.
- Utilizza i ticket di sessione TLS: riduci i costi dell'overhead di crittografia SSL sulle connessioni riprese emettendo ticket di sessione TLS. Questa opzione è particolarmente utile se sono necessarie connessioni sicure e frequenti al database.
- Indicizza le query: 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 database.
- Ottimizza i listener: aggiungi query per limitare i dati restituiti dalle operazioni di ascolto e utilizza i 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 periodicamente job di pulizia e riduci i dati duplicati nel database.
- Utilizza le regole: impedisci operazioni non autorizzate e potenzialmente costose sul 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 dagli esperti di Firebase sul nostro canale Slack o su Stack Overflow.