Hiểu rõ về số lượt đọc và ghi trên quy mô lớn

Hãy đọc tài liệu này để đưa ra quyết định sáng suốt về việc thiết kế ứng dụng nhằm đạt được hiệu suất cao và độ tin cậy. Tài liệu này bao gồm các chủ đề Cloud Firestore nâng cao. 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.

Cloud Firestore là một cơ sở dữ liệu linh hoạt, có thể mở rộng để phát triển thiết bị di động, web và máy chủ từ Firebase và Google Cloud. Bạn có thể dễ dàng bắt đầu sử dụng Cloud Firestore và viết các ứng dụng phong phú và mạnh mẽ.

Để đảm bảo rằng ứng dụng của bạn 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 cần hiểu rõ cơ chế đọc và ghi trong phần phụ trợ Cloud Firestore. Bạn cũng phải hiểu rõ hoạt động tương tác của các hoạt động đọc và ghi với lớp bộ nhớ cũng như các quy tắc ràng buộc 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ế ứng dụng.

Tìm hiểu các thành phần cấp cao

Sơ đồ sau đây cho thấy các thành phần cấp cao liên quan đến yêu cầu API Cloud Firestore.

Thành phần cấp cao

Cloud Firestore SDK 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 các lệnh gọi HTTP và RPC trực tiếp đến API Cloud Firestore, 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. Các ứng dụng này cũng có thể cung cấp các tính năng bổ sung như truy cập khi không có mạng, bộ nhớ đệm, v.v.

Google Front End (GFE)

Đây là dịch vụ cơ sở hạ tầng phổ biến 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 đến và chuyển tiếp các yêu cầu đó đến dịch vụ có liên quan của Google (dịch vụ Cloud Firestore trong ngữ cảnh này). API này cũng cung cấp các chức năng quan trọng khác, bao gồm cả tính năng bảo vệ chống lạ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 bước kiểm tra đối với yêu cầu API, bao gồm cả xác thực, uỷ quyền, kiểm tra hạn mức và quy tắc bảo mật, đồng thời quản lý các 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 lưu trữ Cloud Firestore

Lớp bộ nhớ Cloud Firestore chịu trách nhiệm lưu trữ cả dữ liệu và siêu dữ liệu, cũng như các tính năng cơ sở dữ liệu liên quan do Cloud Firestore cung cấp. Các phần sau đây mô tả cách dữ liệu được sắp xếp trong lớp bộ nhớ Cloud Firestore và cách hệ thống mở rộng 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 và hiểu rõ hơn các phương pháp hay nhất trong Cloud Firestore.

Dải ô và phần phân tách khoá

Cloud Firestore là một cơ sở dữ liệu NoSQL, hướng đến tài liệu. Bạn lưu trữ dữ liệu trong tài liệu, được sắp xếp theo hệ phân cấp của bộ sưu tập. Hệ phân cấp bộ sưu tập và mã tài liệu được dịch thành một khoá duy nhất cho mỗi tài liệu. Các tài liệu được lưu trữ và sắp xếp theo thứ tự bảng chữ cái theo khoá duy nhất này. Chúng tôi sử dụng thuật ngữ dải khoá để chỉ một dải khoá liền nhau theo thứ tự bảng chữ cái.

Cơ sở dữ liệu Cloud Firestore thông thường quá lớn để vừa với một máy 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 để một máy có thể xử lý. Để xử lý khối lượng công việc lớn, Cloud Firestore phân vùng dữ liệu thành các phần riêng biệt có thể được lưu trữ và phân phát từ nhiều máy hoặc máy chủ lưu trữ. Các phân vùng này được tạo trên các bảng cơ sở dữ liệu trong các khối của các 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 tự động và đồng bộ. Các phần dữ liệu được phân tách có bản sao ở nhiều vùng để đảm bảo dữ liệu luôn có sẵn ngay cả khi không thể truy cập vào một vùng. Việc sao chép nhất quán cho các bản sao của phần phân tách được quản lý bằng thuật toán Paxos để đạt được sự đồng thuận. Một bản sao của mỗi phần phân tách được chọn để đóng vai trò là máy chủ Paxos chính, chịu trách nhiệm xử lý các hoạt động ghi vào phần phân tách đó. Tính năng sao chép đồng bộ cho phép bạn luôn có thể đọc phiên bản dữ liệu mới nhất từ Cloud Firestore.

