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 và độ tin cậy cao. Tài liệu này bao gồm các chủ đề nâng cao về Cloud Firestore. 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 với Cloud Firestore và viết các ứng dụng phong phú và mạnh mẽ.
Để đảm bảo ứng dụng của bạn tiếp tục hoạt động tốt 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 tìm hiểu 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 thao tác đọc và ghi với lớp lưu trữ, 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 để 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 một yêu cầu API Cloud Firestore.
SDK và thư viện ứng dụng Cloud Firestore
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 API Cloud Firestore, nhưng các 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ư xem không cần mạng, bộ nhớ đệm, v.v.
Google Front End (GFE)
Đây là một dịch vụ cơ sở hạ tầ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 đến và chuyển tiếp các yêu cầu đó đến dịch vụ Google có liên quan (dịch vụ Cloud Firestore trong bối cảnh này). Dịch vụ này cũng cung cấp các chức năng quan trọng khác, bao gồm cả việc bảo vệ chống lại các cuộc tấn công từ chối dịch vụ.
Cloud Firestore dịch vụ
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ả việ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 lưu trữ 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 sắp xếp dữ liệu trong lớp lưu trữ Cloud Firestore và cách hệ thống mở rộng quy mô. Việc tìm hiểu về 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 về các phương pháp hay nhất trong Cloud Firestore.
Phạm vi và phân tách khoá
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 hệ phân cấp của bộ sưu tập. Hệ phân cấp tập hợ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ữ một cách hợp lý và sắp xếp theo thứ tự từ điển 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 kề theo thứ tự từ điển.
Một cơ sở dữ liệu Cloud Firestore thông thường quá lớn để có thể lưu trữ trên một máy vật lý. Cũng có những trường hợp khối lượng công việc trên dữ liệu quá nặng nên một máy không thể 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ể đượ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 bảng cơ sở dữ liệu trong các khối dải khoá được gọi là phân tách.
Sao chép đồng bộ
Xin lưu ý rằng cơ sở dữ liệu luôn được sao chép tự động và đồng bộ. Các phần dữ liệu được sao chép ở nhiều vùng để đảm bảo dữ liệu luôn có sẵn ngay cả khi một vùng không thể truy cập được. Thuật toán Paxos quản lý việc sao chép nhất quán sang các bản sao khác nhau của phân tách để đạt được sự đồng thuận. Một bản sao của mỗi phân tách được chọn để đóng vai trò là Paxos leader, chịu trách nhiệm xử lý các hoạt động ghi vào phân tách đó. Tính năng sao chép đồng bộ cho phép bạn luôn đọc đượ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ó tính 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, về mặt nội bộ, lớp này chủ yếu bố trí dữ liệu trong hai bảng kiểu cơ sở dữ liệu quan hệ trong lớp lưu trữ 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 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 của cơ sở dữ liệu Cloud Firestore có thể 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 trong ba vùng khác nhau và mỗi phần phân tách có một người dẫn đầu Paxos được chỉ định.
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.
Vị trí theo khu vực là một vị trí địa lý cụ thể, chẳng hạn như us-west1. Như đã giải thích ở trên, các phần dữ liệu của cơ sở dữ liệu Cloud Firestore có bản sao ở nhiều vùng trong khu vực đã chọn.
Vị trí đa khu vực 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 ở 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 chứng kiến không duy trì một tập hợ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, dữ liệu có thể được ghi và đọc ngay cả khi mất toàn bộ một khu vực.
Để biết thêm thông tin về các vị trí của một khu vực, hãy xem phần Vị trí của Cloud Firestore.
Tìm hiểu vòng đời của một thao tác 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 duy nhất yêu cầu cập nhật cả tài liệu và các mục chỉ mục liên quan của tài liệu đó một cách nguyên tử trong lớp lưu trữ. Cloud Firestore cũng hỗ trợ các thao tác nguyên tử 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 tất cả các loại thao tác 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 chuyển đổi tuần tự, nghĩa là tất 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 đưa ra lệnh ghi hoặc cam kế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 đó, thì trong nội bộ, thao tác này được thực thi dưới dạng giao dịch đọc-ghi cơ sở dữ liệu trong lớp lưu trữ. Giao dịch cho phép Cloud Firestore cung cấp các thuộc tính ACID đã đề cập trước đó.
Trong bước đầu tiên của giao dịch, Cloud Firestore đọc tài liệu hiện có và xác định các thay đổi cần thực hiện đối với dữ liệu trong bảng Documents.
Việc này cũng bao gồm cả 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 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 nêu trên, Cloud Firestore sẽ đọc cấu hình lập chỉ mục cho cơ sở dữ liệu. Cấu hình lập chỉ mục lưu trữ thông tin về các chỉ mục cho một cơ sở dữ liệu. Cloud Firestore sử dụng hai loại chỉ mục: trường đơn và 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 thay đổi, Cloud Firestore sẽ thu thập các thay đổi đó trong một giao dịch rồi cam kết giao dịch đó.
Tìm hiểu về giao dịch ghi trong lớp lưu trữ
Như đã thảo luận trước đó, thao tá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 thao tác 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 sao chép ở 3(hoặc nhiều hơn) vùng khác nhau. Mỗi phân tách có một Paxos leader, có thể nằm trong một vùng khác nhau cho các phân tách khác nhau.
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:
Ứng dụng khách 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:
- Tạo giao dịch đọc-ghi.
- Đọc tài liệu
restaurant1trong tập hợpRestaurantstừ bảng Documents trong lớp lưu trữ. - Đọc chỉ mục cho tài liệu từ bảng Indexes (Chỉ mục).
- Tính toán các thay đổi 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
restaurant1trong bảng Tài liệu để phản ánh sự thay đổi về giá trị của trườngpriceCategory. - M2 và M3: Xoá các hàng cho giá trị cũ của
priceCategorytrong 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
priceCategorytrong bảng Chỉ mục cho các 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 tử 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 tán, 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 tách của người tham gia cũng có thể bao gồm bất kỳ phân tách nào 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:
- Ứng dụng lưu trữ đưa ra một lệnh cam kết. Lệnh xác nhận chứa các đột biến M1-M5.
- Phân tách 3 và 6 là những người tham gia trong 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 tách 3. Công việc của điều phối viên là đảm bảo giao dịch được cam kết hoặc huỷ bỏ một cách nguyên tử trên tất cả những người tham gia.
- Bản sao chính của các 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.
- 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 của họ.
- Trình dẫn đầu 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 leader. - 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 quy trình xác nhận hai giai đoạn). Nếu bất kỳ người tham gia nào không thể cam kết giao dịch, thì toàn bộ giao dịch
aborts.
- Trình dẫn đầu 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 điều phối viên biết tất cả người tham gia, bao gồm cả chính điều phối viên, đã chuẩn bị xong, điều phối viên sẽ thông báo kết quả giao dịch
acceptcho tất cả người tham gia (giai đoạn thứ hai của quy trình cam kết hai giai đoạn). Trong giai đoạn này, mỗi người tham gia sẽ ghi lại quyết định cam kết vào bộ nhớ ổn định và giao dịch được cam kết. - 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 cam kết. Song song đó, điều phối viên và tất cả người tham gia sẽ áp dụng các đột biến cho dữ liệu.
Khi cơ sở dữ liệu Cloud Firestore nhỏ, có thể xảy ra trường hợp một phần tách duy nhất sở hữu tất cả các khoá trong các đột biến M1-M5. Trong trường hợp này, chỉ có một người tham gia giao dịch và không cần đến quy trình xác nhận hai giai đoạn đã đề cập trước đó, nhờ vậy mà quá trình ghi sẽ nhanh hơn.
Ghi dữ liệu ở nhiều khu vực
Trong quá trình triển khai nhiều khu vực, việc phân tán bản sao giữa các khu vực sẽ tăng khả năng hoạt động nhưng lại làm giảm hiệu suất. Quá trình giao tiếp giữa các bản sao ở các khu vực khác nhau mất nhiều thời gian khứ hồi hơn. Do đó, độ trễ cơ sở cho các thao tác Cloud Firestore sẽ 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 quyền lãnh đạo đối với các phân tách luôn nằm trong khu vực chính. Khu vực chính là khu vực có lưu lượng truy cập đến máy chủ Cloud Firestore. Quyết định này của người đứng đầu giúp giảm độ trễ khứ hồi trong hoạt động giao tiếp giữa ứng dụng lưu trữ trong Cloud Firestore và người đứng đầu bản sao (hoặc điều phối viên cho các giao dịch nhiều phân tách).
Mỗi lần ghi trong Cloud Firestore cũng liên quan đến 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 đi sâu vào các thao tác đọ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:
- Một lần qué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 việc đọc nhất quán. Tuy nhiên, không giống như các giao dịch dùng cho thao tác ghi, các giao dịch này không có khoá. Thay vào đó, các giao dịch 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 lấy khoá nên các truy vấn này không chặn các giao dịch đọc-ghi đồng thời. Để thực hiện 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 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 lưu trữ
Phần này mô tả các loại thao tác đọc và cách xử lý các thao tác đó trong lớp lưu trữ của Cloud Firestore.
Nội dung đọc hay
Theo mặc định, các thao tác đọc Cloud Firestore có tính nhất quán cao. Tính nhất quán cao này có nghĩa là thao tác đọ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 thao tác ghi đã được thực hiện cho đến khi bắt đầu thao tác đọc.
Đọc một lần, chia đôi
Ứng dụng lưu trữ trong Cloud Firestore tra cứu các phần tử sở hữu khoá của các hàng cần đọc. Giả sử rằng nó cần đọc từ Phân tách 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ễ khứ hồi.
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 được chọn:
- Yêu cầu đọc sẽ được gửi đến một bản sao chính (Vùng A).
- Vì nút chính 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 gửi đến một bản sao không phải là bản sao chính (chẳng hạn như Khu vực B)
- Phân đoạn 3 có thể biết theo trạng thái nội bộ rằng nó có đủ thông tin để phân phát dữ liệu đọc và phân đoạn đó sẽ thực hiện việc này.
- Split 3 không chắc chắn liệu đã thấy dữ liệu mới nhất hay chưa. Nó gửi một thông báo đến nút dẫn đầu để 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ục vụ yêu cầu đọc. Sau khi giao dịch đó được áp dụng, thao tác đọc có thể tiếp tụ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ơ 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.
Đọc dữ liệu 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 việc giao tiếp có thể cần thiết với nút dẫn đầu. 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 nà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 có nhiều khả năng đã xác minh rằng bản sao đó có dữ liệu tại read_time được chỉ định.
Để cải thiện đáng kể hiệu suất, 15 giây là giá trị hợp lý cho độ trễ. Ngay cả đối với các lần đọc cũ, các hàng được tạo ra vẫn nhất quán với nhau.
Tránh các điểm nóng
Các phân tách trong Cloud Firestore được tự động 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 không còn nữa. Vì vậy, nếu có lưu lượng truy cập tăng đột biến định kỳ, thì các phân tách sẽ được duy trì và nhiều phân tách hơn sẽ được đưa ra 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 cấp tài nguyên bổ sung 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ố điểm hạn chế cần lưu ý như giải thích bên dưới.
Việc phân chia bộ nhớ và tải cần có thời gian, và 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 dải khoá, đồng thời tăng lưu lượng truy cập vào 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, hãy tăng lưu lượng truy cập lên đến 50% sau mỗi 5 phút. Quy trình này được gọi là quy tắc 500/50/5 và giúp cơ sở dữ liệu có thể mở rộng quy mô một cách tối ưu để đáp ứng khối lượng công việc của bạn.
Mặc dù các phân tách được tạo tự động khi tải tăng, nhưng Cloud Firestore chỉ có thể phân tách một dải khoá cho đến khi dải khoá đó phân phát một tài liệu duy nhất bằng cách sử dụng một nhóm máy chủ lưu trữ được 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 điểm phát só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 cùng một lúc.
Một trường hợp đặc biệt khác của điểm truy cập xảy ra khi 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 mỗi giây khá cao. Việc tạo thêm phân tách không giúp ích gì trong trường hợp này vì lưu lượng truy cập tăng đột biến chỉ chuyển sang 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 truy cập 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 phải đ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 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ố điểm truy cập.
Tiếp theo là gì?
- Đọ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