Firebase nalicza opłaty za dane, które przechowujesz w bazie danych, oraz za cały wychodzący ruch sieciowy w warstwie sesji (w warstwie 5) modelu OSI. Opłaty za miejsce na dane wynoszą 5 USD za każdy GB na miesiąc. Lokalizacja bazy danych nie ma wpływu na płatności. Ruch wychodzący obejmuje narzuty związane z połączeniami i szyfrowaniem ze wszystkich operacji na bazach danych oraz dane pobierane przy użyciu odczytów bazy danych. Zarówno odczyty, jak i zapisy bazy danych mogą powodować naliczanie opłat za połączenia. Cały ruch do i z Twojej bazy danych, w tym operacje odrzucone przez reguły zabezpieczeń, prowadzi do naliczanych kosztów.
Oto kilka typowych przykładów płatnego ruchu:
- Dane pobrane: gdy klienty pobierają dane z bazy danych, Firebase nalicza opłaty za pobrane dane. Zwykle stanowi ona większość kosztów przepustowości, ale nie jest jedynym czynnikiem, który wpływa na wysokość rachunku.
- Narzut protokołu: do utworzenia i utrzymania sesji konieczny jest dodatkowy ruch między serwerem a klientami. W zależności od bazowego protokołu ruch ten może obejmować: narzut protokołu do Bazy danych czasu rzeczywistego Firebase, narzut WebSocket i narzut nagłówka HTTP. Przy każdorazowym ustanowieniu połączenia ten narzut, w połączeniu z narzutem na szyfrowanie SSL, zwiększa koszty połączenia. Chociaż nie jest to dużo przepustowości w przypadku pojedynczego żądania, może to stanowić znaczącą część rachunku, jeśli masz małe ładunki lub często nawiązujesz krótkie połączenia.
- Narzuty związane z szyfrowaniem SSL: związane z szyfrowaniem SSL wiążą się z kosztami. Koszt ten wynosi średnio około 3,5 KB w przypadku początkowego uzgadniania połączenia i około dziesiątek bajtów w przypadku nagłówków rekordów TLS każdej wiadomości wychodzącej. W przypadku większości aplikacji jest to niewielki procent rachunku. Może to być jednak duży odsetek, jeśli Twój przypadek wymaga wielu uzgadniania połączenia SSL. Na przykład urządzenia, które nie obsługują zgłoszeń na sesję TLS, mogą wymagać dużej liczby uzgadniania połączenia SSL.
- Dane konsoli Firebase: choć zwykle nie jest to znacząca część kosztów Bazy danych czasu rzeczywistego, Firebase nalicza opłaty za dane, które odczytujesz i zapisujesz w konsoli Firebase.
Oszacuj płatne wykorzystanie
Aby sprawdzić bieżące połączenia z Bazą danych czasu rzeczywistego i wykorzystanie danych, otwórz kartę Użycie w konsoli Firebase. Możesz wyświetlić wykorzystanie w bieżącym okresie rozliczeniowym, ostatnich 30 dniach lub ostatnich 24 godzinach.
Firebase wyświetla statystyki użytkowania dla następujących danych:
- Połączenia: liczba jednoczesnych, obecnie otwartych połączeń w czasie rzeczywistym z bazą danych. Obejmuje to następujące połączenia w czasie rzeczywistym: WebSocket, długie odpytania i zdarzenia wysłane przez serwer HTML. Nie uwzględnia ona żądań REST.
- Miejsce na dane:ilość danych przechowywanych w bazie danych. Nie obejmuje to hostingu Firebase ani danych przechowywanych przy użyciu innych usług Firebase.
- Pobrane: wszystkie bajty pobrane z Twojej bazy danych, z uwzględnieniem narzutów protokołu i szyfrowania.
- Obciążenie: ten wykres pokazuje, jaka część bazy danych jest używana podczas przetwarzania żądań w danym 1-minutowym przedziale czasu. Gdy baza danych zbliża się do 100%, mogą wystąpić problemy z wydajnością.
Optymalizowanie wykorzystania
Istnieje kilka sprawdzonych metod, które możesz zastosować, aby zoptymalizować wykorzystanie bazy danych i koszty przepustowości.
- Korzystaj z natywnych pakietów SDK: w miarę możliwości używaj pakietów SDK odpowiadających platformie Twojej aplikacji zamiast interfejsu API REST. Pakiety SDK utrzymują otwarte połączenia, co zmniejsza koszty szyfrowania SSL, które zazwyczaj sumują się z interfejsem API REST.
- Sprawdź, czy nie występują błędy: jeśli koszty przepustowości są nieoczekiwanie wysokie, sprawdź, czy aplikacja nie synchronizuje więcej danych ani nie synchronizuje więcej, niż zakładano. Aby wykryć problemy, użyj narzędzia do profilowania do pomiaru operacji odczytu i włącz logowanie debugowania w pakietach SDK Androida, Objective-C i internetowych. Sprawdź procesy w tle i synchronizacje w aplikacji, aby upewnić się, że wszystko działa prawidłowo.
- 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 korzystające z natywnego pakietu SDK. Jeśli używasz interfejsu API REST, rozważ zastosowanie zdarzeń utrzymywania aktywności HTTP lub zdarzeń wysyłanych przez serwer, które mogą ograniczyć koszty uzgadniania połączenia SSL.
- Używaj zgłoszeń na sesję TLS:zmniejsz koszty związane z szyfrowaniem SSL w przypadku wznawianych połączeń, wysyłając bilety na sesję TLS. Jest to szczególnie przydatne, jeśli potrzebujesz częstych, bezpiecznych połączeń z bazą danych.
- Zapytania dotyczące indeksowania: indeksowanie danych zmniejsza łączną przepustowość wykorzystywanej do obsługi zapytań. Podwójną zaletą jest obniżenie kosztów i zwiększenie wydajności bazy danych. Użyj narzędzia do profilowania, aby znaleźć niezindeksowane zapytania w bazie danych.
- Zoptymalizuj działania detektorów: dodaj zapytania, aby ograniczyć dane zwracane przez operacje nasłuchiwania i używać detektorów, które pobierają tylko aktualizacje danych – np.
on()zamiastonce(). Dodatkowo umieść detektory jak najdalej na ścieżce, by ograniczyć ilość synchronizowanych danych. - Obniż koszty przechowywania danych: uruchamiaj okresowe zadania czyszczenia i ograniczaj zduplikowane dane w bazie danych.
- Używaj reguł: zapobiegaj potencjalnie kosztownym, nieautoryzowanym działaniom w bazie danych. Na przykład stosowanie reguł zabezpieczeń Bazy danych czasu rzeczywistego Firebase pozwala uniknąć sytuacji, w której szkodliwy 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 na stronie Stack Overflow.