Greenplum Database Bài học 13: Heap Tables vs Append-Optimized (AO) Tables: Chọn mô hình lưu trữ cho OLTP hay OLAP?

Ở các bài học trước, chúng ta đã giải quyết bài toán rải dữ liệu xuống các Segment bằng chiến lược phân phối (DISTRIBUTED BY). Tuy nhiên, câu hỏi tiếp theo đặt ra là: Bên trong ổ cứng của mỗi Segment, dữ liệu thực sự được sắp xếp và lưu trữ theo cấu trúc vật lý nào?

Vì Greenplum được phát triển dựa trên nền tảng của PostgreSQL — một hệ cơ sở dữ liệu sinh ra để phục vụ OLTP (xử lý giao dịch nhanh) — nó thừa hưởng mô hình lưu trữ truyền thống gọi là Heap Tables. Nhưng khi bước vào thế giới Data Warehouse (OLAP) với hàng tỷ bản ghi lịch sử, Heap Tables lại bộc lộ những điểm yếu chết người.

Đó là lý do Greenplum ra mắt một mô hình lưu trữ mang tính cách mạng dành riêng cho Big Data: Append-Optimized (AO) Tables. Hãy cùng mổ xẻ sự khác biệt cốt lõi giữa hai mô hình này.

1. Heap Tables: Mô hình lưu trữ truyền thống của PostgreSQL

1.1. Bản chất hoạt động

• Heap Table là kiểu bảng mặc định của PostgreSQL và cũng là mặc định của Greenplum nếu bạn không chỉ định gì thêm khi tạo bảng (CREATE TABLE ...).

• Dữ liệu được lưu trữ thành từng dòng (Row-oriented) không theo một thứ tự sắp xếp cố định nào trên đĩa (giống như việc bạn ném các tờ giấy ghi chú vào một chiếc hộp — "Heap").

• Cơ chế MVCC (Multi-Version Concurrency Control): Mỗi dòng dữ liệu trên Heap Table gánh thêm các siêu dữ liệu (metadata) đi kèm như xmin, xmax để phục vụ việc khóa giao dịch (INSERT, UPDATE, DELETE).

1.2. Ưu điểm tuyệt vời của Heap Tables

• Hỗ trợ tối ưu cho các thao tác OLTP: Xử lý cực nhanh các lệnh INSERT từng dòng đơn lẻ, UPDATE hoặc DELETE liên tục nhờ cơ chế quản lý con trỏ và transaction log tinh vi.

• Thích hợp cho các bảng nhỏ, bảng danh mục (Dimension) thường xuyên thay đổi dữ liệu hoặc bảng trung gian cập nhật trạng thái liên tục.

1.3. Cái giá phải trả trong thế giới OLAP (Data Warehouse)

• Chi phí Metadata khổng lồ: Đối với mỗi bản ghi, Heap Table phải cộng thêm một lượng overhead lớn cho các thông tin MVCC. Nếu bảng có hàng tỷ dòng, dung lượng lãng phí cho metadata này có thể lên tới hàng chục Gigabyte.

• Hiện tượng Table Bloat (Phình to bảng): Khi bạn chạy lệnh UPDATE hoặc DELETE trên Heap Table, PostgreSQL không thực sự xóa sạch không gian đĩa ngay lập tức mà chỉ đánh dấu là "đã ẩn". Không gian đó bị bỏ trống (dead tuples) và buộc DBA phải thường xuyên chạy VACUUM để dọn dẹp, nếu không hiệu năng quét bảng sẽ tụt giảm nghiêm trọng.

2. Append-Optimized (AO) Tables: "Vũ khí chuyên biệt" cho Big Data OLAP

Hiểu được nhược điểm của Heap Table trong môi trường phân tích dữ liệu lớn, Greenplum xây dựng mô hình lưu trữ Append-Optimized (AO) Tables (hay còn gọi là Append-Only Tables từ các phiên bản trước).

┌────────────────────────────────────────────────────────────────────────┐
│                   APPEND-OPTIMIZED (AO) TABLE ARCHITECTURE             │
└───────────────────────────────────┬────────────────────────────────────┘
                                    │
       ┌────────────────────────────┴────────────────────────────┐
       ▼                                                         ▼
 [ Block 1 (Đã đóng & Nén) ]                     [ Block N (Đang ghi tuần tự) ]
 • Không có Metadata dòng phức tạp               • Ghi dồn dập tốc độ cực cao
 • Hỗ trợ nén cao (ZSTD / QuickLZ)               • Tối ưu cho Bulk INSERT / Scan

2.1. Bản chất hoạt động

• Đúng như tên gọi ("Tối ưu hóa việc ghi nối tiếp"), AO Table được thiết kế theo tư duy: Dữ liệu trong Data Warehouse chủ yếu là ghi một lần và đọc mãi mãi (WORM - Write Once, Read Many).

