Đã đăng vào khoảng 5 giờ trước 8 phút đọc

Greenplum Database Bài học 33: Bảo trì định kỳ: VACUUM, ANALYZE và chiến lược quản lý Table Bloat trên Heap và AO Tables

Chúng ta đã đi qua các kỹ thuật thiết kế bảng, nạp dữ liệu tốc độ cao, tinh chỉnh chiến lược JOIN và kiểm soát tài nguyên hệ thống qua Resource Queues. Tuy nhiên, bất kỳ hệ thống cơ sở dữ liệu doanh nghiệp nào sau một thời gian dài vận hành (vài tháng đến vài năm) đều sẽ gặp phải một kẻ thù thầm lặng: Sự phình to dung lượng bảng (Table Bloat) và sự lạc hậu của thống kê dữ liệu (Stale Statistics).

Nếu không có một chiến lược bảo trì định kỳ, các câu lệnh SQL dù được tối ưu đến đâu cũng sẽ chạy chậm dần đều. Trong bài học này, chúng ta sẽ mổ xẻ cơ chế hoạt động của lệnh VACUUM, ANALYZE và cách quản lý Table Bloat trên cả hai mô hình lưu trữ Heap và Append-Optimized (AO) Tables.

1. Vấn đề Table Bloat (Phình to bảng) là gì?

Khi bạn thực hiện các thao tác UPDATE hoặc DELETE trên bảng cơ sở dữ liệu, cơ chế điều khiển đồng thời đa phiên bản (MVCC) của PostgreSQL/Greenplum không thực sự xóa sạch dữ liệu ngay lập tức khỏi ổ cứng:

Các dòng cũ bị đánh dấu là "đã ẩn" (Dead Tuples).
Không gian đĩa chứa các dòng cũ đó bị bỏ trống nhưng không được hệ điều hành tự động thu hồi, khiến dung lượng tệp trên ổ cứng cứ lớn dần lên mặc dù số lượng dòng thực tế có khi đã giảm đi.
Hiện tượng này gọi là Table Bloat. Khi bảng bị bloat nặng, bộ quét tuần tự (Seq Scan) sẽ phải đọc cả những khối dữ liệu toàn rác, gây lãng phí nghiêm trọng băng thông ổ cứng I/O.

2. Giải pháp VACUUM: Dọn dẹp rác trên Heap Tables

Đối với các bảng sử dụng mô hình lưu trữ Heap Tables (thường dùng cho Staging hoặc Dimension Tables có cập nhật dữ liệu), lệnh VACUUM là công cụ bắt buộc phải chạy định kỳ:

SQL

-- 1. VACUUM thông thường (Dọn dẹp rác và đánh dấu không gian trống để tái sử dụng)
VACUUM staging_users;

-- 2. VACUUM FULL (Dọn dẹp triệt để và THU HỒI dung lượng đĩa trả về cho hệ điều hành)
VACUUM FULL staging_users;

Sự khác biệt cốt lõi giữa `VACUUM` và `VACUUM FULL`:

VACUUM thường: Quét bảng, dọn dẹp các Dead Tuples và đánh dấu các trang đĩa trống để các lệnh INSERT sau đó có thể ghi đè vào. Không khóa bảng (Non-blocking), có thể chạy bình thường trong giờ hành chính.
VACUUM FULL: Tạo ra một bản sao hoàn toàn mới của bảng, dồn dẹp gọn gàng mọi khoảng trống và trả lại dung lượng đĩa cho hệ điều hành. Tuy nhiên, nó khóa độc quyền bảng (Exclusive Lock) trong suốt quá trình chạy, khiến mọi câu lệnh đọc/ghi khác phải đứng chờ. Do đó, VACUUM FULL chỉ được phép chạy trong khung giờ bảo trì hệ thống (Maintenance Window).

3. Đặc thù dọn dẹp rác trên Append-Optimized (AO / AOCO) Tables

Như chúng ta đã học ở Phần 2, các bảng lưu trữ theo mô hình Append-Optimized (AO/AOCO) không chịu ảnh hưởng bởi cơ chế MVCC cấp độ dòng truyền thống. Vậy khi bạn chạy lệnh DELETE hoặc UPDATE trên AO Table, rác được xử lý ra sao?

Khi một dòng trên AO Table bị xóa hoặc sửa, Greenplum đánh dấu khối dữ liệu đó là rác thông qua một bảng chỉ mục ngầm gọi là Visibility Map (Bitmap Index). Không gian đĩa cũ chưa được giải phóng ngay.
Để dọn dẹp rác thực sự trên AO Tables, Greenplum cung cấp câu lệnh VACUUM chuyên dụng đi kèm với tham số làm sạch:

SQL

-- Dọn dẹp rác và thu hồi không gian đĩa cho bảng AOCO
VACUUM fact_transactions;

