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ế 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 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 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ế ứ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.

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.

Giao diện người dùng của Google (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, định 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ệ 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. 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 thuật ngữ dải khoá để chỉ một dải khoá liên tục 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 nên một máy không xử lý được. Để 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ể 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 phạm vi khoá được gọi là phần phân tách.

Lưu ý quan trọng: Việc hiểu cách Cloud Firestore quản lý các phạm vi và phần phân tách khoá có vai trò quan trọng đối với quy trình lập mô hình dữ liệu có thể mở rộng.

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ộ. 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 truy cập được 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.

Lưu ý quan trọng: Việc hiểu cách Cloud Firestore quản lý hoạt động sao chép đóng vai trò quan trọng để hiểu được tính nhất quán, khả năng sử dụng và độ tin cậy của Cloud Firestore.

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, 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ơ đồ dưới đâ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 ở 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 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.

Điểm chính cần ghi nhớ: Việc chọn cấu hình một khu vực so với cấu hình nhiều khu vực sẽ có sự đánh đổi về hiệu suất, khả năng sử dụng và chi phí chính.

Tìm hiểu vòng đời của một nội dung 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 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 sẽ đọ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: đơn trường và chỉ mục kết 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 độ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 đó.

Lưu ý quan trọng: Cloud Firestore nội bộ luôn sử dụng các giao dịch để cung cấp các thuộc tính ACID cho các hoạt động ghi.

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

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 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ơ đồ dưới đây, 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 duy nhất, và mỗi phần phân tách được sao chép ở 3 vùng khác nhau trở lên. 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.

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

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ì 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 sẽ được 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 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. 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ì 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 điều phối viên, 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 người lãnh đạo của những phần phân chia này sẽ chịu trách nhiệm về công việc mà những 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.
   • Thủ lĩnh 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 commit cho thủ lĩ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 xác nhận 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. Đồ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 trường hợp một phần phân tách sở hữu tất cả khoá trong các trường hợp độ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. Quá trình liên lạc giữa các bản sao ở những khu vực khác nhau sẽ mất nhiều thời gian khứ hồi hơn. Do đó, độ trễ cơ sở cho các thao tác 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 sao cho 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 nơi lưu lượng truy cập được gửi đế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.

Lưu ý quan trọng: Cloud Firestore sử dụng các giao dịch để ghi, điều này đòi hỏi phải có khoá dùng chung để đọc và khoá độc quyền để ghi. Khi một giao dịch đọc nhiều hàng, không có giao dịch nào khác có thể ghi vào tập hợp các hàng đó cho đến khi giao dịch này xác nhận hoặc huỷ, gây ra độ trễ cao hơn và/hoặc lỗi tranh chấp khoá. Do đó, hãy cố gắng tránh các lượt đọc lớn bên trong một giao dịch.

Lưu ý quan trọng: Độ trễ ghi/giao dịch tăng lên khi số lượng phần phân tách/người tham gia tăng lên. Không có cơ chế rõ ràng để kiểm soát số lượng người tham gia. Tuy nhiên, bạn có thể làm như sau để giảm số lượng người tham gia:

• Mức phân tán chỉ mục cao là khi cần ghi nhiều mục nhập chỉ mục. Mức phân tán chỉ mục cao cho một hoạt động ghi tài liệu làm tăng số lượng hoặc số hàng cơ sở dữ liệu cần được thay đổi, từ đó làm tăng số lượng người tham gia. Dừng lập chỉ mục rõ ràng trên các trường không được dùng để truy vấn.
• Số lượng người tham gia tăng lên khi số lượng tài liệu được cập nhật trong một giao dịch ghi tăng lên. Để giảm độ trễ, hãy duy trì số lượng tài liệu được cập nhật trong một giao dịch ghi ở mức thấp.

Tìm hiểu về 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ần đọ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 giới hạn dấu thời gian mà ứng dụng lưu trữ chọn trong Cloud Firestore được xác định theo 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 chúng được xử lý trong lớp lưu trữ 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 lầ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ử cần đọc phần Phân tách 3 ở 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 được trạng thái nội bộ của nó 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 đó.
  • Tách 3 không chắc chắn đã thấy 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ưu ý quan trọng: Mức hao tổn độ trễ tăng lên khi số lượng phần phân tách liên quan đến một lượt đọc tăng lên. Việc giữ cho nhóm kết quả truy vấn của bạn nhỏ gọn mỗi khi có thể sẽ giúp ích cho bạn.

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 dụng Cloud Firestore 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ể lỗi thời vài giây.

Trong trường hợp đó, ứ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.

Lưu ý quan trọng: Tính năng đọc mạnh đảm bảo các lượt đọc xem được dữ liệu mới nhất. Tuy nhiên, điều này có thể khiến bản sao phải mất thêm độ trễ trọn vòng khi đó phải giao tiếp với trưởng nhóm và có thể phải đợi giao dịch ghi được áp dụng. Để có hiệu suất tốt hơn, hãy sử dụng các lượt đọc cho phép trả về dữ liệu cũ.

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 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 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.

Lưu ý quan trọng: Bạn nên tăng lưu lượng truy cập theo quy tắc 500/50/5 để đạt được mức mở rộng tối ưu nhất.

Mặc dù quá trình phân tách được tạo tự động khi khối lượng tải tăng lên, nhưng Cloud Firestore chỉ có thể phân tách một dải khoá cho đến khi phân phát một tài liệu bằng cách sử dụ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.

Điểm quan trọng: Tránh tốc độ đọc hoặc ghi cao cho một tài liệu hoặc tài liệu trong một phạm vi khoá chứa một vài tài liệu, nếu không ứng dụng của bạn sẽ gặp phải độ trễ cao và/hoặc lỗi tranh chấp.

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 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 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.

Lưu ý quan trọng: Tránh tạo tài liệu với tốc độ cao trong khi chỉ định mã tài liệu tăng/giảm một cách đơn điệu vì điều này có thể tạo ra các điểm nóng. Để tránh tình trạng điểm nóng, bạn có thể tận dụng mã nhận dạng tài liệu tự động Cloud Firestore sử dụng thuật toán phân tán để các mã này được phân tán theo thứ tự bảng chữ cái.

Điểm chính: Việc lập chỉ mục các trường có giá trị tăng/giảm một cách đơn điệu, chẳng hạn như dấu thời gian, có thể dẫn đến các điểm nóng ảnh hưởng đến độ trễ của các ứng dụng có tốc độ đọc và ghi cao. Nếu không truy vấn dựa trên trường có giá trị tuần tự, bạn có thể miễn lập chỉ mục trường đó để bỏ qua giới hạn này.

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

• Đọ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