Trong MongoDB, khi thực hiện các truy vấn phức tạp trên tập dữ liệu lớn, cơ chế tối ưu hóa truy vấn thông qua Query Planner hoạt động như thế nào và làm thế nào để đọc, phân tích kết quả từ hàm explain()?

Question

Accepted Answer

Cơ chế Query Planner trong MongoDB
Khi một câu lệnh truy vấn (Query) được gửi đến MongoDB, nó không được thực thi trực tiếp ngay lập tức mà phải đi qua một bộ phận cốt lõi gọi là Query Planner (trước phiên bản 3.0 thường gọi là Classic Engine, hiện nay sử dụng trường phái tối ưu hóa dựa trên chi phí Cost-based Optimizer với công cụ lưu trữ WiredTiger).
Các giai đoạn xử lý của Query Planner

Query Parsing: Phân tích cú pháp câu lệnh truy vấn JSON thành một cấu trúc cây cú pháp trừu tượng.
Candidate Generation: Dựa trên các Index hiện có trong Collection, Query Planner sinh ra các kế hoạch thực thi tiềm năng (Candidate Plans). Các kế hoạch này có thể bao gồm việc sử dụng các Index khác nhau hoặc quét toàn bộ Collection (COLLSCAN).
Trial Period (WiredTiger): MongoDB tiến hành chạy thử nghiệm đồng thời các kế hoạch tiềm năng này trong một khoảng thời gian ngắn hoặc một số lượng Work Units nhất định. Kế hoạch nào hoàn thành việc trả về kết quả hoặc tiến triển nhanh nhất với ít tài nguyên nhất sẽ được chọn làm Winning Plan.
Caching: Winning Plan sẽ được lưu vào Query Plan Cache của Collection đó để các câu hỏi tương tự về cấu trúc (Shape) trong tương lai có thể sử dụng lại mà không cần tính toán lại từ đầu.

Phân tích kết quả thực thi thông qua phương thức explain()
Để đánh giá hiệu năng truy vấn, lập trình viên sử dụng phương thức db.collection.find().explain('executionStats'). Các thông số quan trọng cần phân tích gồm:

stage: Thể hiện giai đoạn thực thi cốt lõi.
IXSCAN: MongoDB đang sử dụng Index để quét dữ liệu. Đây là trạng thái tối ưu.
COLLSCAN: MongoDB phải quét toàn bộ các Document trong Collection (Collection Scan). Đây là dấu hiệu cảnh báo nghiêm trọng về hiệu năng.

nReturned: Số lượng Document thực tế trả về cho Client.
keysExamined: Số lượng khóa Index đã bị quét qua. Nếu con số này lớn hơn rất nhiều so với nReturned, nghĩa là Index đang chọn chưa thực sự tối ưu hoặc điều kiện lọc kém chọn lọc (Low Cardinality).
docsExamined: Số lượng Document thực tế trên đĩa đã bị quét qua. Trong trường hợp sử dụng Index hoàn hảo (Covered Query), thông số này sẽ bằng 0.

Lưu ý kinh nghiệm thực chiến

Query Shape: MongoDB phân biệt kế hoạch truy vấn dựa trên cấu trúc của câu lệnh (Query Shape), bao gồm các trường trong điều kiện tìm kiếm và thứ tự sắp xếp. Các giá trị bên trong (Literal values) khác nhau không làm thay đổi Query Shape.
Plan Cache Invalidation: Khi một Collection bị thực hiện các thao tác thay đổi cấu trúc lớn (như tạo thêm Index mới, drop Index, hoặc số lượng Document thay đổi đáng kể trên 64 lần), MongoDB sẽ tự động xóa sạch Query Plan Cache để buộc Query Planner tính toán lại kế hoạch tối ưu mới.

Trong MongoDB, khi thực hiện các truy vấn phức tạp trên tập dữ liệu lớn, cơ chế tối ưu hóa truy vấn thông qua Query Planner hoạt động như thế nào và làm thế nào để đọc, phân tích kết quả từ hàm explain()?

Cơ chế Query Planner trong MongoDB

Làm Chủ Phỏng Vấn & Nâng Cao Trình Độ Chuyên Nghiệp

Tải Tuyển Tập 100+ Câu Hỏi Phỏng Vấn Chuyên Sâu (PDF)

Cần Mentor Phỏng Vấn Thử 1-1 & Tối Ưu CV?

Kiểm Tra CV Chuẩn ATS Miễn Phí

Câu hỏi nosql liên quan cùng chủ đề