Greenplum Database Bài học 27: Kiến trúc GPORCA vs Postgres Planner: Bộ tối ưu hóa truy vấn dựa trên chi phí dành riêng cho MPP

chúng ta đã chính thức bước sang Phần 4: Tối ưu hóa Truy vấn & Bộ lập lịch GPORCA (từ Bài 27 đến Bài 35). Sau khi đã nắm vững kiến trúc nền tảng, thiết kế bảng lưu trữ và các phương pháp nạp dữ liệu tốc độ cao ở các phần trước, đây là học phần sẽ biến bạn thành một chuyên gia thực thụ về hiệu năng SQL trên Greenplum.

Bất cứ khi nào bạn gõ một câu lệnh SELECT và nhấn Enter, cơ sở dữ liệu không tự động thực hiện ngay lập tức. Nó phải đi qua một bộ não phân tích gọi là Query Optimizer (Bộ tối ưu hóa truy vấn) để vạch ra đường đi nước bước hiệu quả nhất. Trong Greenplum, có một cuộc cách mạng lớn xoay quanh hai bộ tối ưu hóa: Postgres Planner nguyên bản và siêu phẩm độc quyền GPORCA. Trong bài học này, chúng ta sẽ mổ xẻ sự khác biệt cốt lõi giữa hai bộ não này.

1. Vấn đề của Postgres Planner trong môi trường MPP

Vì Greenplum được phát triển dựa trên nền tảng PostgreSQL, các phiên bản Greenplum đời đầu hoàn toàn sử dụng bộ lập lịch nguyên bản của Postgres (Postgres Planner). Tuy nhiên, Postgres Planner được sinh ra để phục vụ cho các cơ sở dữ liệu đơn lẻ (Single-node OLTP). Khi đem đặt nó vào một cụm phân tán MPP hàng chục máy chủ, Postgres Planner bắt đầu bộc lộ những giới hạn chí mạng:

1. Thiếu tầm nhìn phân tán (Lack of Distributed Awareness): Postgres Planner chỉ biết cách quét dữ liệu trên một không gian cục bộ. Nó không hiểu được khái niệm về các Segment Hosts, các khóa phân phối (DISTRIBUTED BY) hay chi phí khi phải đẩy dữ liệu qua lại qua mạng Interconnect.

2. Giới hạn trong việc lập kế hoạch JOIN phức tạp: Khi một câu lệnh SQL thực hiện JOIN từ 5 đến 10 bảng lớn trở lên, số lượng đường đi khả dĩ tăng theo cấp số nhân. Postgres Planner (với thuật toán tiếp cận theo chiều sâu - Genetic Query Optimizer) thường "bỏ cuộc sớm" và chọn nhầm các đường đi tồi tệ, khiến câu truy vấn chạy mất hàng giờ.

3. Không tối ưu hóa cho Subqueries và CTEs: Các cấu trúc truy vấn con phức tạp thường bị Postgres Planner bóc tách thành các bước thực hiện tuần tự rời rạc, làm mất đi cơ hội tính toán song song trên toàn cụm.

2. GPORCA ra đời: Bộ tối ưu hóa truy vấn thế hệ mới dành riêng cho MPP

Nhận thấy Postgres Planner không thể đáp ứng được các bài toán Data Warehouse quy mô lớn, đội ngũ phát triển Greenplum đã quyết định viết mới hoàn toàn từ đầu một bộ tối ưu hóa truy vấn thế hệ mới mang tên GPORCA (Greenplum Open-Source Optimizer).

