Firebase nalicza opłaty za dane przechowywane w bazie danych i za cały ruch wychodzący w sieci na poziomie sesji (warstwa 5) modelu OSI. Za miejsce na dane pobieramy opłatę w wysokości 5 USD za GB miesięcznie. Opłata jest naliczana codziennie. Lokalizacja bazy danych nie wpływa na płatności. Ruch wychodzący obejmuje narzut związany z połączeniem i szyfrowaniem ze wszystkich operacji na bazie danych oraz dane pobrane w ramach odczytu z bazy danych. Zarówno odczyty, jak i zapisy w bazie danych mogą generować koszty połączenia na Twoim rachunku. Cały ruch do i z bazy danych, w tym operacje odrzucone przez reguły zabezpieczeń, generuje koszty.
Przykłady typowego ruchu, za który naliczane są opłaty:
- Pobrane dane: gdy klienci pobierają dane z Twojej bazy danych, Firebase nalicza opłaty za pobrane dane. Zwykle stanowi to większość kosztów przepustowości, ale nie jest jedynym czynnikiem wpływającym na rachunek.
- Narzucone obciążenie protokołu: do nawiązania i utrzymania sesji konieczny 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 protokołu 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 zwiększa koszty połączenia. Chociaż w przypadku pojedynczego żądania nie jest to duża ilość przepustowości, może stanowić znaczną część rachunku, jeśli ładunki są małe lub często nawiązujesz krótkie połączenia.
- Obciążenie związane z szyfrowaniem SSL: z szyfrowaniem SSL niezbędnym do nawiązywania bezpiecznych połączeń wiąże się pewien 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 odsetek rachunku. Jeśli jednak w Twoim przypadku wymagana jest duża liczba uzgodnień SSL, może to stanowić duży odsetek. Na przykład urządzenia, które nie obsługują biletów sesji TLS, mogą wymagać dużej liczby uzgodnień połączenia SSL.
- FirebaseDane konsoli: chociaż zwykle nie stanowią one znaczącej części kosztów Realtime Database, Firebase pobiera opłaty za dane odczytywane i zapisywane w konsoli Firebase.
Szacowanie rozliczanego wykorzystania
Aby sprawdzić bieżące połączenia Realtime Database i wykorzystanie 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 użytkowania dotyczące tych danych:
- Połączenia: liczba jednoczesnych, aktualnie otwartych połączeń z bazą danych w czasie rzeczywistym. Obejmuje to połączenia w czasie rzeczywistym: WebSocket, długie odpytywanie i zdarzenia wysyłane przez serwer HTML. Nie obejmuje żądań RESTful.
- Miejsce na dane: ilość danych przechowywanych w bazie danych. Nie obejmuje to Hostingu Firebase ani danych zapisanych przy użyciu innych usług 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 1-minutowym przedziale czasu. Gdy wartość ta będzie bliska 100%, mogą pojawić się problemy z wydajnością.
Optymalizacja wykorzystania
Istnieje kilka sprawdzonych metod, które możesz zastosować, aby zoptymalizować wykorzystanie bazy danych i koszty przepustowości.
- Używaj natywnych pakietów SDK: w miarę możliwości używaj pakietów SDK odpowiednich dla platformy aplikacji zamiast interfejsu API REST. Zestawy 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 robi tego częściej, niż pierwotnie zamierzałeś(-aś). Aby zidentyfikować problemy, użyj profilera do pomiaru operacji odczytu i włącz dzienniki debugowania w pakietach SDK na Androida, Objective-C i Web. 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 REST mogą być droższe niż pojedyncze, ciągłe połączenie przy użyciu natywnego pakietu SDK. Jeśli korzystasz z interfejsu API REST, rozważ użycie funkcji HTTP keep-alive lub zdarzeń wysyłanych przez serwer, które mogą obniżyć koszty związane z uzgadnianiem połączenia SSL.
- Używaj biletów sesji TLS: zmniejsz koszty związane z szyfrowaniem SSL w przypadku wznowionych połączeń, wydając bilety sesji TLS. Jest to szczególnie przydatne, jeśli często potrzebujesz bezpiecznych połączeń z bazą danych.
- Zapytania indeksujące: indeksowanie danych zmniejsza całkowitą przepustowość wykorzystywaną na potrzeby zapytań, co ma podwójną zaletę: obniża koszty i zwiększa wydajność bazy danych. Użyj narzędzia profiler, aby znaleźć w bazie danych zapytania, które nie są indeksowane.
- Zoptymalizuj odbiorców: dodaj zapytania, aby ograniczyć dane zwracane przez operacje nasłuchiwania, i używaj odbiorców, którzy pobierają tylko aktualizacje danych, np.
on()
zamiastonce()
. Dodatkowo umieść odbiorniki jak najdalej na ścieżce, aby ograniczyć ilość synchronizowanych przez nie danych. - Obniż koszty przechowywania: okresowo uruchamiaj zadania czyszczenia i usuwaj z bazy danych zduplikowane dane.
- 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 korzystaniu z reguł Bazy danych czasu rzeczywistego Firebase.
Najlepszy plan optymalizacji aplikacji zależy od konkretnego przypadku użycia. To nie jest wyczerpująca lista sprawdzonych metod. Więcej porad i wskazówek od ekspertów Firebase znajdziesz na naszym kanale Slack lub na Stack Overflow.