Hãy đọc tài liệu này để biết hướng dẫn về cách mở rộng quy mô ứng dụng không máy chủ của bạn vượt quá hàng nghìn thao tác mỗi giây hoặc hàng trăm nghìn người dùng đồng thời. Tài liệu này bao gồm các chủ đề nâng cao để giúp bạn hiểu rõ hệ thống. Nếu bạn mới bắt đầu sử dụng Cloud Firestore, hãy xem hướng dẫn bắt đầu nhanh.
Cloud Firestore và SDK web/di động của Firebase cung cấp một mô hình mạnh mẽ để phát triển các ứng dụng không máy chủ, trong đó mã phía máy khách truy cập trực tiếp vào cơ sở dữ liệu. Các SDK cho phép ứng dụng khách theo dõi thông tin cập nhật về dữ liệu theo thời gian thực. Bạn có thể sử dụng tính năng cập nhật theo thời gian thực để xây dựng các ứng dụng thích ứng mà không cần cơ sở hạ tầng máy chủ. Mặc dù việc thiết lập và chạy một ứng dụng rất dễ dàng, nhưng bạn nên hiểu rõ các quy tắc ràng buộc trong hệ thống tạo nên Cloud Firestore để ứng dụng không máy chủ của bạn có thể mở rộng quy mô và hoạt động hiệu quả khi lưu lượng truy cập tăng lên.
Hãy xem các phần sau để biết lời khuyên về cách mở rộng quy mô ứng dụng.
Chọn vị trí cơ sở dữ liệu gần người dùng
Sơ đồ sau đây minh hoạ cấu trúc của một ứng dụng theo thời gian thực:
Khi một ứng dụng đang chạy trên thiết bị của người dùng (thiết bị di động hoặc web) thiết lập kết nối với Cloud Firestore, kết nối đó sẽ được định tuyến đến một máy chủ giao diện người dùng Cloud Firestore trong cùng khu vực nơi đặt cơ sở dữ liệu của bạn. Ví dụ:
nếu cơ sở dữ liệu của bạn nằm trong us-east1, thì kết nối cũng sẽ chuyển đến một
giao diện người dùng Cloud Firestore cũng nằm trong us-east1. Các kết nối này tồn tại lâu dài và luôn mở cho đến khi ứng dụng đóng một cách rõ ràng. Giao diện người dùng đọc dữ liệu từ hệ thống lưu trữ Cloud Firestore cơ bản.
Khoảng cách giữa vị trí thực của người dùng và vị trí của cơ sở dữ liệu Cloud Firestore ảnh hưởng đến độ trễ mà người dùng gặp phải. Ví dụ: một người dùng ở Ấn Độ có ứng dụng giao tiếp với cơ sở dữ liệu ở khu vực Google Cloud tại Bắc Mỹ có thể thấy trải nghiệm chậm hơn và ứng dụng kém nhanh nhạy hơn so với khi cơ sở dữ liệu nằm ở gần hơn, chẳng hạn như ở Ấn Độ hoặc ở một khu vực khác của Châu Á.
Thiết kế hướng đến độ tin cậy
Các chủ đề sau đây giúp cải thiện hoặc ảnh hưởng đến độ tin cậy của ứng dụng:
Bật chế độ ngoại tuyến
Firebase SDK cung cấp tính năng lưu trữ dữ liệu ngoại tuyến. Nếu ứng dụng trên thiết bị của người dùng không thể kết nối với Cloud Firestore, thì ứng dụng vẫn có thể sử dụng được bằng cách làm việc với dữ liệu được lưu vào bộ nhớ đệm cục bộ. Điều này đảm bảo quyền truy cập dữ liệu ngay cả khi người dùng gặp phải kết nối Internet không ổn định hoặc mất hoàn toàn quyền truy cập trong vài giờ hoặc vài ngày. Để biết thêm thông tin chi tiết về chế độ ngoại tuyến, hãy xem phần Bật dữ liệu ngoại tuyến.
Tìm hiểu về tính năng tự động thử lại
Firebase SDK sẽ đảm nhận việc thử lại các thao tác và thiết lập lại các kết nối bị hỏng. Điều này giúp giải quyết các lỗi tạm thời do khởi động lại máy chủ hoặc các vấn đề về mạng giữa máy khách và cơ sở dữ liệu.
Chọn giữa vị trí theo khu vực và vị trí đa khu vực
Có một số điểm đánh đổi khi lựa chọn giữa vị trí theo khu vực và vị trí đa khu vực. Điểm khác biệt chính là cách sao chép dữ liệu. Điều này đảm bảo tính sẵn sàng của ứng dụng. Phiên bản đa khu vực mang lại độ tin cậy cao hơn và tăng độ bền cho dữ liệu của bạn, nhưng bạn phải đánh đổi bằng chi phí.
Tìm hiểu hệ thống truy vấn theo thời gian thực
Truy vấn theo thời gian thực (còn gọi là trình nghe thông tin tổng quan nhanh) cho phép ứng dụng theo dõi các thay đổi trong cơ sở dữ liệu và nhận thông báo có độ trễ thấp ngay khi dữ liệu thay đổi. Ứng dụng có thể nhận được kết quả tương tự bằng cách định kỳ thăm dò cơ sở dữ liệu để tìm bản cập nhật, nhưng cách này thường chậm hơn, tốn kém hơn và cần nhiều mã hơn. Để biết ví dụ về cách thiết lập và sử dụng truy vấn theo thời gian thực, hãy xem phần Nhận thông tin cập nhật theo thời gian thực. Các phần sau đây trình bày chi tiết về cách hoạt động của trình nghe ảnh chụp nhanh và mô tả một số phương pháp hay nhất để điều chỉnh quy mô truy vấn theo thời gian thực trong khi vẫn duy trì hiệu suất.
Hãy tưởng tượng hai người dùng kết nối với Cloud Firestore thông qua một ứng dụng nhắn tin được xây dựng bằng một trong các SDK di động.
Ứng dụng khách A ghi vào cơ sở dữ liệu để thêm và cập nhật tài liệu trong một tập hợp có tên là chatroom:
collection chatroom:
document message1:
from: 'Sparky'
message: 'Welcome to Cloud Firestore!'
document message2:
from: 'Santa'
message: 'Presents are coming'
Ứng dụng B theo dõi thông tin cập nhật trong cùng một tập hợp bằng trình nghe ảnh chụp nhanh. Ứng dụng B nhận được thông báo ngay lập tức bất cứ khi nào có người tạo tin nhắn mới. Sơ đồ sau đây cho thấy cấu trúc đằng sau trình nghe ảnh chụp nhanh:
Chuỗi sự kiện sau đây diễn ra khi Ứng dụng khách B kết nối trình nghe ảnh chụp nhanh với cơ sở dữ liệu:
- Ứng dụng khách B mở kết nối với Cloud Firestore và đăng ký một trình nghe bằng cách gọi đến
onSnapshot(collection("chatroom"))thông qua Firebase SDK. Người nghe này có thể nghe nhạc trong nhiều giờ. - Giao diện người dùng Cloud Firestore truy vấn hệ thống lưu trữ cơ bản để khởi động tập dữ liệu. Thao tác này sẽ tải toàn bộ tập hợp kết quả của các tài liệu trùng khớp. Chúng tôi gọi đây là truy vấn thăm dò ý kiến. Sau đó, hệ thống sẽ đánh giá Quy tắc bảo mật của Firebase trong cơ sở dữ liệu để xác minh rằng người dùng có thể truy cập vào dữ liệu này. Nếu người dùng được uỷ quyền, cơ sở dữ liệu sẽ trả về dữ liệu cho người dùng.
- Sau đó, truy vấn của ứng dụng khách B sẽ chuyển sang chế độ nghe. Trình nghe đăng ký với trình xử lý gói thuê bao và chờ thông tin cập nhật về dữ liệu.
- Giờ đây, ứng dụng khách A sẽ gửi một thao tác ghi để sửa đổi tài liệu.
- Cơ sở dữ liệu cam kết thay đổi tài liệu đối với hệ thống lưu trữ của nó.
- Về mặt giao dịch, hệ thống sẽ cam kết cùng một bản cập nhật cho nhật ký thay đổi nội bộ. Nhật ký thay đổi thiết lập thứ tự nghiêm ngặt của các thay đổi khi chúng xảy ra.
- Nhật ký thay đổi lần lượt phân phối dữ liệu đã cập nhật đến một nhóm trình xử lý gói thuê bao.
- Trình so khớp truy vấn đảo ngược sẽ thực thi để xem tài liệu đã cập nhật có khớp với bất kỳ trình nghe ảnh chụp nhanh nào hiện đã đăng ký hay không. Trong ví dụ này, tài liệu khớp với trình nghe ảnh chụp nhanh của Máy khách B. Như tên gọi, bạn có thể coi trình so khớp truy vấn đảo ngược là một truy vấn cơ sở dữ liệu thông thường nhưng được thực hiện theo cách đảo ngược. Thay vì tìm kiếm trong các tài liệu để tìm những tài liệu khớp với một truy vấn, công cụ này sẽ tìm kiếm một cách hiệu quả trong các truy vấn để tìm những truy vấn khớp với một tài liệu đến. Khi tìm thấy kết quả trùng khớp, hệ thống sẽ chuyển tiếp tài liệu liên quan đến trình nghe ảnh chụp nhanh. Sau đó, hệ thống sẽ đánh giá Quy tắc bảo mật của Firebase của cơ sở dữ liệu để đảm bảo rằng chỉ những người dùng được uỷ quyền mới nhận được dữ liệu.
- Hệ thống chuyển tiếp bản cập nhật tài liệu đến SDK trên thiết bị của ứng dụng khách B và lệnh gọi lại
onSnapshotsẽ kích hoạt. Nếu bạn bật tính năng lưu trữ cục bộ, SDK cũng sẽ áp dụng bản cập nhật cho bộ nhớ đệm cục bộ.
Một phần quan trọng trong khả năng có thể mở rộng của Cloud Firestore phụ thuộc vào việc phân đầu ra từ nhật ký thay đổi đến trình xử lý gói thuê bao và máy chủ giao diện người dùng. Mô hình phân phối này cho phép một thay đổi dữ liệu duy nhất được truyền đi một cách hiệu quả để phục vụ hàng triệu truy vấn theo thời gian thực và người dùng đã kết nối. Bằng cách chạy nhiều bản sao của tất cả các thành phần này trên nhiều vùng (hoặc nhiều khu vực trong trường hợp triển khai nhiều khu vực), Cloud Firestore đạt được khả năng hoạt động cao và khả năng có thể mở rộng.
Xin lưu ý rằng tất cả các thao tác đọc được thực hiện từ SDK web và thiết bị di động đều tuân theo mô hình trên. Các ứng dụng này thực hiện truy vấn thăm dò, sau đó là chế độ nghe để duy trì các đảm bảo về tính nhất quán. Điều này cũng áp dụng cho trình nghe theo thời gian thực, lệnh gọi để truy xuất tài liệu và truy vấn một lần. Bạn có thể coi việc truy xuất một tài liệu và truy vấn một lần là trình nghe ảnh chụp nhanh ngắn hạn có các quy tắc ràng buộc tương tự về hiệu suất.
Áp dụng các phương pháp hay nhất để mở rộng quy mô truy vấn theo thời gian thực
Hãy áp dụng các phương pháp hay nhất sau đây để thiết kế các truy vấn theo thời gian thực có thể mở rộng.
Tìm hiểu về lưu lượng ghi cao trong hệ thống
Phần này giúp bạn hiểu cách hệ thống phản hồi khi số lượng yêu cầu ghi tăng lên.
Nhật ký thay đổi Cloud Firestore thúc đẩy các truy vấn theo thời gian thực sẽ tự động cấp tài nguyên bổ sung theo chiều ngang khi lưu lượng ghi tăng lên. Khi tốc độ ghi cho cơ sở dữ liệu tăng vượt quá mức mà một máy chủ có thể xử lý, nhật ký thay đổi sẽ được phân tách trên nhiều máy chủ và quá trình xử lý truy vấn bắt đầu sử dụng dữ liệu từ nhiều trình xử lý gói thuê bao thay vì một. Theo quan điểm của ứng dụng và SDK, tất cả đều minh bạch và ứng dụng không cần làm gì khi quá trình phân tách diễn ra. Sơ đồ sau đây minh hoạ cách truy vấn theo thời gian thực mở rộng quy mô:
Tính năng tự động cấp tài nguyên bổ sung cho phép bạn tăng lưu lượng ghi mà không bị giới hạn, nhưng khi lưu lượng truy cập tăng lên, hệ thống có thể mất một chút thời gian để phản hồi. Hãy làm theo các đề xuất của quy tắc 5-5-5 để tránh tạo điểm phát sóng ghi. Key Visualizer là một công cụ hữu ích để phân tích các điểm tương tác ghi.
Nhiều ứng dụng có mức tăng trưởng tự nhiên dễ dự đoán, Cloud Firestore có thể đáp ứng mà không cần biện pháp phòng ngừa. Tuy nhiên, khối lượng công việc theo lô như nhập một tập dữ liệu lớn có thể tăng số lượt ghi quá nhanh. Khi thiết kế ứng dụng, hãy lưu ý đến nguồn lưu lượng truy cập ghi.
Hiểu cách hoạt động ghi và đọc tương tác với nhau
Bạn có thể coi hệ thống truy vấn theo thời gian thực là một quy trình kết nối các thao tác ghi với trình đọc. Bất cứ khi nào một tài liệu được tạo, cập nhật hoặc xoá, thay đổi sẽ được truyền từ hệ thống lưu trữ đến trình nghe hiện đã đăng ký. Cấu trúc nhật ký thay đổi của Cloud Firestore đảm bảo tính nhất quán cao, tức là ứng dụng của bạn không bao giờ nhận được thông báo về các bản cập nhật không theo thứ tự so với thời điểm cơ sở dữ liệu ghi nhận các thay đổi về dữ liệu. Điều này giúp đơn giản hoá quá trình phát triển ứng dụng bằng cách loại bỏ các trường hợp hiếm gặp liên quan đến tính nhất quán của dữ liệu.
Quy trình kết nối này có nghĩa là một thao tác ghi gây ra điểm phát sóng hoặc tranh chấp khoá có thể ảnh hưởng tiêu cực đến các thao tác đọc. Khi thao tác ghi không thành công hoặc bị điều tiết, thao tác đọc có thể bị đình trệ trong khi chờ dữ liệu nhất quán từ nhật ký thay đổi. Nếu điều này xảy ra trong ứng dụng, bạn có thể thấy cả thao tác ghi chậm và thời gian phản hồi chậm tương ứng cho các truy vấn. Tránh các điểm nóng là chìa khoá để tránh vấn đề này.
Giữ cho tài liệu và thao tác ghi ở mức nhỏ
Khi xây dựng ứng dụng bằng trình nghe ảnh chụp nhanh, bạn thường muốn người dùng nhanh chóng tìm hiểu về các thay đổi đối với dữ liệu. Để đạt được điều này, hãy cố gắng giữ cho mọi thứ nhỏ gọn. Hệ thống có thể đẩy các tài liệu nhỏ có hàng chục trường thông qua hệ thống rất nhanh chóng. Các tài liệu lớn hơn có hàng trăm trường và dữ liệu lớn sẽ mất nhiều thời gian hơn để xử lý.
Tương tự, hãy ưu tiên các thao tác ghi và cam kết ngắn, nhanh để duy trì độ trễ thấp. Các lô lớn có thể mang lại cho bạn thông lượng cao hơn từ góc nhìn của trình ghi, nhưng thực tế có thể làm tăng thời gian thông báo cho trình nghe ảnh chụp nhanh. Điều này thường trái ngược với việc sử dụng các hệ thống cơ sở dữ liệu khác, nơi bạn có thể sử dụng tính năng phân lô để cải thiện hiệu suất.
Sử dụng trình nghe hiệu quả
Khi tỷ lệ ghi cho cơ sở dữ liệu của bạn tăng lên, Cloud Firestore sẽ phân chia quá trình xử lý dữ liệu trên nhiều máy chủ. Thuật toán phân đoạn của Cloud Firestore cố gắng đặt dữ liệu từ cùng một tập hợp hoặc nhóm tập hợp vào cùng một máy chủ nhật ký thay đổi. Hệ thống cố gắng tối đa hoá thông lượng ghi có thể trong khi vẫn giữ số lượng máy chủ tham gia vào quá trình xử lý truy vấn ở mức thấp nhất có thể.
Tuy nhiên, một số mẫu nhất định vẫn có thể dẫn đến hành vi không tối ưu cho trình nghe ảnh chụp nhanh. Ví dụ: nếu ứng dụng của bạn lưu trữ hầu hết dữ liệu trong một tập hợp lớn, thì trình nghe có thể cần kết nối với nhiều máy chủ để nhận tất cả dữ liệu cần thiết. Điều này vẫn đúng ngay cả khi bạn áp dụng bộ lọc cụm từ tìm kiếm. Việc kết nối với nhiều máy chủ sẽ làm tăng nguy cơ phản hồi chậm.
Để tránh tình trạng phản hồi chậm này, hãy thiết kế giản đồ và ứng dụng sao cho hệ thống có thể phân phát trình nghe mà không cần truy cập vào nhiều máy chủ khác nhau. Cách tốt nhất có thể là chia dữ liệu thành các tập hợp nhỏ hơn với tốc độ ghi thấp hơn.
Điều này tương tự như việc nghĩ về các truy vấn hiệu suất trong cơ sở dữ liệu quan hệ yêu cầu quét toàn bộ bảng. Trong cơ sở dữ liệu quan hệ, một truy vấn yêu cầu quét toàn bộ bảng tương đương với một trình nghe ảnh chụp nhanh theo dõi một tập hợp có tỷ lệ rời bỏ cao. Truy vấn này có thể hoạt động chậm so với một truy vấn mà cơ sở dữ liệu có thể phân phát bằng cách sử dụng một chỉ mục cụ thể hơn. Một truy vấn có chỉ mục cụ thể hơn giống như một trình nghe ảnh chụp nhanh theo dõi một tài liệu hoặc tập hợp ít thay đổi hơn. Bạn nên kiểm thử tải ứng dụng để hiểu rõ nhất hành vi và nhu cầu của trường hợp sử dụng.
Giữ cho các truy vấn thăm dò ý kiến nhanh chóng
Một phần quan trọng khác của truy vấn thích ứng theo thời gian thực là đảm bảo rằng truy vấn thăm dò ý kiến để khởi động dữ liệu diễn ra nhanh chóng và hiệu quả. Lần đầu tiên trình nghe ảnh chụp nhanh mới kết nối, trình nghe phải tải toàn bộ tập kết quả và gửi đến thiết bị của người dùng. Các truy vấn chậm khiến ứng dụng của bạn phản hồi chậm hơn. Ví dụ: điều này bao gồm các truy vấn cố gắng đọc nhiều tài liệu hoặc các truy vấn không sử dụng chỉ mục thích hợp.
Trong một số trường hợp, trình nghe cũng có thể chuyển từ trạng thái nghe về trạng thái thăm dò ý kiến. Quá trình này diễn ra tự động và minh bạch đối với SDK và ứng dụng của bạn. Các điều kiện sau đây có thể kích hoạt trạng thái thăm dò ý kiến:
- Hệ thống cân bằng lại nhật ký thay đổi do có sự thay đổi về tải.
- Điểm truy cập gây ra lỗi hoặc làm chậm quá trình ghi vào cơ sở dữ liệu.
- Việc khởi động lại máy chủ tạm thời sẽ ảnh hưởng đến trình nghe.
Nếu truy vấn thăm dò ý kiến của bạn đủ nhanh, thì trạng thái thăm dò ý kiến sẽ trở nên minh bạch với người dùng ứng dụng.
Ưu tiên trình nghe dài hạn
Mở và duy trì trình nghe càng lâu càng tốt thường là cách tiết kiệm chi phí nhất để xây dựng một ứng dụng sử dụng Cloud Firestore. Khi sử dụng Cloud Firestore, bạn sẽ được tính phí cho các tài liệu được trả về ứng dụng của mình chứ không phải cho việc duy trì kết nối mở. Trình nghe ảnh chụp nhanh tồn tại lâu dài chỉ đọc dữ liệu cần thiết để phân phát truy vấn trong suốt thời gian hoạt động. Thao tác này bao gồm một thao tác thăm dò ban đầu, sau đó là thông báo khi dữ liệu thực sự thay đổi. Mặt khác, truy vấn một lần sẽ đọc lại dữ liệu có thể không thay đổi kể từ lần gần nhất ứng dụng thực thi truy vấn.
Trong trường hợp ứng dụng của bạn phải sử dụng tốc độ dữ liệu cao, trình nghe ảnh chụp nhanh có thể không phù hợp. Ví dụ: nếu trường hợp sử dụng của bạn đẩy nhiều tài liệu mỗi giây thông qua một kết nối trong một khoảng thời gian dài, thì bạn nên chọn các truy vấn một lần chạy ở tần suất thấp hơn.
Tiếp theo là gì?
- Tìm hiểu cách sử dụng trình nghe ảnh chụp nhanh.
- Đọc thêm về các phương pháp hay nhất.