Firebase nalicza opłaty za dane, które przechowujesz w bazie danych, oraz za wszystkie sieci wychodzące w warstwie sesji (w warstwie 5) modelu OSI. Opłata za miejsce na dane: 5 USD za każdy GB/miesiąc, oceniana codziennie. Lokalizacja nie ma wpływu na płatności Twojej bazy danych. Ruch wychodzący obejmuje narzuty związane z połączeniami i szyfrowaniem ze wszystkich operacji na bazie danych i danych pobranych przy użyciu odczytów bazy danych. Obie opcje odczyty i zapisy bazy danych mogą powodować naliczanie opłat za połączenie. Wszystkie ruch do i z bazy danych, z uwzględnieniem operacji odrzuconych ze względu na zabezpieczenia prowadzi do naliczanych kosztów.
Oto kilka typowych przykładów płatnego ruchu:
- Pobrane dane: gdy klienci pobierają dane z Twojej bazy danych, Firebase pobiera opłatę za pobrane dane. Zazwyczaj jest to większa część ale nie jest to jedyny czynnik, który musisz wziąć pod uwagę.
- Narzut protokołu: część dodatkowego ruchu między serwerem a klientami. jest niezbędna do utworzenia i utrzymania sesji. W zależności od podstawowego protokołu ten ruch może obejmować: opóźnienia związane z protokołem czasu rzeczywistego Firebase Realtime Database, opóźnienia związane z WebSocket i opóźnienia związane z nagłówkiem HTTP. Za każdym razem, gdy nawiązywane jest połączenie, ten koszt, w połączeniu z kosztem szyfrowania SSL, zwiększa koszty połączenia. To niewiele dla pojedynczego żądania może stanowić znaczną część rachunku jeśli Twoje ładunki są małe lub nawiązujesz częste, krótkie połączenia.
- Narzut szyfrowania SSL: korzystanie z SSL wiąże się z pewnymi kosztami. nakładu szyfrowania wymaganych do obsługi bezpiecznych połączeń. Średni koszt to około 3, 5 KB podczas początkowego uzgadniania połączenia i około dziesiątki bajtów w nagłówkach rekordów TLS w każdej wiadomości wychodzącej. W przypadku większości aplikacji jest to 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 może wymagać dużej liczby uzgadniania połączenia SSL.
- Dane konsoli Firebase: chociaż zwykle nie są to znaczące części kosztów Realtime Database, Firebase pobiera opłaty za odczytywane dane i z konsoli Firebase.
Oszacuj płatne wykorzystanie
Aby sprawdzić bieżące połączenia i użycie danych w usłudze Realtime Database, otwórz Wykorzystanie w konsoli Firebase. Możesz sprawdzić wykorzystanie w ramach bieżącego rozliczenia ostatnich 30 dni lub ostatnich 24 godzin.
Firebase wyświetla statystyki użytkowania dla następujących danych:
- Połączenia: liczba jednoczesnych, aktualnie otwartych połączeń w czasie rzeczywistym. połączenia z bazą danych. Obejmuje to te dane w czasie rzeczywistym połączeń: WebSocket, długie odpytania i zdarzenia wysyłane przez serwer HTML. Tak nie uwzględniaj żądań REST.
- Miejsce na dane:ilość danych przechowywanych w bazie danych. Nie obejmuje to: Hosting lub dane przechowywane w Firebase w innych usługach Firebase.
- Pobrane: wszystkie bajty pobrane z bazy danych, w tym protokół. i szyfrowania.
- Obciążenie: ten wykres pokazuje, jaka część bazy danych jest używana do przetwarzania żądań w danym 1-minutowym interwale. Mogą występować problemy z wydajnością a baza danych zbliża się do 100%.
Optymalizowanie 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 odpowiadających platformy aplikacji, a nie interfejsu API REST. Pakiety SDK utrzymują otwarte połączenia, co zmniejsza koszty szyfrowania SSL, które zwykle kumulują się w przypadku interfejsu API REST.
- Sprawdź, czy nie występują błędy: jeśli koszty przepustowości są nieoczekiwanie wysokie, sprawdź, że aplikacja nie synchronizuje więcej danych ani nie synchronizuje się częściej niż pierwotnie zamierzone. Aby wykryć problemy, użyj narzędzia do profilowania, mierz operacje odczytu i włącz logowanie debugowania Android Objective-C i Sieć Pakiety SDK. Sprawdź procesy w tle i synchronizacji w aplikacji, aby upewnić się, wszystko działa zgodnie z oczekiwaniami.
- Zmniejsz liczbę połączeń: jeśli to możliwe, spróbuj zoptymalizować przepustowość połączenia. Częste, niewielkie żądania REST mogą być droższe niż pojedyncze, i ciągłe połączenie za pomocą natywnego pakietu SDK. Jeśli używasz interfejsu API REST, warto użyć protokołu utrzymywania aktywności HTTP lub zdarzenia wysyłane przez serwer, co może obniżyć koszty uzgadniania połączenia SSL.
- Użyj zgłoszeń sesji TLS:zmniejsz koszty związane z szyfrowaniem SSL po wznowieniu działania przez Zgłoszenia sesji TLS. Jest to szczególnie przydatne, jeśli musisz często i bezpiecznie połączyć się z innymi osobami do bazy danych.
- Zapytania dotyczące indeksowania: indeksowanie danych zmniejsza całkowitą przepustowość wykorzystywaną do obsługi zapytań, co ma podwójną korzyść obniżenia kosztów i zwiększenia wydajności baz danych. Użyj za pomocą narzędzia do profilowania, aby znaleźć niezindeksowane zapytania w bazie danych.
- Zoptymalizuj słuchaczy: dodaj zapytania, aby ograniczyć ilość danych słuchanych przez Ciebie.
operacji zwracają i używają detektorów, które pobierają tylko aktualizacje danych – przez
przykład:
on()zamiastonce(). Dodatkowo umieść słuchaczy jako: jak najdalej na ścieżce, aby ograniczyć ilość synchronizowanych danych. - Zmniejsz koszty przechowywania: uruchamiaj okresowe zadania czyszczenia i ogranicz liczbę duplikatów. w swojej bazie danych.
- Używaj reguł: zapobiegaj potencjalnie kosztownym, nieautoryzowanym działaniom w bazie danych. Użycie właściwości Firebase Realtime Database Security Rules może na przykład wyeliminować scenariusz gdy szkodliwy 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. Nie jest to wyczerpująca lista sprawdzonych metod, ale znajdziesz tu więcej porad i wskazówek od ekspertów Firebase w naszym Kanał na Slacku lub na stronie Stack Overflow.