┌────────────────────────────────────────────────────────────────────────┐
│                        KIẾN TRÚC TỐI ƯU HÓA GPORCA                       │
└───────────────────────────┬────────────────┬───────────────────────────┘
                            │                │
       [ Câu lệnh SQL của User ] ──► [ GPORCA Engine ]
                                           │
         ┌─────────────────────────────────┴─────────────────────────────────┐
         ▼                                                                   ▼
 [ Thuật toán tìm kiếm dựa trên chi phí ]                        [ Nhận thức phân tán MPP ]
 • Khám phá hàng ngàn không gian thực thi                        • Tối ưu hóa vị trí tính toán
 • Xử lý tuyệt vời các lệnh JOIN lớn, Subqueries                 • Tính toán chính xác chi phí mạng Interconnect

Những điểm vượt trội tuyệt đối của GPORCA:

• Tư duy phân tán toàn cục (Distributed Cost Model): GPORCA hiểu tường tận cấu trúc của cụm MPP. Khi tính toán chi phí (Cost) của một câu lệnh, nó không chỉ tính toán thời gian đọc đĩa (Disk I/O) hay sức mạnh CPU, mà còn tính toán chi phí di chuyển dữ liệu qua mạng Interconnect (Motion Cost).

• Không gian tìm kiếm kế hoạch rộng lớn (Search Space): Sử dụng các mô hình toán học tiên tiến, GPORCA có khả năng khám phá hàng ngàn kịch bản thực thi khác nhau để tìm ra con đường tối ưu nhất mà Postgres Planner không bao giờ chạm tới được.

• Tối ưu hóa Subqueries và Aggregations: GPORCA có khả năng "phẳng hóa" các câu lệnh con (Flattening Subqueries) và tự động đẩy các phép tính tổng hợp xuống gần dữ liệu hơn, giảm thiểu tối đa lượng dữ liệu phải di chuyển qua mạng.

3. GPORCA vs Postgres Planner: Bảng so sánh thực tế

4. Cách kiểm tra GPORCA đang hoạt động trong câu lệnh SQL

Khi bạn chạy câu lệnh EXPLAIN trên Greenplum, phần cuối cùng của bản kế hoạch thực thi sẽ cho bạn biết câu lệnh đó đang được biên dịch bởi bộ tối ưu hóa nào:

SQL

EXPLAIN SELECT * FROM fact_orders WHERE total_amount > 1000;

Kết quả hiển thị:

Plaintext

                                      QUERY PLAN                                      
--------------------------------------------------------------------------------------
 Gather Motion 2:1  (slice1; segments: 2)  (cost=0.00..431.00 rows=1 width=16)
   ->  Seq Scan on fact_orders  (cost=0.00..431.00 rows=50000 width=16)
 Optimizer: Pivotal Optimizer (GPORCA)  <-- Xác nhận đang dùng GPORCA

• Nếu bạn nhìn thấy dòng Optimizer: Pivotal Optimizer (GPORCA), điều đó có nghĩa là câu lệnh của bạn đang được tối ưu hóa bởi siêu bộ não dành riêng cho MPP.

• Trong một số ít trường hợp hiếm hoi nếu GPORCA gặp cấu trúc câu lệnh quá đặc thù chưa được hỗ trợ, Greenplum sẽ tự động chuyển đổi fallback về Postgres Planner (sẽ hiển thị dòng Optimizer: Postgres query optimizer). Bạn có thể bật/tắt GPORCA thông qua tham số cấu hình hệ thống optimizer (ON/OFF).

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

• Postgres Planner nguyên bản thiếu tầm nhìn phân tán và gặp khó khăn khi tối ưu hóa các câu lệnh JOIN lớn trên môi trường MPP.

• GPORCA là bộ tối ưu hóa truy vấn thế hệ mới được thiết kế độc quyền cho Greenplum, hiểu rõ chi phí mạng Interconnect và tối ưu hóa tuyệt đối không gian thực thi truy vấn.

• Sử dụng lệnh EXPLAIN giúp nhận diện nhanh chóng câu lệnh SQL đang được biên dịch bởi GPORCA hay Postgres Planner.

Ở bài học tiếp theo (Bài học 28), chúng ta sẽ tiến hành đọc hiểu bản đồ thực thi truy vấn: Đọ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.