Hiểu các truy vấn thời gian thực ở quy mô lớn

Đọc tài liệu này để được hướng dẫn về cách mở rộng ứng dụng serverless 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 sâu hơn về hệ thống. Nếu bạn mới bắt đầu với Cloud Firestore, hãy xem hướng dẫn bắt đầu nhanh .

Cloud Firestore và SDK di động/web Firebase 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. SDK cho phép khách hàng lắng nghe các 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 đáp ứng 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 thứ gì đó, nhưng điều này sẽ giúp hiểu được các hạn chế trong 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 tốt khi lưu lượng truy cập tăng.

Xem các phần sau để đượ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 với người dùng của bạn

Sơ đồ sau đây thể hiện kiến ​​trúc của một ứng dụng thời gian thực:

Ví dụ về kiến ​​trúc ứng dụng 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 sẽ được chuyển đến máy chủ giao diện 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 , thì kết nối cũng sẽ chuyển đến giao diện Cloud Firestore cũng trong 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 lại một cách rõ ràng. Giao diện người dùng đọc dữ liệu từ hệ thống lưu trữ Cloud Firestore cơ bản.

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 Cloud Firestore ảnh hưởng đến độ trễ mà người dùng gặp phải. Ví dụ: người dùng ở Ấn Độ có ứng dụng tương tác với cơ sở dữ liệu trong 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 linh hoạt 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ế cho độ tin cậy

Các chủ đề sau cải thiện hoặc ảnh hưởng đến độ tin cậy của ứng dụng của bạn:

Bật chế độ ngoại tuyến

SDK Firebase cung cấp tính bền vững của 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 trong 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 mất quyền truy cập hoàn toàn 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 .

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 các kết nối bị hỏng. Điều này giúp khắc phục các lỗi nhất thời do 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 các vị trí khu vực và đa khu vực

Có một số sự cân bằng khi lựa chọn giữa các địa điểm trong khu vực và đa khu vực. Sự khác biệt chính là cách dữ liệu được sao chép. Điều này thúc đẩy sự đảm bảo về tính khả dụng của ứng dụng của bạn. Phiên bản đa khu vực mang lại độ tin cậy cung cấp cao hơn và tăng độ bền cho dữ liệu của bạn nhưng đổi lại là chi phí.

Hiểu hệ thống truy vấn thời gian thực

Truy vấn thời gian thực, còn được gọi là trình xử lý ảnh chụp nhanh, cho phép ứng dụng lắng nghe 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 thăm dò cơ sở dữ liệu định kỳ để tìm bản cập nhật, nhưng ứng dụng này thường chậm hơn, đắt 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 thời gian thực, hãy xem Nhận bản 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 xử lý ả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 thời gian thực trong khi 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 ứng dụng nhắn tin được xây dựng bằng một trong các SDK di động.

Khách hàng A ghi vào cơ sở dữ liệu để thêm và cập nhật tài liệu trong bộ sưu tập có tên chatroom :

collection chatroom:
    document message1:
      from: 'Sparky'
      message: 'Welcome to Cloud Firestore!'

    document message2:
      from: 'Santa'
      message: 'Presents are coming'

Khách hàng B lắng nghe các bản cập nhật trong cùng một bộ sưu tập bằng cách sử dụng trình nghe ảnh chụp nhanh. Khách hàng B nhận được thông báo ngay lập tức bất cứ khi nào ai đó tạo tin nhắn mới. Sơ đồ sau đây cho thấy kiến ​​trúc đằng sau trình nghe ảnh chụp nhanh:

Kiến trúc của kết nối 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:

  1. Ứng dụng khách B mở kết nối tới Cloud Firestore và đăng ký trình nghe bằng cách thực hiện lệnh gọi tới onSnapshot(collection("chatroom")) thông qua SDK Firebase. Người nghe này có thể duy trì hoạt động trong nhiều giờ.
  2. 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 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 bỏ phiếu . 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 dữ liệu này. Nếu người dùng được ủy quyền, cơ sở dữ liệu sẽ trả về dữ liệu cho người dùng.
  3. Truy vấn của Khách hàng B sau đó sẽ chuyển sang chế độ nghe . Trình nghe đăng ký với trình xử lý đăng ký và chờ cập nhật dữ liệu.
  4. Máy khách A hiện gửi thao tác ghi để sửa đổi tài liệu.
  5. Cơ sở dữ liệu cam kết thay đổi tài liệu vào hệ thống lưu trữ của nó.
  6. Về mặt giao dịch, hệ thống cam kết cập nhật tương 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.
  7. Nhật ký thay đổi lần lượt gửi dữ liệu đã cập nhật tới một nhóm trình xử lý đăng ký.
  8. Trình so khớp truy vấn ngược sẽ thực thi để xem liệu 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 Khách hàng B. Như tên ngụ ý, bạn có thể coi 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, nó sẽ tìm kiếm một cách hiệu quả thông qua các truy vấn để tìm những tài liệu phù hợp với tài liệu đến. Sau khi tìm thấy kết quả khớp, hệ thống sẽ chuyển tiếp tài liệu được đề cập đến người nghe ảnh chụp nhanh. Sau đó, hệ thống sẽ đánh giá Quy tắc bảo mật Firebase của cơ sở dữ liệu để đảm bảo rằng chỉ những người dùng được ủy quyền mới nhận được dữ liệu.
  9. Hệ thống chuyển tiếp bản cập nhật tài liệu tới SDK trên thiết bị của khách hàng B và lệnh gọi lại onSnapshot sẽ kích hoạt. Nếu tính năng lưu trữ cục bộ được bật thì 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 phân xuất từ ​​nhật ký thay đổi đến trình xử lý đăng ký và máy chủ giao diện người dùng. Phân xuất cho phép một thay đổi dữ liệu duy nhất được truyền đi một cách hiệu quả nhằm phục vụ hàng triệu truy vấn 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 vùng trong trường hợp triển khai nhiều vùng), Cloud Firestore đạt được tính sẵn sàng và khả năng mở rộng cao.