Kết quả tổng thể của việc này là một hệ thống có khả năng mở rộng và có độ sẵn sàng cao, cung cấp độ trễ thấp cho cả hoạt động đọc và ghi, bất kể khối lượng công việc nặng và ở quy mô rất lớn.

Bố cục dữ liệu

Cloud Firestore là cơ sở dữ liệu tài liệu không có giản đồ. Tuy nhiên, trong nội bộ, ứng dụng này chủ yếu trình bày dữ liệu trong hai bảng kiểu cơ sở dữ liệu quan hệ trong lớp bộ nhớ như sau:

  • Bảng Tài liệu: Tài liệu được lưu trữ trong bảng này.
  • Bảng Chỉ mục: Các mục chỉ mục giúp bạn có thể 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ơ đồ sau đây cho thấy các bảng cho cơ sở dữ liệu Cloud Firestore có thể trông như thế nào với các phần phân tách. Các phần phân tách được sao chép trong ba vùng khác nhau và mỗi phần phân tách có một máy chủ Paxos được chỉ định.

Bố cục dữ liệu

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 khu vực hoặc nhiều khu vực.

Một vị trí theo khu vực là một vị trí địa lý cụ thể, chẳng hạn như us-west1. Các phần dữ liệu của cơ sở dữ liệu Cloud Firestore có bản sao ở các vùng khác nhau trong khu vực đã chọn, như đã giải thích trước đó.

Vị trí đa khu vực bao gồm một nhóm khu vực được xác định nơi lưu trữ bản sao của cơ sở dữ liệu. Trong quá trình triển khai Cloud Firestore ở nhiều khu vực, hai trong số các khu vực 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ó một bản sao nhân chứng không duy trì một tập dữ liệu đầy đủ nhưng tham gia vào quá trình sao chép. Bằng cách nhân bản dữ liệu giữa nhiều khu vực, bạn có thể ghi và đọc dữ liệu ngay cả khi mất toàn bộ một khu vực.

Để biết thêm thông tin về vị trí của một khu vực, hãy xem phần vị trí Cloud Firestore.

Một khu vực so với nhiều khu vực

Tìm hiểu về vòng đời của một hoạt động 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. Thao tác ghi vào một tài liệu yêu cầu cập nhật cả tài liệu và các mục nhập chỉ mục liên kết với tài liệu đó một cách nguyên tử trong lớp bộ nhớ. Cloud Firestore cũng hỗ trợ các thao tác nguyên tử bao gồm nhiều thao tác đọc và/hoặc ghi vào một hoặc nhiều tài liệu.

Đối với tất cả các 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 độc lập và tính bền vững) của cơ sở dữ liệu quan hệ. Cloud Firestore cũng cung cấp khả năng tuần tự hoá, nghĩa là tất cả các giao dịch đều xuất hiện như thể được thực thi theo thứ tự tuần tự.

Các bước cấp cao trong giao dịch ghi

Khi ứng dụng Cloud Firestore phát hành một lệnh 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 được đề cập trước đó, nội bộ, thao tác này sẽ được thực thi dưới dạng giao dịch đọc-ghi cơ sở dữ liệu trong lớp bộ nhớ. Giao dịch này cho phép Cloud Firestore cung cấp các thuộc tính ACID đã đề cập trước đó.

Là 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 thay đổi sẽ được thực hiện đối với dữ liệu trong bảng Documents (Tài liệu).

