Greenplum Database Bài học 14: Row-Oriented vs Column-Oriented (AOCO): Tối ưu hóa I/O cho các truy vấn tổng hợp (Aggregation)

Ở Bài học 13, chúng ta đã biết Append-Optimized (AO) Tables giúp giải quyết bài toán lưu trữ dữ liệu lịch sử khổng lồ nhờ cơ chế ghi tuần tự và nén dữ liệu tối ưu. Tuy nhiên, bên trong mô hình Append-Optimized, Greenplum tiếp tục phân chia thành hai nhánh lưu trữ vật lý hoàn toàn khác biệt: Row-Oriented (Hướng dòng) và Column-Oriented (Hướng cột — gọi tắt là AOCO).

Sự lựa chọn giữa Row và Column quyết định đến sự sống còn của băng thông ổ cứng (Disk I/O) khi bạn thực hiện các câu truy vấn phân tích tổng hợp (SUM, AVG, GROUP BY). Trong bài học này, chúng ta sẽ mổ xẻ nguyên lý hoạt động và bí quyết chọn đúng mô hình cho từng loại bảng.

1. Bài toán kinh điển: Tại sao Row-Oriented "hụt hơi" trước truy vấn OLAP?

Hãy tưởng tượng bạn có một bảng giao dịch orders lưu trữ trên mô hình Row-Oriented (dù là Heap hay AO Row). Bảng này có tới 50 cột (gồm ID, Khách hàng, Ngày tháng, Địa chỉ giao hàng, Trạng thái, Thông tin thiết bị, Phí vận chuyển, v.v.) và chứa 1 tỷ bản ghi (tương đương dung lượng 100 GB trên đĩa).

Bây giờ, nhà quản lý yêu cầu bạn chạy một câu lệnh SQL cực kỳ đơn giản:

SQL

SELECT SUM(shipping_fee) FROM orders;

Câu truy vấn này chỉ cần tính tổng trên đúng 1 cột duy nhất là shipping_fee.

Điều gì xảy ra bên dưới ổ cứng của Row-Oriented?

• Trong mô hình Row-Oriented, dữ liệu của từng dòng được đóng gói liên tiếp nhau trên đĩa: [Dòng 1: Cột 1 đến Cột 50][Dòng 2: Cột 1 đến Cột 50]...

• Khi đọc cột shipping_fee (giả sử nằm ở Cột số 45), ổ cứng buộc phải đọc toàn bộ 100 GB dữ liệu của cả 50 cột lên bộ nhớ RAM.

• Hệ thống lãng phí tới 98% băng thông I/O chỉ để tải 49 cột dữ liệu không liên quan (như tên khách hàng, địa chỉ, ghi chú...) rồi vứt chúng đi. Đó chính là nút thắt cổ chai kinh điển của lưu trữ hướng dòng trong thế giới Data Warehouse!

2. Giải pháp Column-Oriented (AOCO - Append-Optimized Column-Oriented)

Để triệt tiêu lãng phí I/O, Greenplum hỗ trợ mô hình Column-Oriented (thường đi kèm với Append-Optimized, gọi là AOCO).

┌────────────────────────────────────────────────────────────────────────┐
│                   SO SÁNH VẬT LÝ TRÊN ĐĨA: ROW vs COLUMN                │
└───────────────────────────────────┬────────────────────────────────────┘
                                    │
    ┌───────────────────────────────┴───────────────────────────────┐
    ▼                                                               ▼
ROW-ORIENTED (Lưu theo dòng)                    COLUMN-ORIENTED (AOCO - Lưu theo cột)
[D1: C1, C2, C3][D2: C1, C2, C3]...              [Cột 1: D1, D2, D3...][Cột 2: D1, D2, D3...]
(Đọc cả dòng dù chỉ cần 1 cột)                  (Chỉ đọc đúng file của cột cần thiết)

2.1. Bản chất hoạt động của AOCO

• Trong mô hình Column-Oriented, dữ liệu của từng cột được tách rời và lưu trữ vào các file vật lý độc lập nhau trên đĩa.

• Khi bạn chạy câu lệnh SELECT SUM(shipping_fee) FROM orders, Greenplum chỉ mở đúng file chứa dữ liệu của cột shipping_fee để đọc từ đĩa lên RAM.

• Thay vì phải đọc 100 GB, hệ thống giờ đây chỉ phải đọc chưa đầy 2 GB dữ liệu của riêng cột đó. Băng thông I/O giảm đi 50 lần, tốc độ câu truy vấn tăng vọt từ hàng phút xuống còn vài mili-giây!

2.2. Siêu năng lực nén dữ liệu của AOCO (Extreme Compression)

Vì các giá trị trong cùng một cột thường có tính đồng nhất cao (ví dụ: cột status chỉ lặp đi lặp lại vài chuỗi giá trị, hoặc cột age chỉ chứa các số từ 18 đến 60), cấu trúc lưu trữ hướng cột tạo điều kiện hoàn hảo cho các thuật toán nén mạnh mẽ:

• Run-Length Encoding (RLE): Nén chuỗi các giá trị giống nhau liên tiếp.

• Dictionary Encoding: Mã hóa các từ khóa lặp lại thành các số nguyên nhỏ.

• Kết hợp với thuật toán ZSTD, các bảng AOCO thường đạt tỷ lệ nén dung lượng đĩa từ 5 đến 15 lần so với bảng thông thường.

3. Khi nào nên dùng Row-Oriented vs Column-Oriented (AOCO)?

Không phải lúc nào Column-Oriented cũng tốt hơn Row-Oriented. Mỗi mô hình có một vùng đất "hoành tráng" riêng:

4. Cú pháp thực chiến tạo bảng AOCO trên Greenplum

Để khai báo một bảng sử dụng mô hình lưu trữ hướng cột kết hợp nén ZSTD trên Greenplum, bạn sử dụng cú pháp orientation=column:

SQL

CREATE TABLE fact_sales_analytics (
    sale_id BIGINT,
    product_id INT,
    customer_id BIGINT,
    store_id INT,
    quantity INT,
    unit_price NUMERIC(10,2),
    total_amount NUMERIC(12,2),
    sold_date DATE
) 
WITH (
    appendoptimized = true, 
    orientation = column,       -- Chỉ định lưu trữ theo cột (AOCO)
    compresstype = zstd,        -- Thuật toán nén ZSTD
    compressionlevel = 6        -- Mức độ nén (từ 1 đến 19)
)
DISTRIBUTED BY (product_id);

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

• Row-Oriented lưu trữ dữ liệu theo từng dòng, tối ưu khi cần đọc toàn bộ các cột của bản ghi.

• Column-Oriented (AOCO) tách rời từng cột thành các file riêng biệt, giúp triệt tiêu lãng phí Disk I/O khi chạy các câu truy vấn tổng hợp (AGGREGATION) chỉ trên vài cột.

• AOCO mang lại khả năng nén dữ liệu siêu việt (lên tới hàng chục lần), là tiêu chuẩn vàng cho các bảng Fact phân tích quy mô lớn trong Data Warehouse.

Ở bài học tiếp theo (Bài học 15), chúng ta sẽ tìm hiểu sâu hơn về nghệ thuật tinh chỉnh các thuật toán nén: Kỹ thuật nén dữ liệu (Compression): So sánh ZSTD, QuickLZ và Zlib trên bảng Columnar.

Bạn có muốn thử phân tích một câu lệnh báo cáo doanh thu thực tế tại Hasaki để xem việc chuyển sang bảng AOCO giúp tiết kiệm bao nhiêu băng thông I/O không?