Có một số cách để cải thiện hiệu suất Firebase Realtime Database trong ứng dụng của bạn. Để biết những việc bạn có thể làm để tối ưu hoá hiệu suất Realtime Database, hãy thu thập dữ liệu thông qua các công cụ giám sát Realtime Database khác nhau, sau đó thực hiện các thay đổi cho ứng dụng hoặc sử dụng Realtime Database cho phù hợp.
Theo dõi hiệu suất Realtime Database
Bạn có thể thu thập dữ liệu về hiệu suất của Realtime Database thông qua một số công cụ khác nhau, tuỳ thuộc vào mức độ chi tiết mà bạn cần:
- Thông tin tổng quan cấp cao: Sử dụng công cụ lập hồ sơ để xem danh sách các truy vấn chưa được lập chỉ mục và thông tin tổng quan theo thời gian thực về các thao tác đọc/ghi.
- Ước tính mức sử dụng được tính phí: Sử dụng các chỉ số về mức sử dụng có trong bảng điều khiển Firebase để xem mức sử dụng được tính phí và các chỉ số hiệu suất cấp cao.
- Thông tin chi tiết: Sử dụng Cloud Monitoring để xem thông tin chi tiết hơn về hiệu suất của cơ sở dữ liệu theo thời gian.
Cải thiện hiệu suất theo chỉ số
Sau khi thu thập dữ liệu, hãy khám phá các phương pháp hay nhất và chiến lược sau đây dựa trên lĩnh vực hiệu suất mà bạn muốn cải thiện.
| Tổng quan về các chiến lược cải thiện hiệu suất | ||
|---|---|---|
| Chỉ số | Nội dung mô tả | Các phương pháp hay nhất |
| Tải/Mức sử dụng | Tối ưu hoá lượng dung lượng cơ sở dữ liệu được dùng để xử lý các yêu cầu tại một thời điểm bất kỳ (thể hiện trong chỉ số **Load** hoặc **io/database_load**). |
Tối ưu hoá cấu trúc dữ liệu Phân chia dữ liệu trên nhiều cơ sở dữ liệu Cải thiện hiệu suất của trình nghe Giới hạn số lượt tải xuống bằng các quy tắc dựa trên truy vấn Tối ưu hoá các kết nối |
| Đường kết nối đang hoạt động | Cân bằng số lượng kết nối đang hoạt động đồng thời với cơ sở dữ liệu của bạn để không vượt quá giới hạn 200.000 kết nối. |
Phân chia dữ liệu trên nhiều cơ sở dữ liệu Giảm số lượng kết nối mới |
| Băng thông đi | Nếu số lượt tải xuống từ cơ sở dữ liệu của bạn có vẻ cao hơn mức bạn muốn, thì bạn có thể cải thiện hiệu quả của các thao tác đọc và giảm chi phí mã hoá. |
Tối ưu hoá các kết nối Tối ưu hoá cấu trúc dữ liệu Giới hạn số lượt tải xuống bằng các quy tắc dựa trên truy vấn Tái sử dụng các phiên SSL Cải thiện hiệu quả của trình nghe Hạn chế quyền truy cập vào dữ liệu |
| Bộ nhớ | Đảm bảo bạn không lưu trữ dữ liệu không dùng đến hoặc cân bằng dữ liệu đã lưu trữ trên các cơ sở dữ liệu và/hoặc sản phẩm Firebase khác để không vượt quá hạn mức. |
Dọn dẹp dữ liệu không dùng đến Tối ưu hoá cấu trúc dữ liệu Phân chia dữ liệu trên nhiều cơ sở dữ liệu Sử dụng Cloud Storage for Firebase |
Tối ưu hoá các mối kết nối
Các yêu cầu RESTful như GET và PUT vẫn cần có kết nối, mặc dù kết nối đó chỉ tồn tại trong thời gian ngắn. Những kết nối thường xuyên và ngắn hạn này có thể làm tăng đáng kể chi phí kết nối, mức tải cơ sở dữ liệu và băng thông đi so với các kết nối đang hoạt động theo thời gian thực với cơ sở dữ liệu của bạn.
Bất cứ khi nào có thể, hãy sử dụng các SDK gốc cho 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 và tải cơ sở dữ liệu có thể tăng lên khi dùng REST API.
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 để duy trì kết nối đang mở hoặc sử dụng sự kiện do máy chủ gửi. Tính năng này có thể giảm chi phí từ các lần bắt tay SSL.
Phân mảnh dữ liệu trên nhiều cơ sở dữ liệu
Việc phân chia dữ liệu trên nhiều thực thể Realtime Database (còn gọi là phân đoạn cơ sở dữ liệu) mang lại 3 lợi ích:
- Tăng tổng số kết nối đồng thời, đang hoạt động được phép trên ứng dụng của bạn bằng cách chia chúng trên các phiên bản cơ sở dữ liệu.
- Cân bằng tải trên các thực thể cơ sở dữ liệu.
- Nếu bạn có các nhóm người dùng độc lập chỉ cần truy cập vào các tập dữ liệu rời rạc, hãy sử dụng các phiên bản cơ sở dữ liệu khác nhau để có thông lượng cao hơn và độ trễ thấp hơn.
Nếu đang sử dụng gói giá Linh hoạt, bạn có thể tạo nhiều phiên bản cơ sở dữ liệu trong cùng một dự án Firebase, tận dụng phương thức xác thực người dùng chung trên các phiên bản cơ sở dữ liệu.
Tìm hiểu thêm về cách thức và thời điểm phân chia dữ liệu.
Xây dựng cấu trúc dữ liệu hiệu quả
Vì Realtime Database truy xuất dữ liệu từ các nút con của một đường dẫn cũng như đường dẫn đó, nên bạn nên giữ cho cấu trúc dữ liệu của mình càng đơn giản càng tốt. Bằng cách này, bạn có thể truy xuất có chọn lọc dữ liệu mình cần mà không cần tải dữ liệu không cần thiết xuống máy khách.
Cụ thể, hãy cân nhắc các thao tác ghi và xoá khi bạn cấu trúc dữ liệu. Ví dụ: các đường dẫn có hàng nghìn lá có thể tốn nhiều chi phí để xoá. Việc chia các đường dẫn này thành các đường dẫn có nhiều cây con và ít nút lá hơn trên mỗi nút có thể tăng tốc độ xoá.
Ngoài ra, mỗi thao tác ghi có thể chiếm 0,1% tổng mức sử dụng cơ sở dữ liệu của bạn.
Cấu trúc dữ liệu theo cách cho phép bạn ghi hàng loạt vào một thao tác duy nhất dưới dạng các bản cập nhật nhiều đường dẫn thông qua các phương thức update() trong SDK hoặc các yêu cầu PATCH RESTful.
Để tối ưu hoá cấu trúc dữ liệu và cải thiện hiệu suất, hãy làm theo các phương pháp hay nhất cho cấu trúc dữ liệu.
Ngăn chặn hành vi truy cập trái phép
Ngăn chặn các thao tác trái phép trên cơ sở dữ liệu của bạn bằng Realtime Database Security Rules. Ví dụ: việc sử dụng các quy tắc 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.
Sử dụng quy tắc dựa trên truy vấn để giới hạn lượt tải xuống
Realtime Database Security Rules hạn chế quyền truy cập vào dữ liệu trong cơ sở dữ liệu của bạn, nhưng chúng cũng có thể đóng vai trò là giới hạn đối với dữ liệu được trả về thông qua các thao tác đọc. Khi bạn sử dụng các quy tắc dựa trên truy vấn, như được xác định bằng các biểu thức query. như query.limitToFirst, các truy vấn chỉ truy xuất dữ liệu bị ràng buộc bởi quy tắc.
Ví dụ: quy tắc sau đây giới hạn quyền đọc chỉ đối với 1.000 kết quả đầu tiên của một truy vấn, theo thứ tự ưu tiên:
messages: {
".read": "query.orderByKey &&
query.limitToFirst <= 1000"
}
// Example query:
db.ref("messages").limitToFirst(1000)
.orderByKey("value")
Tìm hiểu thêm về Realtime Database Security Rules.
Truy vấn chỉ mụ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 mỗi truy vấn mà ứng dụng chạy.
Sử dụng lại các phiên SSL
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 thường xuyên kết nối an toàn với cơ sở dữ liệu.
Cải thiện hiệu quả của người nghe
Đặ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á. Các trình nghe phải ở gần dữ liệu mà bạn muốn chúng nhận được. Đừng theo dõi ở thư mục gốc của cơ sở dữ liệu, vì điều đó sẽ dẫn đến việc tải xuống toàn bộ cơ sở dữ liệu của bạn.
Thêm các truy vấn để giới hạn dữ liệu mà các thao tác nghe của bạn trả về và sử dụng các trình nghe chỉ tải bản cập nhật xuống dữ liệu – ví dụ: on() thay vì once(). Hãy dành .once() cho những thao tác thực sự không cần cập nhật dữ liệu.
Ngoài ra, hãy sắp xếp các truy vấn bằng orderByKey() (nếu có thể) để đạt được hiệu suất tốt nhất. Việc sắp xếp bằng orderByChild() có thể chậm hơn từ 6 đến 8 lần và việc sắp xếp bằng orderByValue() có thể rất chậm đối với các tập dữ liệu lớn, vì thao tác này yêu cầu đọc toàn bộ vị trí từ lớp liên tục.
Đồng thời, hãy nhớ thêm trình nghe một cách linh động và xoá chúng khi không còn cần thiết nữa.
Dọn dẹp dữ liệu không dùng đến
Định kỳ xoá mọi dữ liệu trùng lặp hoặc không dùng đến trong cơ sở dữ liệu của bạn. Bạn có thể chạy bản sao lưu để kiểm tra dữ liệu theo cách thủ công hoặc sao lưu định kỳ vào một vùng chứa Google Cloud Storage. Ngoài ra, hãy cân nhắc việc lưu trữ dữ liệu đã lưu trữ thông qua Cloud Storage for Firebase.
Gửi mã có thể mở rộng mà bạn có thể cập nhật
Các ứng dụng được tích hợp vào thiết bị IoT phải có mã có thể mở rộng mà bạn có thể dễ dàng cập nhật. Đảm bảo bạn kiểm thử kỹ lưỡng các trường hợp sử dụng, tính đến những trường hợp mà bạn có thể tăng cơ sở người dùng theo cấp số nhân và tích hợp khả năng triển khai các bản cập nhật cho mã của bạn. Hãy cân nhắc kỹ những thay đổi lớn mà bạn có thể cần thực hiện sau này, chẳng hạn như nếu bạn quyết định phân chia dữ liệu.