Omówienie płatności w Bazie danych czasu rzeczywistego
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
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 każdy 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: szyfrowanie SSL niezbędne do nawiązywania bezpiecznych połączeń wiąże się z pewnym obciążeniem. Ś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 wymaganych jest wiele uzgodnień SSL, może to być 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.
Firebase wyświetla statystyki użytkowania dotyczące tych danych:
Połączenia: liczba jednoczesnych, obecnie 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
Aby zoptymalizować wykorzystanie bazy danych i koszty przepustowości, możesz zastosować kilka sprawdzonych metod.
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 rejestrowanie 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.
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() zamiast once(). Dodatkowo umieść odbiorców jak najdalej na ścieżce, aby ograniczyć ilość synchronizowanych przez nich danych.
Obniż koszty przechowywania: okresowo uruchamiaj zadania czyszczenia i usuwaj z bazy danych zduplikowane dane.
Używaj reguł: zapobiegaj potencjalnie kosztownym i 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.
[null,null,["Ostatnia aktualizacja: 2025-08-29 UTC."],[],[],null,["\u003cbr /\u003e\n\nFirebase bills for the data you store in your database and all outbound network\ntraffic at the session layer (layer 5) of the OSI model. Storage is billed at\n$5 for each GB/month, evaluated daily. Billing is not affected by the location\nof your database. Outbound traffic includes connection and encryption overhead\nfrom all database operations and data downloaded through database reads. Both\ndatabase reads and writes can lead to connection costs on your bill. All\ntraffic to and from your database, including operations denied by security\nrules, leads to billable costs.\n\nSome common examples of billed traffic include:\n\n- **Data downloaded:** When clients get data from your database, Firebase charges for the downloaded data. Typically, this makes up the bulk of your bandwidth costs, but it isn't the only factor in your bill.\n- **Protocol overhead:** Some additional traffic between the server and clients is necessary to establish and maintain a session. Depending on the underlying protocol, this traffic might include: Firebase Realtime Database's realtime protocol overhead, WebSocket overhead, and HTTP header overhead. Each time a connection is established, this overhead, combined with any SSL encryption overhead, contributes to the connection costs. Although this isn't a lot of bandwidth for a single request, it can be a substantial part of your bill if your payloads are tiny or you make frequent, short connections.\n- **SSL encryption overhead:** There is a cost associated with the SSL encryption overhead necessary for secure connections. On average, this cost is approximately 3.5KB for the initial handshake, and approximately tens of bytes for TLS record headers on each outgoing message. For most apps, this is a small percentage of your bill. However, this can become a large percentage if your specific case requires a lot of SSL handshakes. For example, devices that don't support [TLS session tickets](https://tools.ietf.org/html/rfc5077) might require large numbers of SSL connection handshakes.\n- **Firebase console data:** Although this isn't usually a significant portion of Realtime Database costs, Firebase charges for data that you read and write from the Firebase console.\n\n| When your project is on the Blaze pricing plan, [**set up budget alerts**](/docs/projects/billing/avoid-surprise-bills#set-up-budget-alert-emails) using the console. You can use the [Blaze plan calculator](/pricing#blaze-calculator) to estimate your monthly costs.\n|\n| Be aware that **budget alerts do *not* cap your usage or\n| charges** --- they are *alerts* about your costs so that you can\n| take action, if needed. For example, you might consider\n| [using\n| budget notifications to programmatically disable Cloud Billing on a\n| project](https://cloud.google.com/billing/docs/how-to/disable-billing-with-notifications).\n\nEstimate your billed usage\n\nTo see your current Realtime Database connections and data usage, check the\n[Usage](https://console.firebase.google.com/project/_/database/usage/current-billing/)\ntab in the Firebase console. You can check usage over the current billing\nperiod, the last 30 days, or the last 24 hours.\n\nFirebase shows usage statistics for the following metrics:\n\n- **Connections:** The number of simultaneous, currently open, realtime connections to your database. This includes the following realtime connections: WebSocket, long polling, and HTML server-sent events. It does not include RESTful requests.\n- **Storage:** How much data is stored in your database. This doesn't include Firebase hosting or data stored through other Firebase products.\n- **Downloads:** All bytes downloaded from your database, including protocol and encryption overhead.\n- **Load:** This graph shows how much of your database is in use, processing requests, over a given 1-minute interval. You might see performance issues as your database approaches 100%.\n\nOptimize usage\n\nThere are a few best practices you can employ to optimize your database usage\nand bandwidth costs.\n\n- **Use the native SDKs:** Whenever possible, use the SDKs that correspond to your app's platform, instead of the REST API. The SDKs maintain open connections, reducing the SSL encryption costs that typically add up with the REST API.\n- **Check for bugs:** If your bandwidth costs are unexpectedly high, verify that your app isn't syncing more data or syncing more often than you originally intended. To pinpoint issues, use the [profiler tool](/docs/database/usage/profile) to measure your read operations and turn on debug logging in the [Android](https://firebase.google.com/docs/reference/android/com/google/firebase/database/Logger), [Objective-C](https://firebase.google.com/docs/reference/ios/firebasecore/api/reference/Enums/FIRLoggerLevel), and [Web](https://firebase.google.com/docs/reference/js/database#enablelogging) SDKs. Check background and sync processes in your app to make sure everything is working as you intended.\n- **Reduce connections:** If possible, try to optimize your connection bandwidth. Frequent, small REST requests can be more costly than a single, continuous connection using the native SDK. If you do use the REST API, consider using an HTTP keep-alive or [server-sent events](/docs/reference/rest/database#section-streaming), which can reduce costs from SSL handshakes.\n- **Use TLS session tickets:** Reduce SSL encryption overhead costs on resumed connections by issuing [TLS session tickets](https://tools.ietf.org/html/rfc5077). This is particularly helpful if you do require frequent, secure connections to the database.\n- **Index queries:** [Indexing your data](/docs/database/security/indexing-data) reduces the total bandwidth you use for queries, which has the double benefit of lowering your costs and increasing your database's performance. Use the profiler tool to [find unindexed queries](/docs/database/usage/profile#unindexed_queries) in your database.\n- **Optimize your listeners:** Add queries to limit the data that your listen operations return and use listeners that only download updates to data --- for example, `on()` instead of `once()`. Additionally, place your listeners as far down the path as you can to limit the amount of data they sync.\n- **Reduce storage costs:** Run periodic cleanup jobs and reduce any duplicate data in your database.\n- **Use Rules:** Prevent any potentially costly, unauthorized operations on your database. For example, using Firebase Realtime Database Security Rules could avoid a scenario where a malicious user repeatedly downloads your entire database. Learn more about [using Firebase Realtime Database Rules](/docs/database/security).\n\n| **Note about the profiler tool:** The profiler tool doesn't account for network traffic. It only records an estimate of the application data sent in responses. The profiler tool is intended to give you an overall picture of your database's performance, to help you monitor operations and troubleshoot issues, **not to estimate billing** . To learn more, see [the profiler tool documentation](/docs/database/usage/profile).\n\nThe best optimization plan for your app depends on your particular use case.\nWhile this isn't an exhaustive list of best practices, you can find\nmore advice and tips from the Firebase experts on our\n[Slack channel](https://firebase.community/)\nor on [Stack Overflow](https://stackoverflow.com/questions/tagged/firebase)."]]
