Gdy Twój projekt korzysta z bezpłatnego abonamentu Spark, nie są naliczane opłaty za korzystanie z Realtime Database. Możesz bezpłatnie korzystać z 1 GB miejsca na dane i 10 GB pobierania danych miesięcznie.
Jeśli przejdziesz na abonament Blaze z płatnością według wykorzystania, zachowasz bezpłatne wykorzystanie (1 GB miejsca na dane i 10 GB pobierania danych miesięcznie), a opłaty będą naliczane za wykorzystanie przekraczające te limity. Gdy Twój projekt korzysta z abonamentu Blaze, zalecamy skonfigurowanie alertów budżetowych.
W dalszej części tej strony znajdziesz szczegółowe informacje o rozliczeniach.
Jak Realtime Database oblicza opłaty
Firebase nalicza opłaty za dane przechowywane w bazie danych i cały ruch wychodzący w warstwie sesji (warstwie 5) modelu OSI. Opłaty za miejsce na dane wynoszą 5 USD za każdy GB miesięcznie i są naliczane codziennie. Lokalizacja bazy danych nie ma wpływu na rozliczenia. Ruch wychodzący obejmuje narzut związany z połączeniem i szyfrowaniem wynikający ze wszystkich operacji na bazie danych oraz dane pobrane podczas odczytu z bazy danych. Zarówno odczyt, jak i zapis w bazie danych mogą powodować naliczanie opłat za połączenie. Cały ruch do i z bazy danych, w tym operacje odrzucone przez reguły bezpieczeństwa, generuje koszty podlegające rozliczeniu.
Oto kilka typowych przykładów ruchu, za który są naliczane opłaty:
- Pobrane dane: gdy klienci pobierają dane z Twojej bazy danych, Firebase nalicza opłaty za pobrane dane. Zwykle stanowią one większość kosztów przepustowości, ale nie są jedynym czynnikiem wpływającym na rachunek.
- Narzut protokołu: do nawiązania i utrzymania sesji potrzebny jest dodatkowy ruch między serwerem a klientami. W zależności od protokołu bazowego ten ruch może obejmować: narzut protokołu czasu rzeczywistego Bazy danych czasu rzeczywistego Firebase, narzut WebSocket i narzut nagłówka HTTP. Za każdym razem, gdy nawiązywane jest połączenie, ten narzut w połączeniu z narzutem szyfrowania SSL przyczynia się do kosztów połączenia. Chociaż w przypadku pojedynczego żądania nie jest to duża przepustowość, może stanowić znaczną część rachunku, jeśli ładunki są małe lub często nawiązujesz krótkie połączenia.
- Narzut szyfrowania SSL: z narzutem szyfrowania SSL niezbędnym do bezpiecznych połączeń wiąże się koszt. Średnio koszt ten wynosi około 3,5 KB w przypadku początkowego uzgadniania połączenia i około kilkudziesięciu bajtów w przypadku nagłówków rekordów TLS w każdej wiadomości wychodzącej. W przypadku większości aplikacji jest to niewielki procent rachunku. Może to jednak stanowić duży procent, jeśli w Twoim konkretnym przypadku wymagana jest duża liczba uzgodnień SSL. Na przykład urządzenia które nie obsługują biletów sesji TLS mogą wymagać dużej liczby uzgodnień połączenia SSL.
- Firebase dane z konsoli: chociaż zwykle nie stanowią one znaczącej części kosztów Realtime Database, Firebase nalicza opłaty za dane odczytywane i zapisywane w konsoli Firebase.
Szacowanie rozliczanego wykorzystania
Aby sprawdzić bieżące połączenia z Realtime Database i użycie danych, otwórz kartę Wykorzystanie w konsoli Firebase. Możesz sprawdzić wykorzystanie w bieżącym okresie rozliczeniowym, w ciągu ostatnich 30 dni lub w ciągu ostatnich 24 godzin.
Firebase wyświetla statystyki wykorzystania tych danych:
- Połączenia: liczba jednoczesnych, obecnie otwartych połączeń z bazą danych w czasie rzeczywistym. Obejmuje to te połączenia w czasie rzeczywistym: WebSocket, długie sondowanie i zdarzenia wysyłane przez serwer HTML. Nie obejmuje to żądań RESTowych.
- Miejsce na dane: ilość danych przechowywanych w bazie danych. Nie obejmuje to Hostingu Firebase ani danych przechowywanych w innych usługach Firebase.
- Pobrane dane: wszystkie bajty pobrane z bazy danych, w tym narzut protokołu i szyfrowania.
- Obciążenie: ten wykres pokazuje, jaka część bazy danych jest używana do przetwarzania żądań w danym jednominutowym przedziale czasu. Gdy baza danych zbliża się do 100% wykorzystania, mogą wystąpić problemy z wydajnością.
Optymalizacja wykorzystania
Aby zoptymalizować wykorzystanie bazy danych i koszty przepustowości, możesz zastosować kilka sprawdzonych metod.
- Używaj natywnych pakietów SDK: jeśli to możliwe, zamiast interfejsu API REST używaj pakietów SDK odpowiadających platformie aplikacji. Pakiety SDK utrzymują otwarte połączenia, co zmniejsza koszty szyfrowania SSL, które zwykle rosną w przypadku interfejsu API REST.
- Sprawdź, czy nie ma błędów: jeśli koszty przepustowości są nieoczekiwanie wysokie, sprawdź, czy aplikacja nie synchronizuje większej ilości danych lub nie synchronizuje ich częściej niż pierwotnie zamierzałeś. Aby zidentyfikować problemy, użyj programu profilującego do pomiaru operacji odczytu i włącz rejestrowanie debugowania w pakietach SDK na Androida, Objective-C i w internecie. Sprawdź procesy działające w tle i synchronizację w aplikacji, aby upewnić się, że wszystko działa zgodnie z Twoimi oczekiwaniami.
- Zmniejsz liczbę połączeń: jeśli to możliwe, spróbuj zoptymalizować przepustowość połączenia. Częste, małe żądania RESTowe mogą być droższe niż pojedyncze, ciągłe połączenie przy użyciu natywnego pakietu SDK. Jeśli używasz interfejsu API REST, rozważ użycie funkcji HTTP utrzymywanie aktywności lub zdarzeń wysyłanych przez serwer, co może zmniejszyć koszty związane z uzgadnianiem połączenia SSL.
- Używaj biletów sesji TLS: zmniejsz koszty narzutu szyfrowania SSL w przypadku wznowionych połączeń, wydając bilety sesji TLS. Jest to szczególnie przydatne, jeśli potrzebujesz częstych, bezpiecznych połączeń z bazą danych.
- Indeksowanie zapytań: indeksowanie danych zmniejsza całkowitą przepustowość używaną do zapytań, co ma podwójną korzyść – obniża koszty i zwiększa wydajność bazy danych. Użyj narzędzia profilującego, aby znaleźć w bazie danych zapytania bez indeksu.
- Optymalizuj odbiorniki: dodaj zapytania, aby ograniczyć dane zwracane przez operacje nasłuchiwania, i używaj odbiorników, które pobierają tylko aktualizacje danych – na przykład
on()zamiastonce(). Dodatkowo umieść odbiorniki jak najdalej w ścieżce, aby ograniczyć ilość synchronizowanych przez nie danych. - Zmniejsz koszty miejsca na dane: regularnie uruchamiaj zadania czyszczenia i zmniejsz ilość zduplikowanych danych w bazie danych.
- Używaj reguł: zapobiegaj potencjalnie kosztownym, nieautoryzowanym operacjom w bazie danych. Na przykład użycie Firebase Realtime Database Security Rules może zapobiec sytuacji w której złośliwy użytkownik wielokrotnie pobiera całą bazę danych. Dowiedz się więcej o używaniu reguł Bazy danych czasu rzeczywistego Firebase.
Najlepszy plan optymalizacji aplikacji zależy od konkretnego przypadku użycia. Nie jest to wyczerpująca lista sprawdzonych metod, ale więcej porad i wskazówek od ekspertów Firebase znajdziesz na naszym kanale Slack lub w Stack Overflow.