Firebase tính phí cho dữ liệu 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 tại lớp phiên (lớp 5) của mô hình OSI. Dung lượng lưu trữ được tính phí với mức giá 5 USD cho mỗi GB/tháng, đượ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 hao tổn kết nối và mã hoá từ tất cả các hoạt động cơ sở dữ liệu và dữ liệu được tải xuống thông qua hoạt động đọ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 trên 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 khách hàng nhận dữ liệu từ cơ sở dữ liệu của bạn, Firebase sẽ tính phí dữ liệu đã tải xuống. Thông thường, đây là phần lớn chi phí băng thông, nhưng không phải là yếu tố duy nhất trong hoá đơn của bạn.
- Mức hao tổn giao thức: Cần có một số lưu lượng truy cập bổ sung giữa máy chủ và ứng dụng để thiết lập và duy trì 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: hao tổn 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, hao tổn WebSocket và hao tổn tiêu đề HTTP. Mỗi khi một kết nối được thiết lập, chi phí này, kết hợp với mọi chi phí mã hoá SSL, sẽ góp phần làm tăng chi phí kết nối. Mặc dù đây không phải là nhiều băng thông cho một yêu cầu, nhưng nó có thể là 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ường xuyên tạo các kết nối ngắ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 bảo mật. Trung bình, chi phí này 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ư gửi đi. Đối với hầu hết ứ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ể trở thành một tỷ lệ lớn nếu trường hợp cụ thể của bạn yêu cầu nhiều lượt bắt tay SSL. Ví dụ: các 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ượt bắt tay kết nối SSL.
- Dữ liệu trong bảng điều khiển Firebase: 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 sẽ tính phí 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 và mức sử dụng dữ liệu hiện tại, hãy kiểm tra thẻ Usage (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 khoảng thời gian thanh toán hiện tại, 30 ngày qua hoặc 24 giờ qua.
Firebase cho thấy số liệu thống kê về mức sử dụng cho các chỉ số sau:
- Kết nối: Số lượng kết nối đồng thời, hiện đang mở, theo thời gian thực với 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: WebSocket, thăm dò ý kiến dài và sự kiện do máy chủ HTML gửi. Báo cáo 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. Điều 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 Firebase khác.
- 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ả chi phí giao thức và mã hoá.
- Tải: Biểu đồ này cho biết lượng cơ sở dữ liệu đang được sử dụng, xử lý các yêu cầu trong một khoảng thời gian nhất định là 1 phút. Bạn có thể gặp vấn đề về hiệu suất khi cơ sở dữ liệu của bạn đạt gần 100%.
Tối ưu hoá việ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 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ì API REST. Các SDK duy trì các kết nối mở, giảm chi phí mã hoá SSL thường tích luỹ với API REST.
- Kiểm tra lỗi: Nếu chi phí băng thông của bạn 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ự kiến ban đầu. Để xác định vấn đề, hãy dùng công cụ trình phân tích tài nguyên để đo lường hoạt động đọc và bật tính năng ghi nhật ký gỡ lỗi trong SDK Android, Target-C và Web. Kiểm tra quy trình đồng bộ hoá và chạy ở chế độ nền trong ứng dụng của bạn để đảm bảo mọi thứ đang hoạt động như dự kiến.
- 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 nhỏ, thường xuyên có thể tốn kém hơn so với một kết nối liên tục bằng SDK gốc. Nếu bạn sử dụng API REST, 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. Điều này có thể làm giảm chi phí từ các lượt bắt tay SSL.
- Sử dụng vé phiên TLS: Giảm chi phí hao tổn khi mã hoá SSL trên các kết nối 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 lập chỉ mục: Việc lập chỉ mục dữ liệu giúp giảm tổng băng thông mà bạn sử dụng cho các truy vấn. Điều này mang lại lợi ích gấp đôi 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ụ phân tích tài nguyên để tìm các truy vấn chưa được lập chỉ mục trong cơ sở dữ liệu.
- Tối ưu hoá trình nghe: Thêm 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 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à trình nghe đồng bộ hoá. - Giảm chi phí lưu trữ: Chạy các công việc dọn dẹp định kỳ và giảm mọi dữ liệu trùng lặp trong cơ sở dữ liệu.
- Sử dụng quy tắc: Ngăn mọi thao tác trái phép, có thể 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 được trường hợp người dùng độc hại tải toàn bộ cơ sở dữ liệu của bạn xuống nhiều lần. Tìm hiểu thêm về cách sử dụng Quy tắc cơ sở dữ liệu thời gian thực Firebase.
Kế hoạch tối ưu hoá tốt nhất cho ứng dụng của bạn phụ thuộc vào trường hợp sử dụng cụ thể. 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ấy thêm lời khuyên và mẹo từ các chuyên gia Firebase trên kênh Slack hoặc trên Stack Overflow.