• Khi bạn nạp dữ liệu vào AO Table, các dòng được ghi tuần tự thành từng khối lớn (Compression Blocks) trên đĩa. Cơ chế MVCC cấp độ dòng phức tạp được lược bỏ hoàn toàn, thay vào đó là quản lý giao dịch ở cấp độ khối (Block-level).

2.2. Ưu điểm vượt trội của AO Tables

1. Dung lượng lưu trữ siêu nhỏ (Nén dữ liệu tuyệt vời): Vì không bị gánh nặng metadata dòng và các khối dữ liệu đồng nhất, AO Table cho phép tích hợp các thuật toán nén mạnh mẽ như ZSTD, QuickLZ hoặc Zlib. Dung lượng bảng có thể giảm từ 3 đến 10 lần so với Heap Table!

2. Tốc độ đọc tuần tự (Sequential Scan) cực nhanh: Khi chạy câu lệnh SELECT quét hàng tỷ bản ghi, việc đọc các khối dữ liệu nén liên tục từ đĩa giúp giảm tải I/O phần cứng đi đáng kể.

3. Nạp dữ liệu hàng loạt (Bulk Load) cực nhanh: Phối hợp với lệnh COPY hoặc gpfdist, tốc độ đổ dữ liệu vào AO Table nhanh hơn nhiều lần so với Heap Table.

2.3. Nhược điểm chí mạng của AO Tables

• Cực kỳ tồi tệ với UPDATE và DELETE từng dòng: AO Table không cho phép sửa trực tiếp một dòng trên đĩa. Khi bạn chạy lệnh UPDATE, hệ thống buộc phải đọc toàn bộ khối dữ liệu cũ lên, sửa đổi, rồi ghi thành một khối hoàn toàn mới ở cuối file, đồng thời đánh dấu khối cũ là rác.

• Quy tắc vàng: Tuyệt đối không dùng AO Table cho các bảng có tính chất OLTP (như bảng sessions, bảng user_cart cập nhật giỏ hàng liên tục từng giây).

3. Bảng so sánh chi tiết: Heap Tables vs Append-Optimized Tables

4. Hướng dẫn thực chiến: Khi nào nên chọn loại bảng nào?

Khi thiết kế một hệ thống Data Warehouse trên Greenplum, quy tắc phân chia mô hình lưu trữ rất rõ ràng:

SQL

-- 1. Bảng Staging / Bảng trung gian cập nhật liên tục (OLTP-style): Dùng HEAP
CREATE TABLE staging_user_actions (
    action_id BIGINT,
    user_id BIGINT,
    action_type VARCHAR(50)
) DISTRIBUTED BY (user_id); 
-- Mặc định không khai báo gì thêm sẽ là Heap Table.

-- 2. Bảng Fact lưu trữ lịch sử giao dịch hàng tỷ dòng (OLAP-style): Bắt buộc dùng AO
CREATE TABLE fact_historical_orders (
    order_id BIGINT,
    user_id BIGINT,
    total_amount NUMERIC(12,2),
    created_at TIMESTAMP
) WITH (appendoptimized=true, orientation=row, compresstype=zstd, compressionlevel=5)
DISTRIBUTED BY (user_id);

• Dùng Heap Tables cho: Các bảng Staging nhận dữ liệu từ API ứng dụng cần thao tác UPDATE/DELETE thường xuyên, hoặc các bảng Dimension nhỏ có cấu trúc thay đổi dữ liệu liên tục.

• Dùng Append-Optimized Tables cho: 95% các bảng Fact (Giao dịch, Log lịch sử, Sự kiện) có đặc tính chỉ INSERT theo lô (Batch) và không bao giờ sửa đổi dữ liệu cũ.

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

• Heap Tables tối ưu cho OLTP (ghi, sửa, xóa linh hoạt từng dòng), nhưng tốn dung lượng đĩa và kém hiệu quả khi quét dữ liệu lớn.

• Append-Optimized (AO) Tables là chuẩn mực vàng cho Data Warehouse (OLAP), hỗ trợ nén dữ liệu cao (ZSTD/QuickLZ), tối ưu hóa đọc tuần tự, nhưng cực kỳ kỵ các thao tác UPDATE/DELETE nhỏ lẻ.

• Việc lựa chọn đúng mô hình lưu trữ giúp tiết kiệm hàng terabyte dung lượng phần cứng và tăng tốc độ câu truy vấn phân tích lên nhiều lần.

Ở bài học tiếp theo (Bài học 14), chúng ta sẽ tiếp tục tiến sâu hơn vào tầng lưu trữ vật lý của AO Tables để khám phá: Row-Oriented vs Column-Oriented (AOCO) Tables — Tối ưu hóa I/O cho các truy vấn tổng hợp (Aggregation).

Bạn có muốn thử cấu hình một bảng Fact giao dịch kết hợp giữa Append-Optimized và thuật toán nén ZSTD cho hệ thống logistics của Hasaki không?