Hãy đọc tài liệu này để đưa ra những quyết định sáng suốt về kiến trúc ứng dụng của bạn 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 của Cloud Firestore. 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 là 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. Rất 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 rằng các ứ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, việc hiểu cơ chế đọc và ghi trong phần phụ trợ của Cloud Firestore sẽ giúp ích. Bạn cũng phải hiểu sự tương tác giữa việc đọc và ghi với lớp lưu trữ và các ràng buộc cơ bản có thể ảnh hưởng đến hiệu suất.
Xem các phần sau để biết cách thực hành tốt nhất trước khi kiến trúc ứng dụng của bạn.
Hiểu các thành phần cấp cao
Sơ đồ sau đây hiển thị 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 khách
Cloud Firestore hỗ trợ SDK và thư viện ứng dụng khách cho các nền tảng khác nhau. Mặc dù ứng dụng có thể thực hiện lệnh gọi HTTP và RPC trực tiếp tới API Cloud Firestore nhưng thư viện máy khách lại cung cấp một lớp trừu tượng để đơn giản hóa 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ộ đệm, v.v.
Giao diện người dùng của Google (GFE)
Đây là 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 chúng đến dịch vụ Google có liên quan (dịch vụ Firestore trong ngữ cảnh này). Nó cũng cung cấp các chức năng quan trọng khác, bao gồm 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 kiểm tra yêu cầu API, bao gồm xác thực, ủy quyền, kiểm tra hạn ngạch 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 khách 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ô. Tìm hiểu về cách sắp xếp dữ liệu có thể giúp bạn thiết kế 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.
Phạm vi chính và sự phân chia
Cloud Firestore là cơ sở dữ liệu định hướng tài liệu, NoSQL. Bạn lưu trữ dữ liệu trong các tài liệu được sắp xếp theo thứ bậc của các bộ sưu tập . Hệ thống phân cấp bộ sưu tập và ID tài liệu được dịch sang một khóa duy nhất cho mỗi tài liệu. Các 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 khóa duy nhất này. Chúng tôi sử dụng thuật ngữ phạm vi khóa để chỉ một phạm vi khóa liền kề về mặt từ điển.
Cơ sở dữ liệu Cloud Firestore thông thường quá lớn để chứa vừa trên một máy vật lý. Cũng có những tình huống trong đó khối lượng công việc trên dữ liệu quá nặng để một máy có 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ục vụ 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 theo các khối gồm các phạm vi chính được gọi là 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ộ. Việc phân chia dữ liệu có các bản sao ở các vùng khác nhau để luôn sẵn sàng ngay cả khi một vùng không thể truy cập được. Việc sao chép nhất quán sang các bản sao khác nhau của phần phân chia đượ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 chia được bầu làm người đứng đầu Paxos, người chịu trách nhiệm xử lý việc ghi vào phần phân chia đó. Bản sao đồng bộ mang đến cho bạn khả năng 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à sẵn sàng cao, cung cấp độ trễ thấp cho 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ó sơ đồ. Tuy nhiên, bên trong nó bố trí 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ữ của nó 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 có thể nhận được kết quả 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 dành cho cơ sở dữ liệu Cloud Firestore trông như thế nào khi được chia tách. Việc phân chia được sao chép thành ba khu vực khác nhau và mỗi phân chia có một thủ lĩnh Paxos được chỉ định.
Một vùng so với nhiều vùng
Khi tạo cơ sở dữ liệu, bạn phải chọn một vùng hoặc nhiều vùng .
Một vị trí khu vực duy nhất là một vị trí địa lý cụ thể, như us-west1 . Việc phân chia dữ liệu của cơ sở dữ liệu Cloud Firestore có các bản sao ở các vùng khác nhau trong vùng đã chọn, như đã giải thích trước đó.
Vị trí nhiều vùng bao gồm một tập hợp các vùng được xác định nơi lưu trữ các bản sao của cơ sở dữ liệu. Khi triển khai Cloud Firestore trên nhiều vùng, hai trong số các vùng có bản sao đầy đủ của toàn bộ dữ liệu trong cơ sở dữ liệu. Vùng thứ ba có bản sao nhân chứng không duy trì bộ dữ liệu đầy đủ nhưng tham gia sao chép. Bằng cách sao chép dữ liệu giữa nhiều vùng, dữ liệu có thể được ghi và đọc ngay cả khi mất toàn bộ vùng.
Để biết thêm thông tin về vị trí của một khu vực, hãy xem Vị trí của Cloud Firestore .
Hiểu cuộc sống của một người viết trong Cloud Firestore
Ứng dụng khách Cloud Firestore có thể ghi dữ liệu bằng cách tạo, cập nhật hoặc xóa một tài liệu. Việc ghi vào một tài liệu yêu cầu cập nhật nguyên tử cả tài liệu và các mục chỉ mục liên quan của nó trong lớp lưu trữ. Cloud Firestore cũng hỗ trợ các hoạt động nguyên tử bao gồm nhiều lần đọ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 ghi, Cloud Firestore cung cấp các thuộc tính ACID (tính nguyên tử, tính nhất quán, sự cô lập và độ bền) của cơ sở dữ liệu quan hệ. Cloud Firestore cũng cung cấp khả năng tuần tự hóa , có nghĩa là tất cả các giao dịch xuất hiện như thể được thực hiện theo thứ tự nối tiếp.
Các bước cấp cao trong giao dịch ghi
Khi ứng dụng khách Cloud Firestore phát hành lệnh ghi hoặc thực hiện giao dịch, sử dụng bất kỳ phương thức nào được đề cập trước đó, nội bộ việ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 lưu trữ. Giao dịch cho phép Cloud Firestore cung cấp các thuộc tính ACID được đề cập trước đó.
Là 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 Tài liệu.
Điều này cũng bao gồm việc thực hiện cá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 chèn tương ứng vào bảng Chỉ mục.
- Các trường đang bị xóa khỏi tài liệu cần được xóa 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ả xóa (đố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 đọ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: trường đơn và hỗn hợp. Để hiểu chi tiết về các chỉ mục được tạo trong Cloud Firestore, hãy xem 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 chúng trong một giao dịch và sau đó thực hiện nó.
Hiểu 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ữ. Tùy thuộc vào cách bố trí dữ liệu, việc ghi có thể bao gồm một hoặc nhiều phần tách như được thấy trong bố cục dữ liệu .
Trong sơ đồ sau, cơ sở dữ liệu Cloud Firestore có tám phần phân chia (được đánh dấu 1-8) được lưu trữ trên ba máy chủ lưu trữ khác nhau trong một vùng duy nhất và mỗi phần phân chia được sao chép trong 3 (hoặc nhiều) vùng khác nhau. Mỗi phần chia có một thủ lĩnh Paxos, người này có thể ở một khu vực khác nhau cho các phần chia khác nhau.
Hãy xem xét cơ sở dữ liệu Cloud Firestore có bộ sưu tập Restaurants như sau:
Ứng dụng khách Cloud Firestore yêu cầu thay đổi sau đối với 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 .
Các bước cấp cao sau đây mô tả những gì xảy ra trong quá trình viết:
- 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 chỉ mục cho tài liệu từ bảng Chỉ mục .
- 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ó năm độ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ường DanhpriceCategory. - M2 và M3: Xóa các hàng cho giá trị cũ của
priceCategorytrong bảng Chỉ mục cho các 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
- Cam kết những đột biến này.
Ứng dụng khách lưu trữ trong dịch vụ Cloud Firestore tra cứu các phần tách sở hữu khóa của các hàng cần thay đổi. Hãy xem xét trường hợp Phần 3 phục vụ M1 và Phần 6 phục vụ M2-M5. Có một giao dịch phân tán, liên quan đến tất cả các phần tách này với tư cách là người tham gia . Sự phân chia của người tham gia cũng có thể bao gồm bất kỳ sự phân chia nào khác mà dữ liệu được đọc trước đó như một phần của giao dịch đọc-ghi.
Các bước sau đây mô tả những gì xảy ra như một phần của cam kết:
- Máy khách lưu trữ đưa ra một cam kết. Cam kết chứa các đột biến M1-M5.
- 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 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 hủy bỏ một cách nguyên tử đối với tất cả những người tham gia.
- Bản sao lãnh đạo của các bộ phận phân chia này chịu trách nhiệm về công việc được thực hiện bởi những người tham gia và điều phối viên.
- Mỗi người tham gia và điều phối viên chạy thuật toán Paxos với các bản sao tương ứng của họ.
- Người lãnh đạo chạy thuật toán Paxos với các bản sao. Số đại biểu đạt được nếu hầu hết các bản sao trả lời
ok to commitphản hồi với người lãnh đạo. - 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 bất kỳ người tham gia nào không thể thực hiện giao dịch thì toàn bộ giao dịch
aborts.
- Người lãnh đạo chạy thuật toán Paxos với các bản sao. Số đại biểu đạt được nếu hầu hết các bản sao trả lời
- Sau khi điều phối viên biết tất cả những người tham gia, bao gồm cả chính họ, đã chuẩn bị sẵn sàng, 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 hai giai đoạn). Trong giai đoạn này, mỗi người tham gia ghi lại quyết định cam kết lưu trữ ổn định và giao dịch được cam kết. - Điều phối viên trả lời ứng dụng khách lưu trữ trong Cloud Firestore rằng giao dịch đã được thực hiện. Song song, điều phối viên và tất cả những người tham gia áp dụng các đột biến cho dữ liệu.
Khi cơ sở dữ liệu của Cloud Firestore còn 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 khóa 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 cần phải có cam kết hai giai đoạn được đề cập trước đó, do đó việc ghi sẽ nhanh hơn.
Viết ở nhiều vùng
Khi triển khai trên nhiều khu vực, việc phân bổ các bản sao giữa các khu vực sẽ làm tăng tính khả dụng nhưng đi kèm với chi phí hiệu suất. Việc liên lạc giữa các bản sao ở các khu vực khác nhau mất nhiều thời gian hơn. Do đó, độ trễ cơ bản cho các hoạt động của 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 định cấu hình các bản sao theo cách mà quyền lãnh đạo các phần tách luôn nằm ở khu vực chính. Khu vực chính là khu vực mà lưu lượng truy cập đến máy chủ Cloud Firestore. Quyết định này của lãnh đạo giúp giảm độ trễ trong giao tiếp giữa máy khách lưu trữ trong Cloud Firestore và người lãnh đạo bản sao (hoặc người điều phối cho các giao dịch chia nhiều lần).
Mỗi lần ghi trong Cloud Firestore cũng liên quan đến một số tương tác với công cụ thời gian thực trong Cloud Firestore. Để biết thêm thông tin về các truy vấn thời gian thực, hãy xem Tìm hiểu các truy vấn thời gian thực ở quy mô lớn .
Hiểu cuộc sống của một lần đọc trong Cloud Firestore
Phần này đi sâu vào 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:
- Quét một phạm vi duy nhất 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ả 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 được sử dụng để ghi, các giao dịch này không có khóa. Thay vào đó, chúng hoạt động bằng cách chọn dấu thời gian, sau đó thực hiện tất cả các lần đọc tại dấu thời gian đó. Vì chúng không thu được khóa nên chúng 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 giới hạn dấu thời gian, thông báo cho lớp lưu trữ cách chọn dấu thời gian đọc. Loại dấu thời gian được giới hạn bởi ứng dụng lưu trữ trong Cloud Firestore được xác định bởi các tùy 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 kiểu đọ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ần đọc của Cloud Firestore rất nhất quán . Tính nhất quán mạnh mẽ này có nghĩa là lần đọc trên Cloud Firestore trả về phiên bản mới nhất của dữ liệu phản ánh tất cả các lần ghi đã được cam kết cho đến khi bắt đầu đọc.
Đọc một lần
Ứng dụng khách lưu trữ trong Cloud Firestore tra cứu các phần tách sở hữu khóa của các hàng cần đọc. Giả sử rằng nó cần đọc từ Phần 3 của phần trước. Máy khách 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 tùy thuộc vào bản sao đã chọn:
- Yêu cầu đọc được chuyển đến bản sao dẫn đầu (Vùng A).
- Vì người lãnh đạo luôn cập nhật nên việc đọc có thể tiến hành trực tiếp.
- Yêu cầu đọc được chuyển tới bản sao không phải bản chính (chẳng hạn như Vùng B)
- Phần 3 có thể biết trạng thái bên trong của nó rằng nó có đủ thông tin để phục vụ việc đọc và phần chia này làm như vậy.
- Phần 3 không chắc chắn liệu nó có thấy dữ liệu mới nhất hay không. Nó gửi một tin nhắn đến người lãnh đạo để yêu cầu dấu thời gian của giao dịch cuối cùng mà nó cần áp dụng để phục vụ việc đọc. Sau khi giao dịch đó được áp dụng, quá trình đọc có thể tiếp tục.
Cloud Firestore sau đó trả về phản hồi cho khách hàng của mình.
Đọc nhiều lần
Trong trường hợp việc đọc phải được thực hiện từ nhiều phần tách, cơ chế tương tự sẽ xảy ra trên tất cả các phần tách. Khi dữ liệu đã được trả về từ tất cả các phần tách, ứng dụng khách lưu trữ trong Cloud Firestore sẽ kết hợp các kết quả. Cloud Firestore sau đó sẽ phản hồi khách hàng của mình bằng dữ liệu này.
Đọc cũ
Đọc mạnh là chế độ mặc định trong Cloud Firestore. Tuy nhiên, nó phải trả giá bằng độ trễ tiềm ẩn cao hơn do có thể cần phải giao tiếp với người lãnh đạo. 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, khách hàng có thể chọn nhận các lượt đọc cũ bằng cách sử dụng các tùy chọn đọc read_time . Trong trường hợp này, việc đọ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 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ị độ ổn định 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 nóng
Sự phân chia 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ục vụ 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 khóa mở rộng. Các phân tách được tạo để xử lý lưu lượng truy cập vượt mức đượ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 lưu lượng truy cập tăng đột biến định kỳ, việc phân chia sẽ được duy trì và đưa ra nhiều phân chia hơn 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 thay đổi 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ố hạn chế cần lưu ý như được giải thích dưới đây.
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 lỗi có độ trễ cao hoặc lỗi vượt quá thời hạn, thường được gọi là điểm phát sóng trong khi dịch vụ điều chỉnh. Cách tốt nhất là phân phối các thao tác trên phạm vi khóa, đồng thời tăng lưu lượng truy cập trên một bộ sưu tập trong cơ sở dữ liệu với 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 50% cứ sau 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 ở quy mô tối ưu để đáp ứng khối lượng công việc của bạn.
Mặc dù việc phân tách được tạo tự động với tải tăng dần, nhưng Cloud Firestore chỉ có thể phân chia một phạm vi khóa cho đến khi nó phân phát một tài liệu duy nhất bằng cách sử dụng một bộ máy chủ lưu trữ được sao chép chuyên dụng. Do đó, khối lượng hoạt động đồng thời cao và liên tục 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 bạn gặp phải độ trễ cao kéo dài trên một tài liệu, bạn nên xem xét sửa đổi mô hình dữ liệu của mình để 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 nóng xảy ra khi khóa tăng/giảm tuần tự được sử dụng làm ID tài liệu trong Cloud Firestore và có số lượng thao tác mỗi giây cao đáng kể. Việc tạo thêm phần chia tách không giúp ích gì ở đây vì lưu lượng truy cập tăng đột biến chỉ chuyển sang phần chia mới được tạo. Do 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 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 ý rằng bằng cách làm theo các phương pháp được nêu ở trên, Firestore có thể mở rộng quy mô để phục vụ khối lượng công việc lớn tùy ý mà bạn không cần phải điều chỉnh bất kỳ cấu hình nào.
Xử lý sự cố
Firestore cung cấp Key Visualizer như một công cụ chẩn đoán được thiết kế đặc biệt để phân tích các kiểu sử dụng và khắc phục sự cố điểm nóng.
Cái gì tiếp theo
- Đọc thêm về các phương pháp hay nhất
- Tìm hiểu về các truy vấn thời gian thực trên quy mô lớn