Hãy đọc tài liệu này để được hướng dẫn về cách mở rộng quy mô ứng dụng không máy chủ 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 sâu hơn về 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 thay thế.
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 dù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 máy khách theo dõi các bản cập nhật đối với 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 các ứng dụng thích ứng mà không cần cơ sở hạ tầng máy chủ. Mặc dù rất dễ dàng để thiết lập và chạy một ứng dụng, nhưng bạn nên hiểu rõ các ràng buộc trong các hệ thống tạo nên Cloud Firestore để ứng dụng không dùng máy chủ có thể mở rộng quy mô và hoạt động tốt khi lưu lượng truy cập tăng lên.
Hãy xem các phần sau đây để 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 một
kết nối với Cloud Firestore, kết nối đó sẽ được định tuyến đến một
Cloud Firestore máy chủ giao diện người dùng trong cùng
khu vực nơi cơ sở dữ liệu của bạn được đặt. Ví dụ:
nếu cơ sở dữ liệu của bạn ở us-east1, thì kết nối cũng sẽ chuyển đến một
Cloud Firestore giao diện người dùng cũng ở us-east1. Các kết nối này tồn tại
lâu dài và vẫn mở cho đến khi ứng dụng đóng 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 trong 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 ít phản hồi nhanh hơn so với trường hợp cơ sở dữ liệu được đặt ở gần hơn, chẳng hạn như ở Ấn Độ hoặc ở một nơi khác ở Châu Á.
Thiết kế hướng đến độ tin cậy
Các chủ đề sau đây 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 tính năng duy 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 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 tự động thử lại
SDK Firebase chịu trách nhiệm thử lại các thao tác và thiết lập lại các kết nối bị gián đoạn. Điều này giúp khắc phục 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 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 dữ liệu được sao chép. Điều này thúc đẩy các đảm bảo về khả năng sử dụng của ứng dụng. Một thực thể đa khu vực mang lại độ tin cậy cao hơn khi phân phát và tăng độ bền của dữ liệu, nhưng điểm đánh đổi là 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 ảnh chụp 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 để cập nhật, nhưng thường chậm hơn, tốn kém hơn và yêu cầu nhiều mã hơn. Để xem 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 bài viết Nhận thông tin cập nhật theo thời gian thực. Các phần sau đây sẽ đi sâu vào 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 để mở rộng 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 2 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 dành cho thiết bị di động.
Máy 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 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'
Máy khách B theo dõi các bản cập nhật trong cùng một bộ sưu tập bằng trình nghe ảnh chụp nhanh. Máy khách 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 Máy khách B kết nối trình nghe ảnh chụp nhanh với cơ sở dữ liệu:
- Ứng dụng B mở kết nối với Cloud Firestore và đăng ký trình nghe bằng cách gọi đến
onSnapshot(collection("chatroom"))thông qua Firebase SDK. 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. Hệ thống này tải toàn bộ tậ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ò ý 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 Máy khách B chuyển sang chế độ theo dõi. Trình nghe đăng ký với trình xử lý gói thuê bao và chờ các bản cập nhật đối với dữ liệu.
- Máy khách A hiện 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 mình.
- Theo giao dịch, hệ thống cam kết cùng một bản cập nhật đối với nhật ký thay đổi nội bộ. Nhật ký thay đổi thiết lập một thứ tự nghiêm ngặt về các thay đổi khi chúng xảy ra.
- Đến lượt nhật ký thay đổi phân tán dữ liệu đã cập nhật đến một nhóm trình xử lý gói thuê bao.
- Một trình so khớp truy vấn đảo ngược 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 được đă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 chiều 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 khớp với một truy vấn, hệ thống này sẽ tìm kiếm 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. Sau khi tìm thấy kết quả phù hợp, hệ thống sẽ chuyển tiếp tài liệu được đề cập đế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 trong 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 máy khách B và lệnh gọi lại
onSnapshotsẽ kích hoạt. Nếu tính năng duy 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 của Cloud Firestore's khả năng có thể mở rộng 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. Tính năng phân đầu ra cho phép một thay đổi dữ liệu duy nhất lan truyền hiệu quả để phục vụ hàng triệu truy vấn 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 này trên nhiều khu vực (hoặc nhiều khu vực trong trường hợp triển khai đa khu vực ), Cloud Firestore đạt được khả năng sử dụng và khả năng mở rộng quy mô cao.
Bạn nên 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 thao tác này thực hiện một truy vấn thăm dò ý kiến, sau đó là chế độ theo dõi để 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, cá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 truy xuất tài liệu đơn lẻ và truy vấn một lần là trình nghe ảnh chụp nhanh tồn tại trong thời gian ngắn, đi kèm với cá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ế các 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 truy cập 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 tự động mở rộng quy mô theo chiều ngang khi lưu lượng truy cập ghi tăng lên. Khi tốc độ ghi cho một 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 chia thành 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 máy khách và SDK, tất cả đều minh bạch và ứng dụng không cần thực hiện hành động nào khi xảy ra tình trạng phân chia. Sơ đồ sau đây minh hoạ cách mở rộng quy mô truy vấn theo thời gian thực:
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 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 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 nó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ể đáp ứng mà không cần biện pháp phòng ngừa. Tuy nhiên, các khối lượng công việc hàng loạt 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 luôn chú ý đến nguồn lưu lượng truy cập ghi.
Tìm hiểu cách tương tác giữa thao tác ghi và thao tác đọ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ẽ lan truyền từ hệ thống lưu trữ đến các trình nghe hiện được đăng ký. Cloud FirestoreCấu trúc nhật ký thay đổi đảm bảo tính nhất quán cao, nghĩa 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 cam kết các thay đổi 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 đặc biệt 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 các điểm nóng hoặc tình trạng 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 gặp phải tình trạng điều tiết, thao tác đọc có thể bị dừng lại để 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 của bạn, 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 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à 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 dữ liệu. Để đạt được điều này, hãy cố gắng giữ cho 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 có hàng trăm trường và dữ liệu lớn mất nhiều thời gian hơn để xử lý.
Tương tự, hãy ưu tiên các thao tác cam kết và ghi nhanh, ngắn để giữ độ trễ ở mức thấp. Các lô lớn có thể mang lại cho bạn công suất cao hơn theo quan điểm 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 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ẽ chia quá trình xử lý dữ liệu trên nhiều máy chủ. Thuật toán phân mảnh của Cloud Firestore cố gắng đồng vị trí 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. 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 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 bộ sưu tậ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 truy vấn. 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 hơn 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ó thể tốt nhất là chia dữ liệu thành các bộ sưu tậ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 một trình nghe ảnh chụp nhanh theo dõi một bộ sưu tập có mức độ thay đổi 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 chỉ mục cụ thể hơn. Truy vấn có chỉ mục cụ thể hơn giống như trình nghe ảnh chụp nhanh theo dõi một tài liệu duy nhất hoặc một bộ sưu tập thay đổi ít thường xuyên hơn. Bạn nên kiểm tra tải ứng dụng để hiểu rõ nhất về 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 các truy vấn theo thời gian thực phản hồi nhanh liên quan đến việc đảm bảo rằng truy vấn thăm dò ý kiến để khởi động dữ liệu là nhanh chóng và hiệu quả. Lần đầu tiên một 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 ít phản hồi nhanh 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 theo dõi trở lại trạng thái thăm dò ý kiến trong một số trường hợp. Điều này xảy 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 thay đổi về tải.
- Các điểm nóng gây ra tình trạng ghi không thành công hoặc bị trì hoãn vào cơ sở dữ liệu.
- Việc khởi động lại máy chủ 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 của bạn.
Ưu tiên trình nghe tồn tại lâu dài
Việc mở và duy trì trình nghe hoạt động càng lâu càng tốt 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ẽ bị 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 tồn tại. Điều này bao gồm một thao tác thăm dò ý kiến ban đầu, sau đó là thông báo khi dữ liệu thực sự thay đổi. Mặt khác, các truy vấn một lần sẽ đọc lại dữ liệu có thể chưa thay đổi kể từ lần cuối ứ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 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 với 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.