Hãy đọc tài liệu này để đưa ra quyết định sáng suốt về việc thiết kế cấu trúc ứng dụng nhằm mang lại hiệu suất và độ tin cậy cao. Tài liệu này trình bày các chủ đề nâng cao về Cloud Firestore. 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 là một cơ sở dữ liệu linh hoạt, có thể mở rộng dùng để phát triển cho thiết bị di động, web và máy chủ của Firebase và Google Cloud. Bạn có thể dễ dàng bắt đầu sử dụng Cloud Firestore để viết những ứng dụng phong phú và mạnh mẽ.
Để đảm bảo các ứng dụng tiếp tục hoạt động hiệu quả khi kích thước cơ sở dữ liệu và lưu lượng truy cập tăng lên, bạn nên nắm được cơ chế đọc và ghi trong phần phụ trợ của Cloud Firestore. Bạn cũng phải hiểu về hoạt động tương tác của thao tác đọc và ghi với lớp lưu trữ cũng như những hạn chế cơ bản có thể ảnh hưởng đến hiệu suất.
Hãy xem các phần sau đây để biết các phương pháp hay nhất trước khi thiết kế cấu trúc cho ứng dụng của bạn.
Tìm hiểu các thành phần cấp cao
Sơ đồ dưới đây cho thấy các thành phần cấp cao liên quan đến một yêu cầu API Cloud Firestore.
SDK Cloud Firestore và thư viện ứng dụng
Cloud Firestore hỗ trợ SDK và thư viện ứng dụng cho nhiều nền tảng. Mặc dù ứng dụng có thể thực hiện lệnh gọi HTTP và RPC trực tiếp đến Cloud Firestore API, nhưng thư viện ứng dụng cung cấp một lớp trừu tượng để đơn giản hoá việc sử dụng API và triển khai các phương pháp hay nhất. Họ cũng có thể cung cấp các tính năng bổ sung như truy cập ngoại tuyến, bộ nhớ đệm, v.v.
Giao diện người dùng của Google (GFE)
Đây là một dịch vụ cơ sở hạ tầng dùng chung cho tất cả các dịch vụ đám mây của Google. GFE chấp nhận các yêu cầu được gửi đến và chuyển tiếp chúng đến dịch vụ có liên quan của Google (dịch vụ Firerestore trong trường hợp này). Nền tảng này cũng cung cấp các chức năng quan trọng khác, bao gồm cả khả năng bảo vệ khỏi các cuộc tấn công Từ chối dịch vụ.
Dịch vụ Cloud Firestore
Dịch vụ Cloud Firestore thực hiện các hoạt động kiểm tra đối với yêu cầu API, bao gồm cả quá trình xác thực, uỷ quyền, kiểm tra hạn mức và các quy tắc bảo mật, đồng thời cũng quản lý giao dịch. Dịch vụ Cloud Firestore này bao gồm một ứng dụng lưu trữ tương tác với lớp lưu trữ để đọc và ghi dữ liệu.
Lớp bộ nhớ Cloud Firestore
Lớp bộ nhớ trên Cloud Firestore chịu trách nhiệm lưu trữ cả dữ liệu lẫn siêu dữ liệu, cũng như các tính năng liên quan đến cơ sở dữ liệu do Cloud Firestore cung cấp. Các phần sau đây mô tả cách sắp xếp dữ liệu trong lớp bộ nhớ trên Cloud Firestore và cách hệ thống điều chỉnh quy mô. Việc tìm hiểu cách sắp xếp dữ liệu có thể giúp bạn thiết kế một mô hình dữ liệu có thể mở rộng, đồng thời hiểu rõ hơn về các phương pháp hay nhất trong Cloud Firestore.
Phạm vi và độ tách chính
Cloud Firestore là một cơ sở dữ liệu NoSQL, hướng tài liệu. Bạn lưu trữ dữ liệu trong tài liệu, được sắp xếp theo thứ bậc của bộ sưu tập. Hệ thống phân cấp bộ sưu tập và mã nhận dạng tài liệu được dịch sang một khoá duy nhất cho mỗi tài liệu. Tài liệu được lưu trữ và sắp xếp theo thứ tự từ điển một cách hợp lý bằng khoá duy nhất này. Chúng tôi sử dụng phạm vi khoá thuật ngữ để đề cập đến một phạm vi các phím liền kề từ vựng.
Một cơ sở dữ liệu điển hình của Cloud Firestore quá lớn nên không vừa với một thiết bị thực. Cũng có những trường hợp khối lượng công việc trên dữ liệu quá lớn nên một máy không xử lý được. Để xử lý tải công việc lớn, Cloud Firestore phân vùng dữ liệu thành nhiều phần riêng biệt có thể lưu trữ và phân phát từ nhiều máy hoặc máy chủ lưu trữ. Những phân vùng này được tạo trên bảng cơ sở dữ liệu trong các khối dải ô khoá được gọi là phần phân tách.
Sao chép đồng bộ
Điều quan trọng cần lưu ý là cơ sở dữ liệu luôn được sao chép một cách tự động và đồng bộ. Việc phân chia dữ liệu có bản sao ở nhiều vùng khác nhau để luôn có thể truy cập ngay cả khi một vùng không thể truy cập được. Việc sao chép nhất quán các bản sao khác nhau của phần phân tách được quản lý bằng thuật toán Paxos để lấy sự đồng thuận. Một bản sao của từng phần phân tách được chọn để làm trưởng nhóm Paxos, chịu trách nhiệm xử lý việc ghi vào phần phân tách đó. Việc sao chép đồng bộ giúp bạn luôn đọc được phiên bản dữ liệu mới nhất từ Cloud Firestore.
Kết quả chung của việc này là một hệ thống có thể mở rộng và có khả năng hoạt động cao, cung cấp độ trễ thấp cho cả thao tác đọc và ghi, bất kể khối lượng công việc lớn và ở quy mô rất lớn.
Bố cục dữ liệu
Cloud Firestore là một cơ sở dữ liệu tài liệu không có giản đồ. Tuy nhiên, nội bộ trình bày dữ liệu chủ yếu trong hai bảng kiểu cơ sở dữ liệu quan hệ trong lớp lưu trữ như sau:
- Bảng Chứng từ: Chứng từ được lưu trữ trong bảng này.
- Bảng Chỉ mục: Các mục nhập chỉ mục có thể giúp bạn nhận kết quả một cách hiệu quả và được sắp xếp theo giá trị chỉ mục được lưu trữ trong bảng này.
Sơ đồ dưới đây cho thấy các bảng của cơ sở dữ liệu Cloud Firestore trông như thế nào khi có các phần phân tách. Các phần phân tách được sao chép ở 3 vùng khác nhau và mỗi phần được chỉ định một trưởng nhóm Paxos.
Một khu vực so với nhiều khu vực
Khi tạo cơ sở dữ liệu, bạn phải chọn một vùng hoặc nhiều vùng.
Vị trí khu vực duy nhất là một vị trí địa lý cụ thể, chẳng hạn như us-west1. Các phần phân tách dữ liệu của cơ sở dữ liệu Cloud Firestore có các bản sao ở nhiều vùng trong khu vực đã chọn, như đã giải thích trước đó.
Một vị trí nhiều vùng bao gồm một nhóm khu vực xác định, nơi lưu trữ các bản sao của cơ sở dữ liệu. Trong quá trình triển khai Cloud Firestore trên nhiều khu vực, hai trong số các khu vực đó sẽ có bản sao đầy đủ của toàn bộ dữ liệu trong cơ sở dữ liệu. Khu vực thứ ba có bản sao nhân chứng không duy trì tập dữ liệu đầy đủ mà tham gia vào quá trình sao chép. Bằng cách sao chép dữ liệu giữa nhiều khu vực, dữ liệu có thể được ghi và đọc ngay cả khi một khu vực bị mất toàn bộ.
Để biết thêm thông tin về vị trí của một khu vực, hãy xem bài viết các vị trí trong Cloud Firestore.
Tìm hiểu vòng đời của một lượt ghi trong Cloud Firestore
Ứng dụng Cloud Firestore có thể ghi dữ liệu bằng cách tạo, cập nhật hoặc xoá một tài liệu. Để ghi vào một tài liệu, bạn phải cập nhật từng tài liệu và các mục nhập chỉ mục liên kết trong lớp lưu trữ. Cloud Firestore cũng hỗ trợ các thao tác atom bao gồm nhiều lượt đọc và/hoặc ghi vào một hoặc nhiều tài liệu.
Đối với mọi loại hoạt động ghi, Cloud Firestore cung cấp các thuộc tính ACID (tính nguyên tử, tính nhất quán, tính tách biệt và độ bền vững) của cơ sở dữ liệu quan hệ. Cloud Firestore cũng cung cấp khả năng chuyển đổi tuần tự, tức là mọi giao dịch sẽ xuất hiện như thể được thực thi theo thứ tự nối tiếp.
Các bước cấp cao trong giao dịch ghi
Khi ứng dụng Cloud Firestore đưa ra yêu cầu ghi hoặc xác nhận một giao dịch, bằng cách sử dụng bất kỳ phương thức nào nêu trên, nội bộ này sẽ được thực thi nội bộ dưới dạng một giao dịch đọc-ghi cơ sở dữ liệu trong lớp lưu trữ. Giao dịch này cho phép Cloud Firestore cung cấp các tài sản ACID đã đề cập trước đó.
Trong bước đầu tiên của một giao dịch, Cloud Firestore đọc tài liệu hiện có và xác định các trường hợp thay đổi dữ liệu cần thực hiện đối với dữ liệu trong bảng Documents (Tài liệu).
Ngoài ra, bạn cũng cần cập nhật những điểm cần thiết cho bảng Chỉ mục như sau:
- Trường đang được thêm vào tài liệu cần có phần chèn tương ứng trong bảng Chỉ mục.
- Các trường đang bị xoá khỏi tài liệu cần được xoá tương ứng trong bảng Chỉ mục.
- Các trường đang được sửa đổi trong tài liệu cần phải xoá cả (đối với giá trị cũ) và chèn (đối với giá trị mới) trong bảng Chỉ mục.
Để tính toán các trường hợp đột biến được đề cập trước đó, Cloud Firestore sẽ đọc cấu hình lập chỉ mục của dự án. Cấu hình lập chỉ mục lưu trữ thông tin về các chỉ mục cho một dự án. Cloud Firestore sử dụng hai loại chỉ mục: một trường đơn và một trường tổng hợp. Để hiểu chi tiết về các chỉ mục được tạo trong Cloud Firestore, hãy xem bài viết Các loại chỉ mục trong Cloud Firestore.
Sau khi tính toán các trường hợp đột biến, Cloud Firestore sẽ thu thập chúng trong một giao dịch rồi xác nhận thông tin đó.
Tìm hiểu về giao dịch ghi trong lớp lưu trữ
Như đã thảo luận trước đó, việc ghi trong Cloud Firestore liên quan đến giao dịch đọc-ghi trong lớp lưu trữ. Tuỳ thuộc vào bố cục dữ liệu, một lượt ghi có thể liên quan đến một hoặc nhiều phần phân tách như trong bố cục dữ liệu.
Trong sơ đồ dưới đây, cơ sở dữ liệu Cloud Firestore có 8 phần (được đánh dấu từ 1 đến 8) được lưu trữ trên 3 máy chủ lưu trữ khác nhau trong cùng một vùng, và mỗi phần được chia thành 3 vùng khác nhau. Mỗi phần phân chia có một trưởng nhóm Paxos, có thể ở một vùng khác nhau cho các phần phân chia khác nhau.
Hãy xem xét cơ sở dữ liệu Cloud Firestore có tập hợp Restaurants như sau:
Ứng dụng Cloud Firestore yêu cầu thay đổi sau đây đối với một tài liệu trong tập hợp Restaurant bằng cách cập nhật giá trị của trường priceCategory.
Các bước cấp cao sau đây mô tả những gì sẽ xảy ra trong quá trình ghi:
- Tạo một giao dịch đọc-ghi.
- Đọc tài liệu
restaurant1trong bộ sưu tậpRestaurantstừ bảng Tài liệu từ lớp lưu trữ. - Đọc các chỉ mục cho tài liệu từ bảng Chỉ mục.
- Tính các đột biến cần thực hiện cho dữ liệu. Trong trường hợp này, sẽ có 5 trường hợp đột biến:
- M1: Cập nhật hàng cho
restaurant1trong bảng Tài liệu để phản ánh thay đổi về giá trị của trườngpriceCategory. - M2 và M3: Xoá các hàng chứa giá trị cũ của
priceCategorytrong bảng Chỉ mục cho chỉ số tăng dần và giảm dần. - M4 và M5: Chèn các hàng cho giá trị mới của
priceCategorytrong bảng Chỉ mục cho chỉ mục giảm dần và tăng dần.
- M1: Cập nhật hàng cho
- Xác nhận những thay đổi này.
Ứng dụng lưu trữ trong dịch vụ Cloud Firestore tra cứu các phần phân tách có khoá của các hàng cần thay đổi. Hãy xem xét trường hợp Split 3 phân phát M1 và Split 6 phân phát M2-M5. Một giao dịch được phân phối liên quan đến tất cả các phần phân tách này với tư cách là người tham gia. Phần phân tách của người tham gia cũng có thể bao gồm bất kỳ phần phân tách nào khác mà dữ liệu được đọc trước đó từ đó trong giao dịch đọc-ghi.
Các bước sau đây mô tả những gì sẽ xảy ra trong quá trình cam kết:
- Ứng dụng lưu trữ đưa ra một cam kết. Cam kết chứa các đột biến M1-M5.
- Giai đoạn 3 và 6 là những người tham gia giao dịch này. Một trong những người tham gia được chọn làm điều phối viên, chẳng hạn như Phân chia 3. Nhiệm vụ của điều phối viên là đảm bảo giao dịch thực hiện hoặc huỷ bỏ nguyên tử giữa tất cả những người tham gia.
- Bản sao người lãnh đạo của những phần phân chia này chịu trách nhiệm về công việc mà người tham gia và điều phối viên thực hiện.
- Mỗi người tham gia và điều phối viên sẽ chạy một thuật toán Paxos với các bản sao tương ứng của họ.
- Trưởng nhóm chạy thuật toán Paxos với các bản sao. Quorum đạt được nếu hầu hết các bản sao trả lời bằng phản hồi
ok to commitcho thủ lĩnh. - Sau đó, mỗi người tham gia sẽ thông báo cho điều phối viên khi họ đã chuẩn bị (giai đoạn đầu tiên của cam kết hai giai đoạn). Nếu người tham gia không thể cam kết thực hiện giao dịch thì toàn bộ giao dịch sẽ
aborts.
- Trưởng nhóm chạy thuật toán Paxos với các bản sao. Quorum đạt được nếu hầu hết các bản sao trả lời bằng phản hồi
- Sau khi biết tất cả những người tham gia (kể cả bản thân) đã sẵn sàng, điều phối viên sẽ thông báo kết quả giao dịch
acceptcho tất cả những người tham gia (giai đoạn thứ hai của cam kết 2 giai đoạn). Trong giai đoạn này, mỗi người tham gia ghi lại quyết định cam kết về bộ nhớ ổn định và giao dịch được cam kết. - Điều phối viên trả lời ứng dụng lưu trữ trong Cloud Firestore rằng giao dịch đã được cam kết. Đồng thời, điều phối viên và tất cả những người tham gia sẽ áp dụng các trường hợp đột biến cho dữ liệu.
Khi cơ sở dữ liệu Cloud Firestore có kích thước nhỏ, có thể xảy ra việc một phần phân tách sở hữu tất cả các khoá trong các trường hợp đột biến M1-M5. Trong trường hợp này, chỉ có một người tham gia trong giao dịch và hoạt động xác nhận 2 giai đoạn nêu trên là không cần thiết, giúp việc ghi nhanh hơn.
Ghi trong nhiều vùng
Trong quá trình triển khai trên nhiều khu vực, việc mở rộng bản sao giữa các khu vực sẽ làm tăng phạm vi cung cấp, nhưng đi kèm với chi phí hiệu suất. Quá trình liên lạc giữa các bản sao ở những khu vực khác nhau mất nhiều thời gian khứ hồi hơn. Do đó, độ trễ cơ sở khi vận hành trên Cloud Firestore cao hơn một chút so với việc triển khai ở một khu vực.
Chúng tôi thiết lập các bản sao sao cho người lãnh đạo đối với các phần phân chia luôn nằm ở khu vực chính. Khu vực chính là khu vực dẫn đến lưu lượng truy cập đến máy chủ Cloud Firestore. Quyết định này của ban lãnh đạo giúp giảm độ trễ trọn vòng trong việc liên lạc giữa ứng dụng lưu trữ trong Cloud Firestore và ứng dụng quản lý bản sao (hoặc điều phối viên đối với các giao dịch nhiều phần).
Mỗi lượt ghi trong Cloud Firestore cũng bao gồm một số hoạt động tương tác với công cụ theo thời gian thực trong Cloud Firestore. Để biết thêm thông tin về truy vấn theo thời gian thực, hãy xem bài viết Tìm hiểu về truy vấn theo thời gian thực trên quy mô lớn.
Tìm hiểu vòng đời của một lượt đọc trong Cloud Firestore
Phần này tìm hiểu sâu về các lượt đọc độc lập, không theo thời gian thực trong Cloud Firestore. Trong nội bộ, máy chủ Cloud Firestore xử lý hầu hết các truy vấn này theo 2 giai đoạn chính:
- Quét một dải ô trên bảng Chỉ mục
- Tra cứu điểm trong bảng Tài liệu dựa trên kết quả của lần quét trước đó
Việc đọc dữ liệu từ lớp lưu trữ được thực hiện nội bộ bằng cách sử dụng giao dịch cơ sở dữ liệu để đảm bảo số lần đọc nhất quán. Tuy nhiên, không giống như các giao dịch được dùng để ghi, những giao dịch này không sử dụng khoá. Thay vào đó, các thẻ này hoạt động bằng cách chọn một dấu thời gian, sau đó thực thi tất cả các lượt đọc tại dấu thời gian đó. Vì không có khoá, nên chúng không chặn các giao dịch đọc-ghi đồng thời. Để thực thi giao dịch này, ứng dụng lưu trữ trong Cloud Firestore chỉ định một giới hạn dấu thời gian. Giới hạn này cho tầng lưu trữ biết cách chọn dấu thời gian đọc. Loại giới hạn dấu thời gian mà ứng dụng lưu trữ trong Cloud Firestore lựa chọn được xác định bằng các tuỳ chọn đọc cho yêu cầu Đọc.
Hiểu giao dịch đọc trong lớp lưu trữ
Phần này mô tả các loại lượt đọc và cách chúng được xử lý trong lớp lưu trữ trên Cloud Firestore.
Số lượt đọc mạnh mẽ
Theo mặc định, số liệu đọc trên Cloud Firestore rất nhất quán. Tính nhất quán mạnh mẽ này đồng nghĩa với việc một lượt đọc trên Cloud Firestore sẽ trả về phiên bản mới nhất của dữ liệu phản ánh tất cả các lượt ghi đã được xác nhận cho đến khi bắt đầu quá trình đọc.
Đọc trong một phần
Ứng dụng lưu trữ trong Cloud Firestore tra cứu các phần phân tách sở hữu khoá của các hàng cần đọc. Giả sử cần đọc phần Phân tách 3 ở phần trước. Ứng dụng gửi yêu cầu đọc tới bản sao gần nhất để giảm độ trễ trọn vòng.
Tại thời điểm này, các trường hợp sau có thể xảy ra tuỳ thuộc vào bản sao đã chọn:
- Yêu cầu đọc được chuyển đến bản sao của biến thể dẫn đầu (Khu vực A).
- Vì người lãnh đạo luôn cập nhật thông tin mới nhất, nên việc đọc có thể tiến hành ngay.
- Yêu cầu đọc được chuyển đến một bản sao không phải trưởng nhóm (chẳng hạn như Khu vực B)
- Tuỳ vào trạng thái nội bộ, Split 3 có thể biết rằng nó có đủ thông tin để phân phát hoạt động đọc và quá trình phân tách sẽ thực hiện việc này.
- Tách 3 không chắc chắn đã thấy dữ liệu mới nhất hay chưa. Nó gửi tin nhắn cho nhà lãnh đạo để yêu cầu cung cấp dấu thời gian của giao dịch gần nhất mà nó cần áp dụng để phục vụ việc đọc. Sau khi giao dịch đó được áp dụng, việc đọc có thể tiếp tục.
Sau đó, Cloud Firestore sẽ trả về phản hồi cho ứng dụng của mình.
Đọc từng phần
Trong trường hợp việc đọc phải được thực hiện từ nhiều phần phân tách, cơ chế tương tự sẽ xảy ra trên tất cả các phần phân tách. Sau khi dữ liệu được trả về từ tất cả các phần phân tách, ứng dụng lưu trữ trong Cloud Firestore sẽ kết hợp các kết quả. Sau đó, Cloud Firestore sẽ phản hồi ứng dụng khách bằng dữ liệu này.
Số lượt đọc cũ
Đọc mạnh là chế độ mặc định trong Cloud Firestore. Tuy nhiên, việc này khiến độ trễ tiềm ẩn cao hơn do có thể bắt buộc phải giao tiếp với trưởng nhóm. Thông thường, ứng dụng Cloud Firestore của bạn không cần đọc phiên bản dữ liệu mới nhất và chức năng này hoạt động tốt với những dữ liệu có thể lỗi thời vài giây.
Trong trường hợp như vậy, ứng dụng có thể chọn nhận các lần đọc cũ bằng cách sử dụng tuỳ chọn đọc read_time. Trong trường hợp này, việc đọc được thực hiện như dữ liệu tại read_time và bản sao gần nhất có nhiều khả năng đã xác minh rằng nó có dữ liệu tại read_time được chỉ định.
Để có hiệu suất tốt hơn đáng kể, 15 giây là giá trị thời gian lỗi hợp lý. Ngay cả đối với các lần đọc cũ, các hàng mang lại vẫn nhất quán với nhau.
Tránh các điểm phát sóng
Các phần phân chia trong Cloud Firestore sẽ tự động được chia thành các phần nhỏ hơn để phân phối lưu lượng truy cập đến nhiều máy chủ lưu trữ hơn khi cần hoặc khi không gian khoá mở rộng. Các mức phân tách được tạo để xử lý lưu lượng truy cập vượt quá sẽ được giữ lại trong khoảng 24 giờ ngay cả khi lưu lượng truy cập biến mất. Vì vậy, nếu có mức tăng đột biến về lưu lượng truy cập định kỳ, các phần phân tách sẽ được duy trì và đưa ra nhiều phần phân tách hơn mỗi khi cần. Những cơ chế này giúp cơ sở dữ liệu của Cloud Firestore tự động mở rộng quy mô khi tải lưu lượng truy cập hoặc kích thước cơ sở dữ liệu tăng lên. Tuy nhiên, có một số giới hạn cần lưu ý như được giải thích bên dưới.
Việc chia nhỏ bộ nhớ và tải sẽ mất nhiều thời gian. Trong khi đó, việc tăng lưu lượng truy cập quá nhanh có thể gây ra lỗi có độ trễ cao hoặc vượt quá thời hạn (thường được gọi là điểm nóng trong khi dịch vụ sẽ điều chỉnh). Phương pháp hay nhất là phân phối các thao tác trên dải khoá, đồng thời tăng cường lưu lượng truy cập trên một tập hợp trong cơ sở dữ liệu có 500 thao tác mỗi giây. Sau khi tăng dần mức này, hãy tăng lưu lượng truy cập lên tối đa 50% mỗi 5 phút. Quá trình này được gọi là quy tắc 500/50/5 và định vị cơ sở dữ liệu để mở rộng quy mô một cách tối ưu nhằm đáp ứng khối lượng công việc của bạn.
Mặc dù quá trình phân tách được tạo tự động khi tải trọng tăng lên, nhưng Cloud Firestore chỉ có thể phân chia một phạm vi khoá cho đến khi phân phối một tài liệu bằng cách sử dụng một nhóm máy chủ lưu trữ nhân bản chuyên dụng. Do đó, số lượng lớn và liên tục các thao tác đồng thời trên một tài liệu có thể dẫn đến một điểm tương tác trên tài liệu đó. Nếu bạn gặp phải độ trễ cao được duy trì trên một tài liệu, bạn nên xem xét việc sửa đổi mô hình dữ liệu để chia nhỏ hoặc sao chép dữ liệu trên nhiều tài liệu.
Lỗi tranh chấp xảy ra khi nhiều thao tác cố đọc và/hoặc viết cùng một tài liệu cùng lúc.
Một trường hợp đặc biệt khác của điểm tương tác xảy ra khi một phím tăng/giảm tuần tự được dùng làm mã nhận dạng tài liệu trong Cloud Firestore và có một lượng thao tác lớn đáng kể mỗi giây. Việc tạo thêm phần phân tách không có tác dụng vì mức tăng đột biến của lưu lượng truy cập chỉ chuyển sang phần phân tách mới được tạo. Vì Cloud Firestore tự động lập chỉ mục tất cả các trường trong tài liệu theo mặc định, nên những điểm phát sóng di động như vậy cũng có thể được tạo trên không gian chỉ mục cho trường tài liệu có chứa giá trị tăng/giảm tuần tự như dấu thời gian.
Lưu ý: Khi làm theo các phương pháp nêu trên, Firestore có thể mở rộng quy mô để phục vụ các tải công việc lớn tuỳ ý mà bạn không cần phải điều chỉnh cấu hình.
Khắc phục sự cố
Firestore cung cấp Key Visualr dưới dạng một công cụ chẩn đoán được thiết kế đặc biệt để phân tích thói quen sử dụng và khắc phục sự cố về điểm phát sóng.
Bước tiếp theo
- Đọc thêm về các phương pháp hay nhất
- Tìm hiểu về truy vấn theo thời gian thực trên quy mô lớn