Lưu ý quan trọng của DBA: Quá trình VACUUM trên bảng AO/AOCO dung lượng hàng trăm Gigabyte tiêu tốn rất nhiều tài nguyên CPU và I/O. Hãy cấu hình lịch trình chạy vào ban đêm hoặc sử dụng tính năng AO Compact tự động của Greenplum.

4. ANALYZE: Bí quyết sống còn của bộ tối ưu hóa GPORCA

Nếu VACUUM giải quyết bài toán dung lượng đĩa, thì ANALYZE giải quyết bài toán "trí tuệ" của bộ tối ưu hóa truy vấn GPORCA.

4.1. Thống kê dữ liệu (Statistics) là gì?

Khi GPORCA lên kế hoạch thực thi câu lệnh EXPLAIN, nó dựa vào các bảng thống kê hệ thống (pg_statistic) để biết:

Bảng này có bao nhiêu dòng?
Giá trị phân phối của cột này nằm trong khoảng nào? Có bao nhiêu giá trị duy nhất (Cardinality)?

4.2. Hậu quả khi thiếu hoặc lạc hậu Statistics:

Nếu bạn vừa nạp hàng chục triệu bản ghi mới vào bảng fact_orders nhưng quên chạy ANALYZE, GPORCA vẫn nghĩ rằng bảng đó chỉ có vài trăm dòng. Kết quả là:

GPORCA chọn nhầm chiến lược Broadcast Join thay vì Redistributed Join.
Cấp phát thiếu RAM (statement_mem), dẫn đến lỗi Spill to Disk kinh hoàng.
Chọn sai đường dẫn quét bảng (Seq Scan thay vì tận dụng Index hoặc Partition Elimination).

4.3. Cú pháp thực chiến:

SQL

-- 1. Cập nhật thống kê cho toàn bộ cơ sở dữ liệu
ANALYZE;

-- 2. Cập nhật thống kê cho một bảng cụ thể (Nên chạy ngay sau các tiến trình ETL lớn)
ANALYZE fact_orders;

-- 3. Cập nhật thống kê cho một cột cụ thể có độ phân tán cao
ANALYZE fact_orders(customer_id);

5. Xây dựng chiến lược bảo trì định kỳ chuẩn Enterprise

Để cụm Greenplum luôn vận hành với hiệu năng cao nhất, một DBA chuyên nghiệp luôn thiết lập một lịch trình bảo trì tự động (Maintenance Schedule) kết hợp giữa Linux Cron và các câu lệnh SQL định kỳ:

┌────────────────────────────────────────────────────────────────────────┐
│                    LỊCH TRÌNH BẢO TRÌ ĐỊNH KỲ (MAINTENANCE)            │
└───────────────────────────┬────────────────────┬───────────────────────┘
                            │                    │
             [ Hàng đêm (Đêm khuya) ]    [ Hàng tuần / Hàng tháng ]
             • Chạy ANALYZE cho bảng     • Chạy VACUUM các bảng AO lớn
               Fact mới nạp dữ liệu.     • Kiểm tra hệ thống Table Bloat.

Hàng đêm (Sau khi ETL hoàn tất): Tự động chạy lệnh ANALYZE cho các bảng Fact và Dimension vừa có biến động dữ liệu lớn trong ngày.
Hàng tuần: Kiểm tra dung lượng tệp đĩa, chạy VACUUM cho các bảng Heap hoặc AO có tỷ lệ UPDATE/DELETE cao.
Theo dõi qua System Catalog: Sử dụng các view hệ thống như pg_stat_user_tables để theo dõi tỷ lệ dòng rác (n_dead_tup) nhằm chủ động lên lịch dọn dẹp trước khi hệ thống bị chậm.

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

Table Bloat là hiện tượng phình to dung lượng ổ cứng do các dòng dữ liệu cũ (UPDATE/DELETE) không được thu hồi ngay lập tức theo cơ chế MVCC.
VACUUM giúp dọn dẹp rác trên Heap Tables (có hỗ trợ VACUUM FULL thu hồi đĩa) và dọn dẹp không gian trên Append-Optimized Tables.
ANALYZE làm mới bảng thống kê hệ thống, là "nhiên liệu" bắt buộc để bộ tối ưu hóa GPORCA lập kế hoạch thực thi chính xác và nhanh chóng.
Thiết lập lịch trình bảo trì tự động hàng đêm là tiêu chuẩn vàng của mọi quản trị viên cơ sở dữ liệu Greenplum chuyên nghiệp.

Ở bài học tiếp theo (Bài học 34), chúng ta sẽ tìm hiểu về công cụ giám sát và quản lý cụm: Giám sát cụm Greenplum: Sử dụng Command Center, pg_stat_activity và các lệnh quản trị hệ thống.

cloud database