Đọ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 ra ngoài hàng nghìn hoạt động mỗi giây hoặc hàng trăm nghìn hoạt động người dùng đồng thời. Tài liệu này có các chủ đề nâng cao để trợ giúp bạn hiểu rõ về hệ thống. Nếu bạn chỉ mới bắt đầu với Cloud Firestore, hãy xem hướng dẫn bắt đầu nhanh.
Cloud Firestore và SDK web/thiết bị 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. SDK cho phép ứng dụng theo dõi nội dung cập nhật dữ liệu theo thời gian thực. Bạn có thể sử dụng các bản cập nhật theo thời gian thực để tạo ứng dụng thích ứng mà không cần máy chủ cơ sở hạ tầng. Mặc dù việc thiết lập và chạy một thứ gì đó rất dễ dàng, nhưng nó sẽ hữu ích nắm được các hạn chế trong các hệ thống tạo nên Cloud Firestore để ứng dụng không máy chủ 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 đây để được tư vấn về cách mở rộng quy mô ứng dụng của bạn.
Chọn vị trí cơ sở dữ liệu gần người dùng của bạn
Sơ đồ dưới đâ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 đến Cloud Firestore, kết nối sẽ được định tuyến đến
Máy chủ giao diện người dùng Cloud Firestore trong cùng
region (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, kết nối cũng sẽ chuyển đến
Giao diện người dùng Cloud Firestore cũng có trong us-east1. Những kết nối này
tồn tại lâu dài và luôn mở cho đến khi bị ứng dụng đóng một cách rõ ràng. Chiến lược phát hành đĩa đơn
giao diện người dùng đọc dữ liệu từ các hệ thống lưu trữ cơ bản của Cloud Firestore.
Khoảng cách giữa vị trí thực tế của người dùng và Cloud Firestore vị trí của cơ sở dữ liệu ả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 một cơ sở dữ liệu ở một 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 hơn so với khi cơ sở dữ liệu thay vào đó lại ở 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
Firebase SDK giúp lưu trữ dữ liệu ngoại tuyến một cách cố định. 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, ứ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 dữ liệu truy cập ngay cả khi người dùng gặp sự cố 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 chi tiết về chế độ ngoại tuyến, hãy xem Bật dữ liệu ngoại tuyến.
Tìm hiểu về việc thử lại tự động
SDK Firebase đảm nhiệm việc thử lại các hoạt động và thiết lập lại kết nối bị hỏng. Việc này giúp khắc phục các lỗi tạm thời gây ra bằng cách khởi động lại máy chủ hoặc sự cố 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à nhiều khu vực
Có một số đánh đổi khi chọn giữa theo khu vực và địa điểm nhiều khu vực. Điểm khác biệt chính là cách dữ liệu được sao chép. Chiến dịch này thúc đẩy đảm bảo về tính sẵn có cho ứng dụng của bạn. Một thực thể nhiều vùng mang lại độ tin cậy cao hơn cho việc phân phát và tăng tính bền vững của dữ liệu nhưng sự đánh đổi chính là chi phí.
Tìm hiểu về hệ thống truy vấn theo thời gian thực
Các truy vấn theo thời gian thực (còn được gọi là trình nghe tổng quan nhanh) cho phép ứng dụng nghe các thay đổi trong cơ sở dữ liệu và nhận được thông báo độ trễ thấp ngay khi dữ liệu thay đổi. Ứng dụng có thể nhận được cùng một kết quả bằng cách định kỳ thăm dò cơ sở dữ liệu để nhưng thường chậm hơn, tốn kém hơn và yêu cầu nhiều mã hơn. Cho 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 Xem thông tin cập nhật theo thời gian thực. Các phần sau có được thông tin chi tiết về cách hoạt động của trình nghe tổng quan nhanh và mô tả một số về các 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 2 người dùng kết nối với Cloud Firestore thông qua một tin nhắn ứng dụng được tạo bằng một trong các SDK 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 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 nội dung cập nhật trong cùng một bộ sưu tập bằng cách sử dụng trình nghe tổng quan nhanh. Ứng dụng B sẽ nhận được thông báo ngay lập tức mỗi khi có người tạo tin nhắn mới. Sơ đồ dưới đây cho thấy cấu trúc của một trình nghe tổng quan nhanh:
Trình tự các sự kiện sau đây sẽ diễn ra khi Ứng dụng B kết nối một bản tổng quan nhanh trình nghe vào cơ sở dữ liệu:
- Ứng dụng B mở một kết nối đến Cloud Firestore và đăng ký một
trình nghe bằng cách thực hiện lệnh gọi đến
onSnapshot(collection("chatroom"))thông qua Firebase SDK. Trình nghe này có thể duy trì 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 để tự khởi động tập dữ liệu. Công cụ này tải toàn bộ tập hợp kết quả so khớp tài liệu. Chúng tôi gọi đây là truy vấn thăm dò ý kiến. Khi đó, hệ thống đánh giá thông tin của cơ sở dữ liệu Quy tắc bảo mật của Firebase để xác minh rằng người dùng có thể truy cập dữ liệu này. Nếu người dùng được uỷ quyền, cơ sở dữ liệu 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ý thuê bao và chờ cập nhật cho dữ liệu.
- Ứng dụng A hiện sẽ gửi thao tác ghi để sửa đổi tài liệu.
- Cơ sở dữ liệu 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ẽ gửi cùng một bản cập nhật cho phiên bản nhật ký thay đổi. Nhật ký thay đổi thiết lập một thứ tự nghiêm ngặt của các thay đổi như chúng xảy ra.
- Nhật ký thay đổi sẽ chuyển dữ liệu cập nhật sang một nhóm gói thuê bao trình xử lý.
- Trình so khớp truy vấn đảo ngược thực thi để xem tài liệu được cập nhật có khớp với không bất kỳ trình nghe ảnh chụp nhanh nào hiện đã đăng ký. Trong ví dụ này, tài liệu khớp với trình nghe tổng quan nhanh của Ứng dụng B. Như cái tên của nó cho thấy, bạn có thể liên tưởng trình so khớp truy vấn ngược như một truy vấn cơ sở dữ liệu thông thường nhưng được thực hiện ngược lại. Thay vì tìm kiếm trong các tài liệu để tìm những tài liệu phù hợp với truy vấn, tính năng này sẽ tìm kiếm hiệu quả qua để tìm những truy vấn khớp với tài liệu gửi đến. Sau khi tìm thấy đoạn trùng khớp, hệ thống sẽ chuyển tiếp tài liệu liên quan đến trình nghe tổng quan 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 sẽ chuyển tiếp bản cập nhật tài liệu tới SDK trên thiết bị của ứng dụng B, và
lệnh gọi lại
onSnapshotsẽ kích hoạt. Nếu tính năng lưu trữ cục bộ được bật, 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 mở rộng của Cloud Firestore phụ thuộc vào lượng người hâm mộ nhật ký thay đổi cho trình xử lý đăng ký và máy chủ giao diện người dùng. Chiến lược phát hành đĩa đơn tính năng fan-out cho phép một thay đổi dữ liệu được truyền tải hiệu quả để phân phát hàng triệu theo thời gian thực và người dùng được 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 trên nhiều vùng (hoặc nhiều khu vực trong trường hợp bạn có nhiều vùng triển khai), Cloud Firestore đạt được khả năng hoạt động và khả năng mở rộng cao.
Lưu ý rằng tất cả thao tác đọc được phát hành qua SDK dành cho thiết bị di động và web hãy làm theo mô hình trên. Chúng thực hiện một truy vấn thăm dò, sau đó là chế độ nghe để duy trì sự đả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ể nghĩ đến truy xuất tài liệu và truy vấn một lần dưới dạng trình nghe tổng quan nhanh trong thời gian ngắn đi kèm với những hạn chế 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.
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 ứng với tình trạng tăng số lượng yêu cầu ghi.
Nhật ký thay đổi của 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. Tốc độ ghi cho một cơ sở dữ liệu vượt quá khả năng xử lý của một máy chủ, nhật ký thay đổi được chia nhỏ 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 khách hàng và SDK, điều này là minh bạch và bạn không cần làm gì cả khỏi ứng dụng khi phân tách xảy ra. Biểu đồ dưới đây minh hoạ cách truy vấn theo thời gian thực:
Tự động chuyển tỷ lệ cho phép bạn tăng lưu lượng ghi mà không có giới hạn, nhưng khi giao thông tăng tốc, 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 trong quy tắc 5-5-5 để tránh tạo một điểm phát sóng ghi. Key Visualr là một công cụ hữu ích để phân tích các điểm phát sóng ghi.
Nhiều ứng dụng có mức tăng trưởng tự nhiên có thể dự đoán, điều mà Cloud Firestore có thể đáp ứng mà không có biện pháp phòng ngừa. Tải công việc hàng loạt, chẳng hạn như nhập có thể tăng tốc độ ghi quá nhanh. Khi bạn thiết kế ứng dụng, hãy luôn biết lưu lượng truy cập ghi đến từ đâu.
Hiểu cách hoạt động ghi và đọc tương tá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 việc ghi với độc giả. 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ẽ truyền từ hệ thống lưu trữ sang người nghe. Cấu trúc nhật ký thay đổi của Cloud Firestore đảm bảo mạnh mẽ nhất quán, 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 đúng thứ tự so với thời điểm cơ sở dữ liệu gửi dữ liệu thay đổi. Việc này giúp đơn giản hoá quá trình phát triển ứng dụng bằng cách xoá 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 được kết nối này có nghĩa là 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 hoạt động đọc. Khi thao tác ghi không thành công hoặc gặp phải tình trạng điều tiết, lượt đọc có thể chờ dữ liệu nhất quán từ nhật ký thay đổi. Nếu việc này xảy ra trong ứng dụng của mình, bạn có thể thấy cả thao tác ghi chậm và phản hồi chậm có tương quan dành cho truy vấn. Tránh các điểm phát sóng là chìa khoá để tránh gặp phải vấn đề này vấn đề.
Giữ tài liệu và thao tác ghi ở quy mô nhỏ
Khi tạo ứng dụng có trình nghe tổng quan nhanh, bạn thường muốn người dùng tìm thấy về dữ liệu thay đổi một cách nhanh chóng. Để đạt được mục tiêu này, hãy cố gắng làm những việc nhỏ gọn. Chiến lược phát hành đĩa đơn có thể đẩy các tài liệu nhỏ có hàng chục trường thông qua hệ thống một cách 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à cam kết ngắn, nhanh chóng để 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 độ của người viết nhưng thực sự có thể làm tăng thời gian thông báo cho trình nghe tổng quan nhanh. Điều này thường khác thường so với việc sử dụng các hệ thống cơ sở dữ liệu khác 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ốc độ ghi cơ sở dữ liệu của bạn tăng lên, Cloud Firestore 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 định vị dữ liệu từ cùng một bộ sưu tập hoặc nhóm bộ sưu tập trên cùng một máy chủ nhật ký thay đổi. Chiến lược phát hành đĩa đơn hệ thống cố gắng tối đa hoá thông lượng ghi có thể trong khi vẫn giữ số 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 hình nhất định vẫn có thể dẫn đến hành vi dưới mức tối ưu cho ảnh chụp nhanh người nghe. 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 thu thập dữ liệu, trình nghe có thể cần phải kết nối với nhiều máy chủ để nhận 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. Đang kết nối vào nhiều máy chủ sẽ làm tăng nguy cơ phản hồi chậm hơn.
Để tránh những phản hồi chậm hơn 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 người nghe mà không cần phải truy cập nhiều máy chủ. Có thể có hiệu quả tốt nhất là chia dữ liệu của mình 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 về hiệu suất trong cơ sở dữ liệu quan hệ yêu cầu phải quét toàn bộ bảng. Trong quan hệ cơ sở dữ liệu, một truy vấn yêu cầu quét toàn bộ bảng tương đương với trình nghe tổng quan nhanh xem một tuyển tập có tỷ lệ người dùng cao. Quá trình 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 một chỉ mục cụ thể hơn. Truy vấn có chỉ mục cụ thể hơn giống như một trình nghe tổng quan nhanh xem một tài liệu hoặc một bộ sưu tập có ít thay đổi hơn. Bạn nên tải kiểm 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ì 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 đáp ứng theo thời gian thực bao gồm đảm bảo rằng để tự động khởi động, giúp dữ liệu trở nên nhanh chóng và hiệu quả. Khi một trình nghe tổng quan nhanh mới được kết nối lần đầu tiên, trình nghe phải tải toàn bộ tập hợp kết quả và gửi nó đến thiết bị của người dùng. Truy vấn chậm khiến ứng dụng của bạn phản hồi ké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 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 trong một số trường hợp. Việc 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 có thể kích hoạt trạng thái thăm dò:
- Hệ thống cân bằng lại nhật ký thay đổi do thay đổi về tải.
- Các điểm phát sóng khiến việc 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ẽ ảnh hưởng đến người nghe.
Nếu truy vấn thăm dò của bạn đủ nhanh, trạng thái thăm dò sẽ trở nên trong suốt cho người dùng ứng dụng của bạn.
Ưu tiên người nghe lâu dài
Mở đầu và giữ chân người nghe lâu nhất có thể là điều quan trọng nhất cách tiết kiệm chi phí để tạo một ứng dụng sử dụng Cloud Firestore. Khi sử dụng Cloud Firestore, bạn sẽ bị tính phí đối với những tài liệu mà hệ thống trả về ứng dụng của bạn chứ không phải để duy trì kết nối mở. Một trình nghe tổng quan nhanh sẽ đọc dữ liệu cần thiết để phân phát truy vấn trong suốt thời gian hoạt động. Chiến dịch này bao gồm hoạt động thăm dò ban đầu, sau đó là các thông báo khi dữ liệu thực sự thay đổi. Mặt khác, truy vấn một lần đọc lại những 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 kết nối trong một khoảng thời gian dài, thì có thể bạn nên chọn 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.