Hãy đọc tài liệu này để biết hướng dẫn về cách mở rộng ứng dụng không có máy chủ ngoài 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 Firebase dành cho thiết bị di động/web cung cấp một mô hình mạnh mẽ để phát triển các ứng dụng không có 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 nghe thông tin cập nhật về dữ liệu theo thời gian thực. Bạn có thể sử dụng thông tin cập nhật theo thời gian thực để xây dựng các ứng dụng thích ứng không yêu cầu cơ sở hạ tầng máy chủ. Mặc dù rất dễ thiết lập và chạy, nhưng bạn cần hiểu các quy tắc ràng buộc trong các hệ thống tạo nên Cloud Firestore để ứng dụng không có 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 với 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 (di động hoặc web) thiết lập kết nối với Cloud Firestore, kết nối này sẽ được định tuyến đến máy chủ giao diện người dùng Cloud Firestore trong cùng một khu vực nơi cơ sở dữ liệu của bạn nằm. 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 giao diện người dùng Cloud Firestore cũng nằm trong us-east1. Các kết nối này có thời gian 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ừ các 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ơ 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 ở 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 ở 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ế để đảm bảo độ 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
SDK Firebase cung cấp dữ liệu ổn định khi không có mạng. 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 xử lý 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 vào dữ liệu ngay cả khi người dùng gặp phải tình trạng kết nối Internet không ổn định hoặc hoàn toàn mất 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 bài viết Bật dữ liệu ngoại tuyến.
Tìm hiểu về tính năng thử lại tự động
SDK Firebase sẽ xử lý 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 khắc phục các lỗi tạm thời do việc khởi động lại máy chủ hoặc sự cố mạng giữa ứng dụng 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 chọn giữa vị trí theo khu vực và vị trí theo nhiều khu vực. Điểm khác biệt chính là cách sao chép dữ liệu. Điều này giúp đảm bảo khả năng cung cấp của ứng dụng. Một thực thể nhiều vùng sẽ giúp tăng độ tin cậy khi phân phát và tăng độ bền của dữ liệu, nhưng bạn sẽ phải đánh đổi bằng chi phí.
Tìm hiểu về 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 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ò ý kiến cơ sở dữ liệu để cập nhật, nhưng cách này thường chậm hơn, tốn kém hơn và yêu cầu nhiều mã hơn. Để biết các 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 đi sâu vào chi tiết về cách hoạt động của trình nghe tổng quan nhanh và mô tả một số phương pháp hay nhất để mở rộng quy mô truy vấn theo thời gian thực mà 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 tạo bằng một trong các SDK dành cho thiết bị di động.
Ứng dụng A ghi vào cơ sở dữ liệu để thêm và cập nhật tài liệu trong một bộ sưu tậ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 nội dung cập nhật trong cùng một bộ sưu tập bằng trình nghe tổng quan 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 của trình nghe ảnh chụp nhanh:
Trình tự sự kiện sau đây diễn ra khi Ứng dụng B kết nối trình nghe ảnh chụp nhanh với cơ sở dữ liệu:
- Ứng dụng B mở một kết nối đến Cloud Firestore và đăng ký trình nghe bằng cách gọi đến
onSnapshot(collection("chatroom"))thông qua SDK Firebase. Trình nghe này có thể hoạt động 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. Phương thức này tải toàn bộ tập hợp kết quả của các tài liệu phù hợp. Chúng tôi gọi đây là truy vấn thăm dò. Sau đó, hệ thống sẽ đánh giá Quy tắc bảo mật của Firebase của 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 B sẽ chuyển sang chế độ nghe. Trình nghe đăng ký với trình xử lý gói thuê bao và chờ dữ liệu cập nhật.
- Ứng dụng A hiện gửi một thao tác ghi để sửa đổi tài liệu.
- Cơ sở dữ liệu sẽ xác nhận thay đổi tài liệu vào hệ thống lưu trữ.
- Về mặt giao dịch, hệ thống sẽ thực hiện 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 sẽ phân phối dữ liệu đã cập nhật cho 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 Ứng dụng 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 cụm từ tìm kiếm, công cụ này sẽ tìm kiếm hiệu quả trong các cụm từ tìm kiếm để tìm những cụm từ tìm kiếm khớp với một tài liệu sắp tới. Khi tìm thấy kết quả trùng khớp, hệ thống sẽ chuyển tiếp tài liệu có 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 nội dung 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 chế độ 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 của khả năng mở rộng của Cloud Firestore phụ thuộc vào việc phân phối từ bản ghi thay đổi đến trình xử lý gói thuê bao và máy chủ giao diện người dùng. Tính năng phân tán cho phép một thay đổi dữ liệu duy nhất được truyền tải một cách hiệu quả để phân phát 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 và khả năng mở rộng cao.
Xin lưu ý rằng tất cả các thao tác đọc được phát hành từ SDK dành cho thiết bị di động và web đề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ò ý kiến, sau đó là chế độ nghe để duy trì 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 các lần truy xuất tài liệu đơn và truy vấn một lần là trình nghe tổng quan nhanh có thời gian tồn tại ngắn, kèm theo 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
Áp dụng các phương pháp hay nhất sau đây để thiết kế truy vấn theo thời gian thực có thể mở rộng quy mô.
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 số lượng yêu cầu ghi ngày càng tăng.
Nhật ký thay đổi Cloud Firestore thúc đẩy các truy vấn theo thời gian thực tự động mở rộng theo chiều ngang khi lưu lượng truy cập ghi tăng lên. Khi tốc độ ghi cho cơ sở dữ liệu tăng lên mức mà một máy chủ không thể xử lý, nhật ký thay đổi sẽ được phân chia trên nhiều máy chủ và quá trình xử lý truy vấn sẽ bắt đầu sử dụng dữ liệu từ nhiều trình xử lý gói thuê bao thay vì một trình xử lý. Từ 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 các truy vấn theo thời gian thực mở rộng quy mô:
Tính năng tự động mở rộng cho phép bạn tăng lưu lượng truy cập ghi mà không có 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 chút thời gian để phản hồi. 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 nóng ghi.
Nhiều ứng dụng có mức tăng trưởng tự nhiên có thể dự đoán được mà Cloud Firestore có thể thích ứ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 tốc độ 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.
Tìm hiểu cách hoạt động của các hoạt động ghi và đọc
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 mạnh mẽ, 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 thực hiệ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 ngoại lệ 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 nóng hoặc tranh chấp khoá có thể ảnh hưởng tiêu cực đến các thao tác đọc. Khi các thao tác ghi không thành công hoặc bị điều tiết, thao tác đọc có thể bị treo 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ả các thao tác ghi chậm và thời gian phản hồi chậm có liên quan 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à các 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 về dữ liệu. Để đạt được điều này, hãy cố gắng giữ mọi thứ ở mức nhỏ. 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 với 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à xác nhận ngắn, nhanh để giảm độ trễ. Các lô lớn có thể mang lại cho bạn thông lượng cao hơn từ quan điểm của trình ghi, nhưng thực sự 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, trong đó bạn có thể sử dụng tính năng xử lý hàng loạt để cải thiện hiệu suất.
Sử dụng trình nghe hiệu quả
Khi tốc độ 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 cù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á mức thông lượng ghi có thể có 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 tổng quan 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ủ làm tăng nguy cơ phản hồi chậm hơn.
Để tránh những phản hồi chậm này, hãy thiết kế giản đồ và ứng dụng của bạn để hệ thống có thể phân phát trình nghe mà không cần chuyển đến nhiều máy chủ. Tốt nhất bạn nên chia dữ liệu thành các tập hợp nhỏ hơn với tốc độ ghi nhỏ hơn.
Điều này tương tự như việc suy 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 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 truy vấn mà cơ sở dữ liệu có thể phân phát bằng cách sử dụng chỉ mục cụ thể hơn. Một truy vấn có chỉ mục cụ thể hơn giống như trình nghe tổng quan nhanh theo dõi một tài liệu hoặc một tập hợp thay đổi ít thường xuyên hơn. Bạn nên tải thử ứng dụng để hiểu rõ nhất hành vi và nhu cầu của trường hợp sử dụng.
Duy trì tốc độ nhanh cho các truy vấn thăm dò
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ả. Trong lần đầu tiên kết nối với trình nghe ảnh chụp nhanh mới, trình nghe phải tải toàn bộ tập hợp kết quả và gửi tập hợp kết quả đó đế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 kém hơn. Ví dụ: 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.
Trình nghe cũng có thể chuyển từ trạng thái nghe sang trạng thái thăm dò ý kiến trong một số trường hợp. Quá trình này diễn ra tự động và minh bạch đối với SDK cũng như ứ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 tải thay đổi.
- Điểm truy cập khiến quá trình ghi vào cơ sở dữ liệu không thành công hoặc bị trì hoãn.
- Việc khởi động lại máy chủ tạm thời sẽ tạm thời ảnh hưởng đến trình nghe.
Nếu các 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 đối với người dùng ứng dụng.
Ưu tiên trình nghe tồn tại lâu dài
Việc mở và duy trì trình nghe lâu nhất có thể thường là cách hiệu quả nhất về chi phí để 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 bạn chứ không phải để duy trì kết nối đang mở. Trình nghe ảnh chụp nhanh có thời gian tồn tại lâu 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. Quá trình này bao gồm một thao tác thăm dò ý kiến ban đầu, theo 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 đây 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 tiêu thụ dữ liệu với tốc độ 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.
Bước tiếp theo
- Tìm hiểu cách sử dụng trình nghe tổng quan nhanh.
- Đọc thêm về các phương pháp hay nhất.