Điều đáng lưu ý là tất cả các hoạt động đọc được thực hiện từ SDK dành cho thiết bị di động và web đều tuân theo mô hình trên. Họ thực hiện truy vấn bỏ phiếu theo sau là chế độ nghe để duy trì sự đảm bảo tính nhất quán. Điều này cũng áp dụng cho trình nghe 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 việc truy xuất tài liệu đơn lẻ và truy vấn một lần giống như trình xử lý ảnh chụp nhanh 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 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 thời gian thực có thể mở rộng.

Hiểu 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 với số lượng yêu cầu ghi ngày càng tăng.

Nhật ký thay đổi của Cloud Firestore điều khiển các truy vấn thời gian thực sẽ tự động mở rộng theo chiều ngang khi lưu lượng ghi tăng lên. Khi tốc độ ghi 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 ra 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ý đăng ký thay vì một. Từ quan điểm của khách hàng và SDK, tất cả điều này đề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 sự phân chia. Sơ đồ sau đây minh họa quy mô truy vấn thời gian thực:

Kiến trúc của fan-out của nhật ký thay đổi

Tự động chia 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 lưu lượng truy cập tăng lên, hệ thống có thể mất mộ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 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ể đáp ứng mà không cần đề phòng. Tuy nhiên, 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 bạn thiết kế ứng dụng của mình, hãy lưu ý xem lưu lượng ghi của bạn đến từ đâu.

Hiểu cách viết và đọc tương tác

Bạn có thể coi hệ thống truy vấn thời gian thực như một đường dẫn kết nối các hoạt động ghi với người đọc. Bất cứ khi nào một tài liệu được tạo, cập nhật hoặc xóa, thay đổi sẽ được truyền từ hệ thống lưu trữ đến những người 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, có 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 đúng thứ tự so với khi cơ sở dữ liệu cam kết thay đổi dữ liệu. Điều này giúp đơn giản hóa việc phát triển ứng dụng bằng cách loại bỏ các trường hợp khó khăn xung quanh tính nhất quán của dữ liệu.

Đường dẫn được kết nối này có nghĩa là thao tác ghi gây ra xung đột điểm nóng hoặc khóa 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 sự cố điều tiết, quá trình đọc có thể bị đình trệ 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 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 cho các truy vấn. Tránh các điểm nóng là chìa khóa để tránh xa vấn đề này.

Giữ tài liệu và thao tác viết ở mức nhỏ

Khi xây dựng ứng dụng bằng trình xử lý ả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ữ mọi thứ nhỏ nhặt. Hệ thống có thể đẩy các tài liệu nhỏ với 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ự như vậy, hãy ưu tiên các thao tác ghi và cam kết ngắn, nhanh để giữ độ trễ ở mức thấp. Theo quan điểm của người viết, các lô lớn có thể mang lại cho bạn thông lượng cao hơn nhưng thực tế có thể tăng thời gian thông báo cho người nghe ảnh chụp nhanh. Điều này thường phản trực giác 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ể sử dụng tính năng tạo khối để cải thiện hiệu suất.

Sử dụng người nghe hiệu quả

Khi tốc độ ghi 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 sharding của Cloud Firestore cố gắ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. Hệ thống cố gắng tối đa hóa thông lượng ghi có thể có trong khi vẫn giữ số lượng máy chủ tham gia 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 dưới mức 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, 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. 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ế lược đồ và ứng dụng của bạn để hệ thống có thể phục vụ người nghe mà không cần đến nhiều máy chủ khác nhau. Tốt nhất nên chia dữ liệu của bạn 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ư 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 bộ sưu tập có tỷ lệ rời bỏ cao. Nó 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 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ư trình nghe ảnh chụp nhanh xem một tài liệu hoặc một bộ sưu tập ít thay đổi hơn. Bạn nên tải thử nghiệm ứng dụng của mình để hiểu rõ nhất hành vi và nhu cầu của trường hợp sử dụng của bạn.

Duy trì truy vấn bỏ phiếu nhanh chóng

Một phần quan trọng khác của truy vấn thời gian thực đáp ứng liên quan đến việc đảm bảo rằng truy vấn thăm dò để khởi động dữ liệu nhanh và hiệu quả. Lần đầu tiên 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. Truy vấn chậm làm cho ứ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 các truy vấn không sử dụng chỉ mục thích hợp.

Người nghe cũng có thể chuyển từ trạng thái nghe sang trạng thái bỏ phiếu 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 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 bỏ phiếu:

  • Hệ thống cân bằng lại nhật ký thay đổi do thay đổi tải.
  • Điểm phát sóng gây ra lỗi 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 người nghe.

Nếu truy vấn thăm dò của bạn đủ nhanh thì 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 những người nghe lâu năm

Mở và giữ chân người nghe lâu nhất có thể thường là cách tiết kiệm chi phí nhất để 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 chỉ đọc dữ liệu cần thiết để phục vụ truy vấn trong suốt vòng đời của nó. Điều này bao gồm hoạt động bỏ phiếu ban đầu, 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 cuối ứng dụng thực hiện 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 xử lý ả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ì tốt hơn nên chọn truy vấn một lần chạy ở tần suất thấp hơn.

Cái gì tiếp theo