Memahami Penagihan Realtime Database

Firebase menagih biaya untuk data yang Anda simpan di database dan semua traffic jaringan keluar pada lapisan sesi (lapisan 5) model OSI. Besarnya biaya penyimpanan adalah $5 untuk tiap GB/bulan, dan ini dievaluasi setiap harinya. Penagihan tidak terpengaruh oleh lokasi database Anda. Traffic keluar mencakup overhead koneksi dan enkripsi dari semua operasi database dan data yang didownload melalui operasi baca database. Operasi baca dan tulis database dapat terhitung sebagai biaya koneksi pada tagihan Anda. Semua traffic yang menuju dan berasal dari database Anda, termasuk operasi yang ditolak oleh aturan keamanan, dapat dikenakan biaya.

Beberapa contoh umum dari traffic yang ditagih meliputi:

  • Data yang didownload: Saat klien mendapatkan data dari database Anda, Firebase mengenakan biaya untuk data yang didownload. Biasanya, ini merupakan sebagian besar dari biaya bandwidth Anda, tetapi bukan satu-satunya faktor dalam tagihan.
  • Overhead protokol: Diperlukan beberapa traffic tambahan antara server dan klien untuk membuat dan mempertahankan sesi. Bergantung pada protokol yang mendasarinya, traffic ini mungkin mencakup: overhead protokol realtime Firebase Realtime Database, overhead WebSocket, dan overhead header HTTP. Setiap kali koneksi dibuat, overhead ini, yang digabungkan dengan overhead enkripsi SSL, menimbulkan biaya koneksi. Meskipun tidak memerlukan bandwidth yang besar untuk satu permintaan, overhead ini bisa dikenakan biaya yang signifikan jika payload Anda kecil atau Anda sering membuat koneksi pendek.
  • Overhead enkripsi SSL: Ada biaya terkait overhead enkripsi SSL yang diperlukan untuk koneksi yang aman. Rata-rata, biaya yang dikenakan adalah sekitar 3,5 KB untuk handshake awal dan sekitar puluhan byte untuk header record TLS pada setiap pesan keluar. Untuk kebanyakan aplikasi, biaya ini hanya merupakan sebagian kecil dari tagihan Anda. Namun, persentase biaya ini bisa meningkat jika kasus Anda memerlukan banyak handshake SSL. Misalnya, perangkat yang tidak mendukung tiket sesi TLS kemungkinan akan memerlukan handshake koneksi SSL dalam jumlah besar.
  • Data Firebase console: Firebase mengenakan biaya untuk pembacaan dan penulisan data yang Anda lakukan dari Firebase console, meskipun biasanya bukan merupakan persentase yang besar dalam total biaya Realtime Database.

Memperkirakan tagihan penggunaan Anda

Untuk melihat koneksi dan penggunaan data Realtime Database Anda saat ini, buka tab Usage di Firebase console. Anda dapat memeriksa penggunaan untuk periode penagihan saat ini, 30 hari terakhir, atau 24 jam terakhir.

Firebase menunjukkan statistik penggunaan untuk metrik berikut:

  • Koneksi: Jumlah koneksi realtime simultan yang saat ini terbuka ke database Anda. Ini mencakup koneksi realtime berikut: WebSocket, long polling, dan peristiwa HTML yang dikirim oleh server. Koneksi tidak mencakup permintaan RESTful.
  • Penyimpanan: Jumlah data yang tersimpan dalam database Anda. Ini tidak mencakup hosting Firebase atau data yang disimpan melalui produk Firebase lainnya.
  • Download: Semua byte yang didownload dari database Anda, termasuk overhead protokol dan enkripsi.
  • Beban: Grafik ini menunjukkan banyaknya penggunaan database Anda untuk memproses permintaan, selama interval 1 menit yang ditentukan. Anda mungkin akan mengalami masalah performa saat beban database mendekati 100%.

Mengoptimalkan penggunaan

Ada beberapa praktik terbaik yang dapat dilakukan untuk mengoptimalkan penggunaan database dan biaya bandwidth.

  • Gunakan SDK native: Jika memungkinkan, gunakan SDK yang sesuai dengan platform aplikasi Anda, bukan REST API. SDK mempertahankan koneksi terbuka, sehingga mengurangi biaya enkripsi SSL yang biasanya bertambah jika menggunakan REST API.
  • Periksa bug: Jika biaya bandwidth Anda tinggi, pastikan aplikasi tidak melakukan banyak sinkronisasi data atau sering melakukan sinkronisasi di luar keinginan Anda. Untuk menemukan masalah secara tepat, gunakan alat profiler untuk mengukur operasi baca dan mengaktifkan logging debug di SDK Android, Objective-C, dan Web. Periksa proses sinkronisasi dan proses yang berjalan di latar belakang pada aplikasi Anda untuk memastikan semuanya sesuai keinginan Anda.
  • Kurangi koneksi: Jika memungkinkan, cobalah untuk mengoptimalkan bandwidth koneksi Anda. Permintaan REST yang kecil tetapi sering mungkin memerlukan biaya yang lebih mahal daripada koneksi tunggal dan berkelanjutan yang menggunakan SDK native. Jika Anda menggunakan REST API, pertimbangkan untuk menggunakan HTTP keep-alive atau peristiwa yang dikirim server, guna mengurangi biaya dari handshake SSL.
  • Gunakan tiket sesi TLS: Kurangi biaya overhead enkripsi SSL pada koneksi yang dilanjutkan dengan menerbitkan tiket sesi TLS. Metode ini sangat praktis jika Anda memerlukan koneksi rutin dan aman ke database.
  • Kueri indeks: Pengindeksan data mengurangi total bandwidth yang digunakan untuk kueri dan memberikan dua keuntungan, yaitu mengurangi biaya serta meningkatkan performa database. Gunakan alat profiler untuk menemukan kueri yang tidak terindeks di database Anda.
  • Optimalkan pemroses: Tambahkan kueri untuk membatasi data yang ditampilkan oleh operasi pemrosesan dan manfaatkan pemroses yang hanya mendownload pembaruan data — misalnya, on() dan bukan once(). Selain itu, tempatkan pemroses sedalam mungkin pada jalur untuk membatasi jumlah data yang disinkronkan.
  • Kurangi biaya penyimpanan: Jalankan tugas pembersihan berkala dan kurangi data duplikat di database Anda.
  • Gunakan Aturan: Cegah operasi yang berpotensi mahal dan tidak sah pada database Anda. Misalnya, penggunaan Firebase Realtime Database Security Rules dapat menghindari skenario yang memungkinkan pengguna yang berbahaya mendownload seluruh database Anda berulang kali. Pelajari lebih lanjut cara menggunakan Aturan Firebase Realtime Database.

Rencana pengoptimalan terbaik untuk aplikasi Anda bergantung pada kasus penggunaan Anda. Meskipun daftar ini belum mencakup semua praktik terbaik yang tersedia, Anda dapat menemukan saran dan tips lainnya dari pakar Firebase di saluran Slack atau Stack Overflow kami.