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 ra 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 sâu về hệ thống. Nếu bạn chỉ 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/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 để xây dựng các ứng dụng thích ứng mà không yêu cầu 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 hạn chế trong các hệ thống cấu thành 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 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 một giao diện người dùng Cloud Firestore cũng trong us-east1. Những kết nối này tồn tại trong thời gian 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 sẽ đọ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à vị trí cơ sở dữ liệu trên 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 ở một khu vực Google Cloud ở Bắc Mỹ có thể nhận 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 được đặt 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, thì ứng dụng vẫn 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 sự cố 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ề việc thử lại tự động
SDK Firebase 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. Việc này giúp giải quyết 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 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ố ưu điểm khi chọn giữa các vị trí theo khu vực và nhiều 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 khả năng đảm bảo tính sẵn có của ứng dụng. Một thực thể nhiều khu vực sẽ mang lại độ tin cậy cao hơn trong quá trình phân phát và tăng độ bền của dữ liệu, nhưng bạn cũng sẽ đánh đổi lại 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. Một ứng dụng có thể nhận được kết quả tương tự bằng cách thăm dò cơ sở dữ liệu định kỳ để 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 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 sẽ trình bày 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ố 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 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 diễn ra khi Ứng dụng B kết nối một trình nghe tổng quan 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ý một 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ể 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 để khởi động tập dữ liệu. Nó 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ò ý kiến. Sau đó, hệ thống sẽ đánh giá Quy tắc bảo mật 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 này đăng ký bằng một trình xử lý gói thuê bao và chờ cập nhật 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 này xác nhận nội dung thay đổi đối vớ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 một thứ tự nghiêm ngặt của các thay đổi khi chúng diễn ra.
- Nhật ký thay đổi sẽ phân bổ dữ liệu được 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 ngược sẽ được thực thi để xem tài liệu đã cập nhật có khớp với bất kỳ trình nghe tổng quan 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 tổng quan nhanh của Ứng dụng B. Như chính tên gọi của nó, 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 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ả thông qua các truy vấn để tìm những tài liệu khớp với tài liệu gửi đế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 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 đến 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 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 mở rộng của Cloud Firestore phụ thuộc vào lượt chuyển đổi từ nhật ký thay đổi đến các trình xử lý gói thuê bao và máy chủ giao diện người dùng. Tính năng này cho phép một thay đổi dữ liệu được truyền một cách hiệu quả nhằm phân phát cho 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 vùng (hoặc nhiều khu vực trong trường hợp triển khai trên nhiều khu vực), 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 đều tuân theo mô hình trên. Chúng thực hiện truy vấn thăm dò, theo sau là chế độ nghe để duy trì sự đảm bảo về tính nhất quán. Việc 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 hoạt động truy xuất tài liệu đơn lẻ và truy vấn một lần là trình nghe tổng quan nhanh trong thời gian ngắn có các 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 hồi số lượng yêu cầu ghi ngày càng tăng.
Các nhật ký thay đổi của Cloud Firestore thúc đẩy các truy vấn theo thời gian thực sẽ tự động mở rộng theo chiều ngang khi lưu lượng truy cập ghi tăng lên. Vì tốc độ ghi của cơ sở dữ liệu tăng vượt quá khả năng xử lý của một máy chủ, nên nhật ký thay đổi sẽ được chia nhỏ 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 máy chủ. Từ góc độ của ứng dụng và SDK, mọi việc đều minh bạch và ứng dụng không cần làm gì cả 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 chuyển tỷ lệ cho phép bạn tăng lưu lượng ghi mà không có giới hạn. Tuy nhiên, 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 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 giúp 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ự đoán được, 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 theo lô, chẳng hạn như nhập một tập dữ liệu lớn, có thể tăng tốc độ ghi quá nhanh. Khi bạn thiết kế ứng dụng, hãy nắm bắ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 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ẽ truyền từ hệ thống lưu trữ sang các 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 sẽ 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 khi cơ sở dữ liệu cam kết các thay đổi về dữ liệu. 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 vi phạm 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 thao tác đọ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, quá trình đọc có thể 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 ứng đối với các truy vấn. Tránh các điểm phát sóng là chìa khoá để xử lý vấn đề này.
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 nhanh chóng nắm được các thay đổi về dữ liệu. Để đạt được mục tiêu này, hãy cố gắng làm những việc nhỏ gọn. Hệ thống có thể đẩy các tài liệu nhỏ có hàng chục trường qua hệ thống một cách rất nhanh. 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 xử lý hơn.
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ể cung cấp 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 mà bạn có thể 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 nhóm thu thập hoặc nhóm thu thập trên cùng một máy chủ nhật ký thay đổi. Hệ thống sẽ cố gắng tối đa hoá thông lượng ghi có thể đạt được trong khi vẫn giữ cho 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 dưới mức 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 bộ sưu tập lớn, thì trình nghe có thể cần phải 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 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 trình nghe mà không cần phải chuyển đến nhiều máy chủ. Cách tốt nhất là chia dữ liệu của bạn 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 một cơ sở dữ liệu quan hệ yêu cầu phải quét toàn bộ bảng. Trong một cơ sở dữ liệu quan hệ, một truy vấn yêu cầu quét toàn bộ bảng sẽ tương đương với trình nghe tổng quan nhanh theo dõi một tập hợp tỷ lệ rời bỏ cao. Nó 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. 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 tập hợp có ít thường xuyên 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 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 nhanh 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ả rồi gửi đến thiết bị của người dùng. Truy vấn chậm khiến ứng dụng của bạn ít phản hồi hơn. Ví dụ: những truy vấn này cố gắng đọc nhiều tài liệu hoặc truy vấn không sử dụng các chỉ mục phù 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 sang trạng thái thăm dò. Điều 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 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 các truy vấn thăm dò của bạn đủ nhanh, trạng thái thăm dò sẽ trở nên minh bạch đối với người dùng ứng dụng.
Ưu tiên người nghe nhạc dài lâu
Việc mở và duy trì hoạt động của trình nghe trong thời gian dài nhất có thể thường là cách tiết kiệm chi phí nhất để tạo một ứng dụng sử dụng Cloud Firestore. Khi sử dụng Cloud Firestore, bạn sẽ phải trả phí cho các tài liệu được trả về cho ứ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 dài hạn 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. Trong đó 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. Trong khi đó, truy vấn một lần sẽ đọ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 tổng quan 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, bạn nên chọn truy vấn một lần ở 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.