Việc này cũng bao gồm việc cập nhật cần thiết cho bảng Chỉ mục như sau:

  • Các trường đang được thêm vào tài liệu cần có các mục 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ó thao tá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 cả thao tác xoá (đố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 đột biến được đề cập trước đó, Cloud Firestore sẽ đọc cấu hình lập chỉ mục cho 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 và tổng hợp. Để hiểu rõ về các chỉ mục được tạo trong Cloud Firestore, hãy xem phần Các loại chỉ mục trong Cloud Firestore.

Sau khi tính toán các đột biến, Cloud Firestore sẽ thu thập các đột biến đó bên trong một giao dịch rồi xác nhận giao dịch đó.

Tìm hiểu về giao dịch ghi trong lớp bộ nhớ

Như đã thảo luận trước đó, một hoạt động ghi trong Cloud Firestore liên quan đến một giao dịch đọc-ghi trong lớp bộ nhớ. Tuỳ thuộc vào bố cục dữ liệu, một hoạt động 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ơ đồ sau, cơ sở dữ liệu Cloud Firestore có 8 phần phân tách (đượ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 một vùng và mỗi phần phân tách được nhân bản trong 3(hoặc nhiều hơn) vùng khác nhau. Mỗi phần phân tách có một máy chủ Paxos chính, có thể nằm trong một vùng khác nhau cho các phần phân tách khác nhau.

<span class=Phân tách cơ sở dữ liệu Cloud Firestore">

Hãy xem xét một cơ sở dữ liệu Cloud Firestore có tập hợp Restaurants như sau:

Bộ sưu tập nhà hàng

Ứng dụng Cloud Firestore yêu cầu thay đổi sau đây đối với một tài liệu trong bộ sưu tập Restaurant bằng cách cập nhật giá trị của trường priceCategory.

Thay đổi thành tài liệu trong bộ sưu tập

Các bước cấp cao sau đây mô tả những gì xảy ra trong quá trình ghi:

  1. Tạo giao dịch đọc-ghi.
  2. Đọc tài liệu restaurant1 trong bộ sưu tập Restaurants từ bảng Documents (Tài liệu) trong lớp bộ nhớ.
  3. Đọc các chỉ mục cho tài liệu trong bảng Chỉ mục.
  4. Tính toán các đột biến cần thực hiện đối với dữ liệu. Trong trường hợp này, có 5 đột biến:
    • M1: Cập nhật hàng cho restaurant1 trong bảng Documents (Tài liệu) để phản ánh sự thay đổi về giá trị của trường priceCategory.
    • M2 và M3: Xoá các hàng có giá trị cũ là priceCategory trong bảng Chỉ mục cho chỉ mục giảm dần và tăng dần.
    • M4 và M5: Chèn các hàng cho giá trị mới của priceCategory trong bảng Chỉ mục cho chỉ mục giảm dần và tăng dần.
  5. Gửi các đột biến 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 sở hữu khoá của các hàng cần thay đổi. Hãy xem xét trường hợp Phân tách 3 phân phát M1 và Phân tách 6 phân phát M2-M5. Có một giao dịch phân phối, liên quan đến tất cả các phần phân tách này dưới dạng người tham gia. Các phần phân tách của người tham gia cũng có thể bao gồm mọi phần phân tách khác mà dữ liệu đã được đọc trước đó trong giao dịch đọc-ghi.

Các bước sau đây mô tả những gì xảy ra trong quá trình cam kết:

  1. Ứng dụng lưu trữ phát hành một cam kết. Bản sửa đổi này chứa các đột biến M1-M5.
  2. Các phầ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 người điều phối, chẳng hạn như Phân đoạn 3. Nhiệm vụ của trình điều phối là đảm bảo giao dịch được xác nhận hoặc huỷ một cách nguyên vẹn trên tất cả các bên tham gia.
    • Bản sao chính của các phần phân tách này chịu trách nhiệm về công việc do người tham gia và điều phối viên thực hiện.
  3. Mỗi người tham gia và điều phối viên chạy một thuật toán Paxos với các bản sao tương ứng.
    • Máy chủ chính chạy thuật toán Paxos với các bản sao. Quorum được đạt được nếu hầu hết các bản sao trả lời bằng phản hồi ok to commit cho máy chủ chính.
    • Sau đó, mỗi người tham gia sẽ thông báo cho người điều phối khi họ sẵn sàng (giai đoạn đầu của quá trình cam kết hai giai đoạn). Nếu có người tham gia không thể xác nhận giao dịch, thì toàn bộ giao dịch sẽ aborts.
  4. Khi biết tất cả các bên tham gia, bao gồm cả chính nó, đã sẵn sàng, trình điều phối sẽ thông báo kết quả giao dịch accept cho tất cả các bên tham gia (giai đoạn thứ hai của quá trình cam kết hai giai đoạn). Trong giai đoạn này, mỗi người tham gia ghi lại quyết định xác nhận vào bộ nhớ ổn định và giao dịch được xác nhận.
  5. Trình điều phối phản hồi cho ứng dụng lưu trữ trong Cloud Firestore rằng giao dịch đã được xác nhận. Song song, trình điều phối và tất cả người tham gia áp dụng các đột biến cho dữ liệu.

Vòng đời của cam kết

Khi cơ sở dữ liệu Cloud Firestore có kích thước nhỏ, có thể một phần phân tách duy nhất sở hữu tất cả khoá trong các đột biến M1-M5. Trong trường hợp như vậy, chỉ có một người tham gia giao dịch và không bắt buộc phải thực hiện giao dịch hai giai đoạn được đề cập trước đó, nhờ đó, quá trình ghi sẽ nhanh hơn.

Ghi ở nhiều khu vực

Trong quá trình triển khai nhiều khu vực, việc phân phối bản sao trên các khu vực sẽ làm tăng khả năng hoạt động, nhưng đi kèm với chi phí hiệu suất. Việc giao tiếp giữa các bản sao ở các khu vực khác nhau sẽ mất nhiều thời gian hơn. Do đó, độ trễ cơ sở cho các hoạt động Cloud Firestore cao hơn một chút so với khi triển khai ở một khu vực.

Chúng tôi định cấu hình các bản sao theo cách mà vai trò lãnh đạo cho các phần phân tách luôn nằm trong vùng chính. Khu vực chính là khu vực mà lưu lượng truy cập đang đến máy chủ Cloud Firestore. Quyết định về vai trò lãnh đạo này giúp giảm độ trễ trọn vòng trong quá trình giao tiếp giữa ứng dụng lưu trữ trong Cloud Firestore và máy chủ sao lưu chính (hoặc trình điều phối cho các giao dịch nhiều phần).

Mỗi lần ghi trong Cloud Firestore cũng có 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ề vòng đời của một lượt đọc trong Cloud Firestore

Phần này đi sâu vào các hoạt động đọ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 hai giai đoạn chính:

  1. Một lần quét phạm vi trên bảng Chỉ mục
  2. Truy vấn điểm trong bảng Tài liệu dựa trên kết quả của lần quét trước
Có thể có một số truy vấn nhất định yêu cầu ít hoặc nhiều quá trình xử lý hơn (ví dụ: truy vấn IN) trong Cloud Firestore.

Hoạt động đọc dữ liệu từ lớp bộ nhớ đượ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 tính nhất quán của hoạt động đọc. Tuy nhiên, không giống như các giao dịch dùng để ghi, các giao dịch này không sử dụng khoá. Thay vào đó, các hàm 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 thu nạp khoá nên các đối tượng này 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, cho lớp lưu trữ biết cách chọn dấu thời gian đọc. Loại dấu thời gian ràng buộc do ứng dụng lưu trữ chọn trong Cloud Firestore được xác định bằng các tuỳ chọn đọc cho yêu cầu Đọc.

Tìm hiểu về giao dịch đọc trong lớp bộ nhớ

Phần này mô tả các loại lượt đọc và cách các lượt đọc đó được xử lý trong lớp bộ nhớ trong Cloud Firestore.

Đọc mạnh

Theo mặc định, các lượt đọc Cloud Firestore rất nhất quán. Tính nhất quán mạnh mẽ này có nghĩa là một lượt đọc Cloud Firestore sẽ trả về phiên bản dữ liệu mới nhất phản ánh tất cả các lượt ghi đã được xác nhận cho đến khi bắt đầu lượt đọc.

Đọc một phần phân tách

Ứng dụng lưu trữ trong Cloud Firestore sẽ 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ử rằng nó cần đọc từ Phần 3 trong phần trước đó. Ứng dụng gửi yêu cầu đọc đến bản sao gần nhất để giảm độ trễ của lượt truy cập.

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 gửi đến một bản sao chính (Khu vực A).
    • Vì trình đọc luôn được cập nhật, nên quá trình đọc có thể tiến hành trực tiếp.
  • Yêu cầu đọc được chuyển đến một bản sao không phải là bản sao chính (chẳng hạn như Vùng B)
    • Phân đoạn 3 có thể biết theo trạng thái nội bộ rằng phân đoạn này có đủ thông tin để phân phát hoạt động đọc và phân đoạn này sẽ thực hiện việc đó.
    • Phân đoạn 3 không chắc liệu đã xem dữ liệu mới nhất hay chưa. Phương thức này gửi thông báo đến máy chủ chính để yêu cầu dấu thời gian của giao dịch gần đây nhất mà nó cần áp dụng để phân phát lệnh đọc. Sau khi áp dụng giao dịch đó, bạn có thể tiếp tục đọc.

Sau đó, Cloud Firestore sẽ trả về phản hồi cho ứng dụng khách.

Đọc nhiều phần phân tách

Trong trường hợp phải đọc từ nhiều phần phân tách, cùng một cơ chế 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.

Lượt đọc cũ

Đọc mạnh là chế độ mặc định trong Cloud Firestore. Tuy nhiên, điều này có thể làm tăng độ trễ do có thể cần phải giao tiếp với trình điều phối. 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 dữ liệu có thể đã cũ vài giây.

Trong trường hợp như vậy, ứng dụng có thể chọn nhận dữ liệu đọc cũ bằng cách sử dụng các tuỳ chọn đọc read_time. Trong trường hợp này, các lượt đọc được thực hiện khi dữ liệu ở read_time và bản sao gần nhất rất có thể đã xác minh rằng bản sao đó có dữ liệu tại read_time đã chỉ định. Để có hiệu suất tốt hơn đáng kể, 15 giây là một giá trị lỗi thời hợp lý. Ngay cả đối với các lượt đọc cũ, các hàng được trả về vẫn nhất quán với nhau.

Tránh các điểm phát sóng

Các phân đoạn trong Cloud Firestore sẽ tự động được chia thành các phần nhỏ hơn để phân phối công việc phân phát 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 phần phân tách được tạo để xử lý lưu lượng truy cập dư thừa 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ó sự gia tăng lưu lượng truy cập định kỳ, các phần phân tách sẽ được duy trì và thêm nhiều phần phân tách khác bất cứ khi nào cần thiết. Các cơ chế này giúp cơ sở dữ liệu Cloud Firestore tự động mở rộng quy mô khi 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, bạn cần lưu ý một số hạn chế như giải thích bên dưới.

Việc phân tách bộ nhớ và tải sẽ mất thời gian, đồng thời việc tăng lưu lượng truy cập quá nhanh có thể gây ra độ trễ cao hoặc lỗi vượt quá thời hạn, thường được gọi là điểm nóng, trong khi dịch vụ điều chỉnh. Phương pháp hay nhất là phân phối các thao tác trên phạm vi khoá, đồng thời tăng lưu lượng truy cập trên một tập hợp trong cơ sở dữ liệu với 500 thao tác mỗi giây. Sau khi tăng dần như vậ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ù các phần phân tách được tạo tự động khi tải tăng lên, nhưng Cloud Firestore chỉ có thể phân tách một phạm vi khoá cho đến khi phân phát một tài liệu bằng một nhóm máy chủ lưu trữ sao chép 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 nóng trên tài liệu đó. Nếu gặp phải độ trễ cao liên tục trên một tài liệu, bạn nên cân nhắc sửa đổi mô hình dữ liệu để phân tách 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ố gắng đọc và/hoặc ghi cùng một tài liệu đồng thời.

Một trường hợp đặc biệt khác của việc tạo điểm phát sóng xảy ra khi một khoá 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ó số lượng thao tác cao đáng kể mỗi giây. Việc tạo thêm các nhóm phân tách sẽ không giúp ích gì ở đây vì lưu lượng truy cập tăng đột biến sẽ chỉ chuyển sang nhóm phân tách mới 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 các điểm nóng di chuyển như vậy cũng có thể được tạo trên không gian chỉ mục cho một trường tài liệu chứa giá trị tăng/giảm tuần tự như dấu thời gian.

Xin lưu ý rằng bằng cách làm theo các phương pháp nêu trên, Cloud Firestore có thể mở rộng quy mô để phục vụ khối lượng công việc lớn tuỳ ý mà bạn không cần điều chỉnh bất kỳ cấu hình nào.

Khắc phục sự cố

Cloud Firestore cung cấp Key Visualizer (Trình trực quan hoá khoá) dưới dạng một công cụ chẩn đoán được thiết kế để phân tích các mẫu sử dụng và khắc phục sự cố về điểm nóng.

Bước tiếp theo