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 phi 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 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à Firebase SDK 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 này cho phép máy khách theo dõi các bản cập nhật 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 để 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 hạn chế trong những 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 với người dùng của bạn
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 này sẽ được định tuyến đến một 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 đượ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 giao diện người dùng Cloud Firestore cũng ở 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ừ 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 tại 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 nằm ở vị trí 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 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 khả 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 bằng cách hoạt động với dữ liệu được lưu vào bộ nhớ đệm cục bộ. Điều này đảm bảo người dùng có thể truy cập vào dữ liệu ngay cả khi kết nối Internet không ổn định hoặc hoàn toàn mất kết nối 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
Các SDK Firebase sẽ đảm nhiệm việc 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 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à 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 dữ liệu được sao chép. Điều này giúp đảm bảo tính sẵn có của ứng dụng. Một phiên bản đ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 nhược điểm 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 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. Một ứ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 nội dung cập nhật, nhưng thường thì cách này sẽ 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 đây sẽ đi vào chi tiết về cách hoạt động của trình nghe dữ liệu nhanh và mô tả một số phương pháp hay nhất để mở rộng quy mô các 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 có 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.
Client 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 các nội dung cập nhật trong cùng một tập hợp bằng trình nghe dữ liệu tức thời. Ứng dụng B sẽ 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 một trình nghe ảnh chụp nhanh:
Trình tự các sự kiện sau đây diễn ra khi Client B kết nối một 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ý 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ể 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. Thao tác này sẽ tải toàn bộ tậ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ò. Sau đó, hệ thống sẽ đánh giá Các 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 một trình xử lý gói thuê bao và chờ dữ liệu cập nhật.
- Giờ đây, ứng dụng A sẽ gửi một thao tác ghi để sửa đổi một 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 cơ sở dữ liệu.
- Về mặt giao dịch, hệ thống cam kết cùng một nội dung 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 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ý đăng ký.
- 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 này khớp với trình nghe ảnh chụp nhanh của Client B. Như tên gọi, bạn có thể coi bộ 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 hướng 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, tính nă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. Khi tìm thấy một kết quả trùng khớp, hệ thống sẽ chuyển tiếp tài liệu được đề cập đến các trình nghe ảnh chụp nhanh. Sau đó, hệ thống sẽ đánh giá Các quy tắc bảo mật của Firebase của cơ sở dữ liệu để đảm bảo 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 B và lệnh gọi lại
onSnapshotsẽ kích hoạt. Nếu bạn bật tính năng duy 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 việc phân phối từ nhật ký thay đổi đến các trình xử lý đăng ký và máy chủ giao diện người dùng. Tính năng phân phối 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 nhiều khu vực), Cloud Firestore đạt được khả năng hoạt động và khả năng mở rộng 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. Chúng thực hiện một truy vấn thăm dò ý kiến, sau đó là chế độ nghe để duy trì các đảm bảo về tính nhất quán. Quy tắc 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 việc truy xuất một tài liệu và truy vấn một lần là các trình nghe ảnh chụp nhanh tồn tại trong thời gian ngắn, đi kèm với 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ế các truy vấn có thể mở rộng theo thời gian thực.
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.
Các nhật ký thay đổi Cloud Firestore điều khiển 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. Khi tốc độ ghi cho một cơ sở dữ liệu tăng lên 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ý đăng ký thay vì chỉ 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 thực hiện hành động nào khi các phần tách xảy ra. 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 mở rộng quy mô cho phép bạn tăng lưu lượng 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 tuân theo các đề xuất của quy tắc 5-5-5 để tránh tạo điểm ghi nóng. 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 có thể 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ô 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 các thao tác 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 người đọc. Mỗi khi 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ữ đến 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 thời điểm cơ sở dữ liệu cam kết 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 biên liên quan đến tính nhất quán của dữ liệu.
Đường dẫn kết nối này có nghĩa là một thao tác ghi gây ra các điểm truy cập 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 gặp phải tình trạng điều tiết, thao tác đọc có thể bị tạm dừng để 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, thì 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 tương quan cho các truy vấn. Tránh các điểm nóng là cách chính để tránh gặp phải vấn đề này.
Giữ cho các thao tác ghi và tài liệu có kích thước nhỏ
Khi tạo ứ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 biết được các thay đổi về dữ liệu. Để làm đượ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. Các tài liệu lớ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 ghi và xác nhận nhanh, ngắn để 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 theo quan điểm của trình ghi, nhưng trên thực tế, điều này có thể làm tăng thời gian thông báo cho các 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 đoạn của Cloud Firestore cố gắng đồng định vị dữ liệu từ cùng một tập hợp hoặc nhóm tập hợ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ý một 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 các 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 của bạn sao cho hệ thống có thể phân phát các trình nghe mà không cần truy cập vào nhiều máy chủ khác nhau. Bạn nên 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 xem xét các truy vấn hiệu suất trong cơ sở dữ liệu quan hệ cần 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ốc độ thay đổi cao. Truy vấn này có thể thực hiện chậm hơn so với một 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ư một trình nghe ảnh chụp nhanh theo dõi một tài liệu duy nhất hoặc một tập hợp ít thay đổi hơn. Bạn nên tải và 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ì tốc độ truy vấn nhanh
Một phần quan trọng khác của truy vấn phản hồi theo thời gian thực là đảm bảo rằng truy vấn thăm dò để khởi động dữ liệu diễn ra nhanh chóng và hiệu quả. Vào 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 tậ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 ít phản hồi hơn. Ví dụ: những truy vấn cố gắng đọc nhiều tài liệu hoặc những truy vấn không sử dụng 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ò. Quá trình này diễn ra tự động và không ảnh hưởng đến 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 có sự thay đổi về tải.
- Điểm truy cập gây ra lỗi hoặc trì hoãn việc 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 các trình 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 của bạn.
Ưu tiên trình nghe tồn tại lâu dài
Việc mở và duy trì các trình nghe hoạt động càng lâu càng tốt 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ẽ 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ì một kết nối đang 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 của truy vấn. Điều này bao gồm một thao tác 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, cá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 sử dụng tốc độ dữ liệu cao, thì 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 dữ liệu tổng quan nhanh.
- Đọc thêm về các phương pháp hay nhất.