Tìm hiểu về việc thanh toán cho cơ sở dữ liệu theo thời gian thực
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Firebase tính phí cho dữ liệu mà bạn lưu trữ trong cơ sở dữ liệu và tất cả lưu lượng truy cập mạng đi ở lớp phiên (lớp 5) của mô hình OSI. Bộ nhớ được tính phí 5 USD cho mỗi GB/tháng và được đánh giá hằng ngày. Vị trí của cơ sở dữ liệu không ảnh hưởng đến việc thanh toán. Lưu lượng truy cập đi bao gồm chi phí kết nối và mã hoá từ tất cả các thao tác trên cơ sở dữ liệu và dữ liệu được tải xuống thông qua các lượt đọc cơ sở dữ liệu. Cả hoạt động đọc và ghi cơ sở dữ liệu đều có thể dẫn đến chi phí kết nối trong hoá đơn của bạn. Tất cả lưu lượng truy cập đến và đi từ cơ sở dữ liệu của bạn, bao gồm cả các thao tác bị từ chối theo quy tắc bảo mật, đều dẫn đến chi phí có thể tính phí.
Sau đây là một số ví dụ phổ biến về lưu lượng truy cập có tính phí:
Dữ liệu đã tải xuống: Khi các ứng dụng nhận dữ liệu từ cơ sở dữ liệu của bạn, Firebase sẽ tính phí cho dữ liệu đã tải xuống. Thông thường, đây là phần lớn chi phí băng thông của bạn, nhưng đó không phải là yếu tố duy nhất trong hoá đơn.
Chi phí giao thức: Cần có thêm lưu lượng truy cập giữa máy chủ và các ứng dụng để thiết lập và duy trì một phiên. Tuỳ thuộc vào giao thức cơ bản, lưu lượng truy cập này có thể bao gồm: chi phí giao thức theo thời gian thực của Cơ sở dữ liệu theo thời gian thực của Firebase, chi phí WebSocket và chi phí tiêu đề HTTP. Mỗi khi một kết nối được thiết lập, chi phí chung này, kết hợp với mọi chi phí chung về mã hoá SSL, sẽ góp phần vào chi phí kết nối. Mặc dù đây không phải là băng thông lớn cho một yêu cầu duy nhất, nhưng nó có thể chiếm một phần đáng kể trong hoá đơn của bạn nếu tải trọng của bạn rất nhỏ hoặc bạn thực hiện các kết nối ngắn thường xuyên.
Chi phí mã hoá SSL: Có một chi phí liên quan đến chi phí mã hoá SSL cần thiết cho các kết nối an toàn. Trung bình, chi phí này là khoảng 3, 5 KB cho lần bắt tay ban đầu và khoảng hàng chục byte cho tiêu đề bản ghi TLS trên mỗi thông báo đi. Đối với hầu hết các ứng dụng, đây là một tỷ lệ nhỏ trong hoá đơn của bạn. Tuy nhiên, tỷ lệ này có thể tăng lên đáng kể nếu trường hợp cụ thể của bạn yêu cầu nhiều lần bắt tay SSL. Ví dụ: những thiết bị không hỗ trợ vé phiên TLS có thể yêu cầu số lượng lớn các lần bắt tay kết nối SSL.
FirebaseDữ liệu bảng điều khiển: Mặc dù đây thường không phải là một phần đáng kể trong chi phí Realtime Database, nhưng Firebase tính phí cho dữ liệu mà bạn đọc và ghi từ bảng điều khiển Firebase.
Ước tính mức sử dụng tính phí
Để xem các kết nối Realtime Database hiện tại và mức sử dụng dữ liệu, hãy kiểm tra thẻ Mức sử dụng trong bảng điều khiển Firebase. Bạn có thể kiểm tra mức sử dụng trong kỳ thanh toán hiện tại, 30 ngày qua hoặc 24 giờ qua.
Firebase cho biết số liệu thống kê về mức sử dụng cho những chỉ số sau:
Số lượng kết nối: Số lượng kết nối đồng thời, hiện đang mở và theo thời gian thực đến cơ sở dữ liệu của bạn. Điều này bao gồm các kết nối theo thời gian thực sau đây: WebSocket, long polling và các sự kiện do máy chủ HTML gửi. Số liệu này không bao gồm các yêu cầu RESTful.
Bộ nhớ: Lượng dữ liệu được lưu trữ trong cơ sở dữ liệu của bạn. Thao tác này không bao gồm dịch vụ lưu trữ Firebase hoặc dữ liệu được lưu trữ thông qua các sản phẩm khác của Firebase.
Tải xuống: Tất cả các byte được tải xuống từ cơ sở dữ liệu của bạn, bao gồm cả giao thức và chi phí mã hoá.
Tải: Biểu đồ này cho biết mức sử dụng cơ sở dữ liệu của bạn, xử lý các yêu cầu trong khoảng thời gian 1 phút nhất định. Bạn có thể gặp phải vấn đề về hiệu suất khi cơ sở dữ liệu của bạn gần đạt đến 100%.
Tối ưu hoá mức sử dụng
Bạn có thể áp dụng một số phương pháp hay nhất để tối ưu hoá mức sử dụng cơ sở dữ liệu và chi phí băng thông.
Sử dụng các SDK gốc: Bất cứ khi nào có thể, hãy sử dụng các SDK tương ứng với nền tảng của ứng dụng thay vì REST API. Các SDK duy trì kết nối mở, giảm chi phí mã hoá SSL thường tăng lên khi dùng REST API.
Kiểm tra lỗi: Nếu chi phí băng thông cao hơn dự kiến, hãy xác minh rằng ứng dụng của bạn không đồng bộ hoá nhiều dữ liệu hơn hoặc đồng bộ hoá thường xuyên hơn so với dự định ban đầu. Để xác định chính xác vấn đề, hãy sử dụng công cụ phân tích tài nguyên để đo lường các thao tác đọc và bật tính năng ghi nhật ký gỡ lỗi trong SDK Android, Objective-C và Web. Kiểm tra các quy trình đồng bộ hoá và chạy nền trong ứng dụng để đảm bảo mọi thứ hoạt động như bạn dự định.
Giảm số lượng kết nối: Nếu có thể, hãy cố gắng tối ưu hoá băng thông kết nối. Các yêu cầu REST thường xuyên, nhỏ có thể tốn kém hơn so với một kết nối liên tục duy nhất bằng cách sử dụng SDK gốc. Nếu bạn sử dụng REST API, hãy cân nhắc sử dụng tính năng duy trì kết nối HTTP hoặc sự kiện do máy chủ gửi. Các tính năng này có thể giảm chi phí từ các lần bắt tay SSL.
Sử dụng vé phiên TLS: Giảm chi phí chung cho hoạt động mã hoá SSL trên các kết nối được tiếp tục bằng cách phát hành vé phiên TLS.
Điều này đặc biệt hữu ích nếu bạn cần kết nối thường xuyên và an toàn với cơ sở dữ liệu.
Truy vấn chỉ mục:Việc lập chỉ mục dữ liệu giúp giảm tổng băng thông bạn sử dụng cho các truy vấn, mang lại lợi ích kép là giảm chi phí và tăng hiệu suất của cơ sở dữ liệu. Sử dụng công cụ lập hồ sơ để tìm các truy vấn chưa được lập chỉ mục trong cơ sở dữ liệu của bạn.
Tối ưu hoá trình nghe: Thêm các truy vấn để giới hạn dữ liệu mà các thao tác nghe trả về và sử dụng trình nghe chỉ tải các bản cập nhật xuống dữ liệu – ví dụ: on() thay vì once(). Ngoài ra, hãy đặt các trình nghe của bạn càng xa đường dẫn càng tốt để giới hạn lượng dữ liệu mà chúng đồng bộ hoá.
Giảm chi phí lưu trữ: Chạy các tác vụ dọn dẹp định kỳ và giảm mọi dữ liệu trùng lặp trong cơ sở dữ liệu của bạn.
Sử dụng quy tắc: Ngăn chặn mọi thao tác trái phép, có khả năng tốn kém trên cơ sở dữ liệu của bạn. Ví dụ: việc sử dụng Firebase Realtime Database Security Rules có thể tránh trường hợp người dùng độc hại liên tục tải toàn bộ cơ sở dữ liệu của bạn xuống.
Tìm hiểu thêm về cách sử dụng Quy tắc cơ sở dữ liệu theo thời gian thực của Firebase.
Kế hoạch tối ưu hoá tốt nhất cho ứng dụng của bạn sẽ phụ thuộc vào trường hợp sử dụng cụ thể của bạn.
Mặc dù đây không phải là danh sách đầy đủ các phương pháp hay nhất, nhưng bạn có thể tìm thêm lời khuyên và mẹo từ các chuyên gia Firebase trên kênh Slack của chúng tôi hoặc trên Stack Overflow.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 2025-09-05 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)."]]
