Jeśli Twój projekt jest objęty bezpłatnym abonamentem Spark, nie naliczamy opłat za korzystanie z Realtime Database. Możesz bezpłatnie korzystać z 1 GB magazynu danych i pobierać 10 GB danych miesięcznie.
Jeśli przejdziesz na abonament Blaze z płatnością według wykorzystania, zachowasz bezpłatne wykorzystanie (1 GB magazynu danych i 10 GB pobierania danych miesięcznie), a opłaty będą naliczane za wykorzystanie powyżej tej ilości. Jeśli Twój projekt jest objęty abonamentem Blaze, zalecamy skonfigurowanie w nim alertów dotyczących budżetu.
Bardziej szczegółowe informacje o płatnościach znajdziesz w dalszej części tej strony.
Jak Realtime Database oblicza płatności
Firebase nalicza opłaty za dane przechowywane w bazie danych i cały ruch wychodzący w sieci w warstwie sesji (warstwa 5) modelu OSI. Opłata za miejsce na dane wynosi 5 USD za każdy GB miesięcznie i 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 bazy danych oraz danych pobranych przez odczyty bazy danych. Zarówno odczyty, jak i zapisy w bazie danych mogą powodować naliczanie kosztów połączenia na rachunku. Cały ruch do i z bazy danych, w tym operacje odrzucone przez reguły zabezpieczeń, generuje naliczane koszty.
Typowe przykłady ruchu podlegającego rozliczeniu:
- Pobrane dane: gdy klienci pobierają dane z bazy danych, Firebase pobiera opłatę za pobrane dane. Zwykle stanowi to większość kosztów przepustowości, ale nie jest to jedyny czynnik wpływający na rachunek.
- Narzut 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 ruch ten 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, przyczynia się do kosztów połączenia. Chociaż nie jest to duża przepustowość w przypadku pojedynczego żądania, może stanowić znaczną część rachunku, jeśli ładunki są niewielkie lub często nawiązujesz krótkie połączenia.
- Narzut szyfrowania SSL: z narzutem szyfrowania SSL, który jest niezbędny do nawiązywania bezpiecznych połączeń, wiąże się koszt. Średnio jest to 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 odsetek, jeśli w Twoim przypadku wymaganych jest wiele uzgodnień SSL. Na przykład urządzenia, które nie obsługują biletów sesji TLS, mogą wymagać dużej liczby uzgodnień połączeń SSL.
- Dane konsoli Firebase: chociaż zwykle nie stanowi to znaczącej części kosztów Realtime Database, Firebase pobiera opłaty za dane, które odczytujesz i zapisujesz w konsoli Firebase.
Szacowanie rozliczanego wykorzystania
Aby sprawdzić bieżące połączenia Realtime Database i wykorzystanie danych, otwórz kartę Użycie 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ń w czasie rzeczywistym z bazą danych. Obejmuje to te połączenia w czasie rzeczywistym: WebSocket, długie sondowanie i zdarzenia wysyłane przez serwer HTML. Nie obejmuje żądań RESTful.
- Pamięć: ilość danych przechowywanych w bazie danych. Nie obejmuje to hostingu Firebase ani danych przechowywanych w innych usługach Firebase.
- Pobieranie: 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 interwale. Gdy baza danych zbliża się do 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: gdy tylko jest to możliwe, używaj pakietów SDK, które odpowiadają platformie aplikacji, zamiast interfejsu API REST. Pakiety SDK utrzymują otwarte połączenia, co zmniejsza koszty szyfrowania SSL, które zwykle sumują się w przypadku interfejsu REST API.
- Sprawdź, czy nie ma błędów: jeśli koszty przepustowości są nieoczekiwanie wysokie, sprawdź, czy aplikacja nie synchronizuje więcej danych lub nie synchronizuje ich częściej, niż było to pierwotnie zamierzone. Aby precyzyjnie określić problemy, użyj narzędzia do profilowania, aby zmierzyć operacje odczytu i włączyć rejestrowanie debugowania w pakietach SDK na Androida, Objective-C i sieć. Sprawdź procesy działające w tle i procesy synchronizacji w aplikacji, aby upewnić się, że wszystko działa zgodnie z oczekiwaniami.
- Zmniejsz liczbę połączeń: jeśli to możliwe, spróbuj zoptymalizować przepustowość połączenia. Częste, małe żądania REST mogą być bardziej kosztowne niż pojedyncze, ciągłe połączenie przy użyciu natywnego pakietu SDK. Jeśli używasz interfejsu REST API, rozważ użycie protokołu HTTP keep-alive lub zdarzeń wysyłanych przez serwer, co może obniżyć koszty uzgadniania SSL.
- Używaj biletów sesji TLS: zmniejsz koszty ogólne szyfrowania SSL w przypadku wznawianych połączeń, wydając bilety sesji TLS. Jest to szczególnie przydatne, jeśli potrzebujesz częstych, bezpiecznych połączeń z bazą danych.
- Zapytania dotyczące indeksów: indeksowanie danych zmniejsza łączną przepustowość używaną na potrzeby zapytań, co przynosi podwójną korzyść: obniża koszty i zwiększa wydajność bazy danych. Użyj narzędzia do profilowania, aby znaleźć nieindeksowane zapytania w bazie danych.
- Zoptymalizuj detektory: dodaj zapytania, aby ograniczyć dane zwracane przez operacje nasłuchiwania, i używaj detektorów, które pobierają tylko aktualizacje danych – na przykład
on()zamiastonce(). Dodatkowo umieść detektory jak najdalej na ścieżce, aby ograniczyć ilość synchronizowanych danych. - Obniż koszty przechowywania danych: okresowo uruchamiaj zadania czyszczenia i ograniczaj ilość zduplikowanych danych w bazie danych.
- Używaj reguł: zapobiegaj potencjalnie kosztownym, nieautoryzowanym operacjom na 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. To nie jest pełna lista sprawdzonych metod. Więcej porad i wskazówek od ekspertów Firebase znajdziesz na naszym kanale Slack lub w Stack Overflow.