Greenplum Database Bài học 28: Đọc hiểu EXPLAIN và EXPLAIN ANALYZE trong Greenplum: Những điểm khác biệt hoàn toàn so với PostgreSQL

Ở Bài học 27, chúng ta đã diện kiến bộ siêu trí tuệ GPORCA — bộ tối ưu hóa truy vấn chuyên biệt cho kiến trúc MPP của Greenplum. Tuy nhiên, làm sao để bạn biết GPORCA đang thực sự nghĩ gì và lên kế hoạch chạy câu lệnh SQL của bạn ra sao?

Câu trả lời nằm ở lệnh EXPLAIN và EXPLAIN ANALYZE.

Nếu bạn đã quen thuộc với việc đọc lệnh EXPLAIN trong PostgreSQL đơn lẻ, khi bước sang Greenplum, bạn sẽ thấy bản kế hoạch thực thi (Query Plan) hoàn toàn khác biệt với những thuật ngữ mới như Slices, Motion, Gang. Trong bài học này, chúng ta sẽ học cách đọc hiểu tường tận các bản vẽ kỹ thuật này để bắt "bệnh" cho mọi câu lệnh SQL chậm.

1. Phân biệt EXPLAIN và EXPLAIN ANALYZE

Trước khi mổ xẻ nội dung bên trong, chúng ta cần phân định rõ hai công cụ:

• EXPLAIN [SQL]: Chỉ yêu cầu GPORCA vẽ ra bản kế hoạch thực thi trên lý thuyết dựa vào bảng thống kê (Statistics) hiện tại. Câu lệnh không thực sự được chạy, nên trả về kết quả trong tích tắc. Dùng để kiểm tra xem hệ thống chọn đường đi nào.

• EXPLAIN ANALYZE [SQL]: Thực thi thật sự câu lệnh trên toàn bộ cụm, sau đó đo đạc chính xác thời gian thực tế (time), số dòng thực tế (rows) và lượng bộ nhớ tiêu thụ của từng bước.

  • ⚠️ Cảnh báo thực chiến: Hãy cẩn thận khi chạy EXPLAIN ANALYZE trên các câu lệnh UPDATE, DELETE hoặc các bảng Fact hàng tỷ dòng đang chạy trên môi trường Production, vì nó sẽ thực sự tác động và làm tốn tài nguyên hệ thống!

2. Giải phẫu cấu trúc một bản kế hoạch EXPLAIN trên Greenplum

Hãy nhìn vào cấu trúc một bản kế hoạch thực thi điển hình của Greenplum và cách đọc nó:

Plaintext

                                      QUERY PLAN                                      
--------------------------------------------------------------------------------------
 Gather Motion 2:1  (slice1; segments: 2)  (cost=0.00..431.00 rows=1 width=8)
   ->  Partial Aggregate  (cost=0.00..431.00 rows=1 width=8)
         ->  Seq Scan on fact_orders  (cost=0.00..431.00 rows=50000 width=16)
 Optimizer: Pivotal Optimizer (GPORCA)

Nguyên tắc đọc bản kế hoạch: Đọc từ DƯỚI lên TRÊN

1. Bước dưới cùng (Seq Scan): Các tiến trình Segment đồng loạt quét tuần tự bảng fact_orders trên ổ cứng của riêng mình.

2. Bước ở giữa (Partial Aggregate): Mỗi Segment tự tính toán cộng dồn cục bộ trên tập dữ liệu của chính nó để giảm tải lượng dữ liệu phải truyền tải.

3. Bước trên cùng (Gather Motion): Dữ liệu sau khi tính nháp từ các Segment được gom qua mạng Interconnect đẩy về Master Node để ra kết quả cuối cùng.

3. Ba điểm khác biệt "Sống còn" so với PostgreSQL thuần

Khi chuyển từ PostgreSQL sang Greenplum, bạn sẽ thấy bản kế hoạch xuất hiện những khái niệm hoàn toàn mới mà Postgres thuần không bao giờ có:

3.1. Sự xuất hiện của các toán tử Motion (Di chuyển dữ liệu qua mạng)

Như chúng ta đã học ở Bài 5, đây là dấu hiệu đặc trưng của kiến trúc MPP. Trong bản kế hoạch EXPLAIN, bạn sẽ liên tục gặp các toán tử dịch chuyển dữ liệu:

• Gather Motion N:1: Gom dữ liệu từ $N$ Segments về 1 Master.

• Redistribute Motion: Băm (Hash) lại dữ liệu và bắn chéo giữa các Segments để thực hiện phép JOIN.

• Broadcast Motion: Nhân bản dữ liệu từ 1 nơi gửi ra toàn bộ các Segments còn lại.(Nếu bạn nhìn thấy quá nhiều Redistribute Motion trong một câu lệnh JOIN, đó là dấu hiệu cho thấy khóa phân phối DISTRIBUTED BY đang được thiết kế tồi!)

3.2. Khái niệm Slices (Lát cắt thực thi phân tán)

Trong một bản kế hoạch của Greenplum, bạn sẽ thấy các nhãn như (slice1), (slice2).

• Một câu lệnh SQL phức tạp được GPORCA chia nhỏ thành nhiều phần độc lập gọi là các Slices.

• Mỗi Slice đại diện cho một giai đoạn tính toán có thể chạy song song độc lập trên các Segment trước khi truyền kết quả sang Slice tiếp theo qua mạng Interconnect.

3.3. Khái niệm Gang (Nhóm tiến trình thực thi)

Khi chạy EXPLAIN ANALYZE, bạn sẽ thấy thuật ngữ Reader Gang hoặc Writer Gang.

• Gang là tập hợp các tiến trình con (QE - Query Executor) được sinh ra đồng thời trên các Segment Hosts để cùng thực hiện một Slice công việc.

• Reader Gang chuyên đọc dữ liệu, trong khi Writer Gang chuyên ghi dữ liệu xuống bảng đích (ví dụ trong các lệnh INSERT INTO ... SELECT).

4. Cách đọc EXPLAIN ANALYZE để bắt bệnh câu lệnh chậm

Khi một câu lệnh SQL chạy lâu trên Production, việc chạy EXPLAIN ANALYZE sẽ giúp bạn soi thấy các "ung nhọt" hệ thống:

Plaintext

EXPLAIN ANALYZE SELECT * FROM fact_orders JOIN customers ON ...;

Hãy chú ý đến 3 chỉ số vàng:

1. Time (Thời gian thực tế): Nhìn xem bước nào (Step) tốn nhiều thời gian nhất (cost lý thuyết có thể đánh lừa, nhưng thời gian thực tế trong ANALYZE thì không bao giờ nói dối). Nếu một bước Seq Scan tốn tới vài chục giây, bảng đó đang thiếu Index hoặc thiếu Partitioning.

2. Rows (Số lượng dòng): So sánh giữa rows=... (số dòng mà GPORCA ước tính) và actual rows=... (số dòng thực tế xuất hiện). Nếu hai con số này lệch nhau hàng ngàn lần, điều đó có nghĩa là bảng của bạn đang bị thiếu thống kê (Out-of-date Statistics). GPORCA tính toán sai chi phí và chọn nhầm đường đi. (Khắc phục bằng cách chạy ngay lệnh ANALYZE table_name;).

3. Workmem / Spill to Disk: Nếu bạn thấy xuất hiện thông báo Work_mem used: ... spilling to disk, điều đó có nghĩa là bộ nhớ RAM cấp cho câu lệnh (statement_mem) quá nhỏ, khiến dữ liệu phải tràn ra ổ cứng tạm thời — nguyên nhân hàng đầu làm sập hiệu năng hệ thống.

Tóm tắt Bài học 28

• EXPLAIN vẽ ra kế hoạch thực thi lý thuyết, trong khi EXPLAIN ANALYZE thực thi thật và đo đạc chính xác thời gian, số dòng thực tế của từng bước.

• Bản kế hoạch Greenplum khác biệt hoàn toàn so với PostgreSQL nhờ sự xuất hiện của các toán tử Motion, các phân đoạn Slices và nhóm tiến trình Gang.

• Phân tích sự chênh lệch giữa số dòng ước tính và số dòng thực tế giúp phát hiện lỗi thiếu thống kê dữ liệu, từ đó tối ưu hóa chiến lược Index và Partitioning.

Ở bài học tiếp theo (Bài học 29), chúng ta sẽ mổ xẻ chi tiết từng loại toán tử di chuyển dữ liệu qua mạng: Giải mã các toán tử dịch chuyển dữ liệu (Motion Operators): Broadcast Motion, Redistribute Motion và Gather Motion.