Posted inDatabase

Hướng dẫn phân vùng bảng (Table Partitioning) trong PostgreSQL: Tăng tốc truy vấn cho bảng hàng triệu bản ghi

Database tutorial - IT technology blog
Database tutorial - IT technology blog

Giới thiệu

Trong hành trình làm việc với dữ liệu, có lẽ không ít lần mình đau đầu vì những bảng dữ liệu cứ thế phình to, từ vài trăm nghìn bản ghi lên đến hàng triệu, thậm chí hàng tỷ. Khi đó, mỗi câu truy vấn dường như trở thành một thử thách về sự kiên nhẫn. Mình đã từng chứng kiến những câu SELECT đơn giản mà chạy mất mấy chục giây, thậm chí cả phút, khiến hệ thống chậm chạp và người dùng than phiền.

Đó là lúc mình nhận ra cần có một giải pháp mạnh mẽ hơn ngoài việc chỉ tối ưu INDEX hay viết lại QUERY. Và câu trả lời mình tìm thấy là Phân vùng bảng (Table Partitioning) trong PostgreSQL. Sau hơn nửa năm triển khai và vận hành trên môi trường production, mình có thể khẳng định phân vùng bảng là giải pháp cực kỳ hiệu quả. Nó giúp cải thiện hiệu suất và đơn giản hóa việc quản lý các bảng dữ liệu khổng lồ.

Bài viết này chia sẻ chi tiết cách mình đã áp dụng phân vùng bảng. Từ những bước cơ bản đến các kỹ thuật nâng cao, kèm kinh nghiệm thực tế để bạn áp dụng ngay cho hệ thống.

1. Quick Start: Phân vùng bảng trong 5 phút

Không lòng vòng, mình sẽ đi thẳng vào ví dụ thực tế. Giả sử bạn có một bảng lưu trữ các bản ghi log hệ thống audit_logs và bảng này đang tăng trưởng với tốc độ chóng mặt. Mình muốn phân vùng nó theo thời gian tạo created_at.

Bước 1: Tạo bảng chính (Partitioned Table)

Đây là bảng “cha” không chứa dữ liệu trực tiếp, mà sẽ định nghĩa cách các bảng con được phân vùng.

CREATE TABLE audit_logs (
    log_id BIGSERIAL NOT NULL,
    action_type VARCHAR(50) NOT NULL,
    user_id INT NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
) PARTITION BY RANGE (created_at);

Ở đây, mình dùng PARTITION BY RANGE (created_at) để chỉ định rằng bảng sẽ được phân vùng theo phạm vi giá trị của cột created_at.

Bước 2: Tạo các phân vùng con (Partitions)

Mỗi phân vùng con là một bảng vật lý riêng biệt, chứa một phần dữ liệu của bảng chính. Mình thường tạo phân vùng theo tháng hoặc năm tùy vào lượng dữ liệu.

-- Phân vùng cho tháng 1 năm 2023
CREATE TABLE audit_logs_2023_01 PARTITION OF audit_logs
    FOR VALUES FROM ('2023-01-01 00:00:00+00') TO ('2023-02-01 00:00:00+00');

-- Phân vùng cho tháng 2 năm 2023
CREATE TABLE audit_logs_2023_02 PARTITION OF audit_logs
    FOR VALUES FROM ('2023-02-01 00:00:00+00') TO ('2023-03-01 00:00:00+00');

-- Và cứ thế cho các tháng tiếp theo...
CREATE TABLE audit_logs_2023_03 PARTITION OF audit_logs
    FOR VALUES FROM ('2023-03-01 00:00:00+00') TO ('2023-04-01 00:00:00+00');

Lưu ý: Phạm vi giá trị FROM là bao gồm, còn TO là không bao gồm. Các khoảng giá trị không được chồng chéo lên nhau.

Bước 3: Chèn dữ liệu

Khi bạn chèn dữ liệu vào bảng chính audit_logs, PostgreSQL sẽ tự động định tuyến bản ghi đó vào đúng phân vùng con dựa trên giá trị của cột created_at.

INSERT INTO audit_logs (action_type, user_id, created_at) VALUES
('LOGIN', 101, '2023-01-15 10:30:00+00'),
('LOGOUT', 101, '2023-01-15 11:00:00+00'),
('UPDATE_PROFILE', 102, '2023-02-01 09:00:00+00'),
('VIEW_REPORT', 103, '2023-02-20 14:00:00+00'),
('DELETE_ITEM', 104, '2023-03-05 16:00:00+00');

Nếu bạn chèn một bản ghi có created_at nằm ngoài phạm vi của tất cả các phân vùng con hiện có, sẽ có lỗi xảy ra (trừ khi có phân vùng DEFAULT, mình sẽ nói sau).

Bước 4: Truy vấn và cảm nhận hiệu suất

Giờ đây, khi bạn truy vấn dữ liệu và lọc theo cột created_at, PostgreSQL sẽ thông minh chỉ quét các phân vùng chứa dữ liệu bạn cần, thay vì toàn bộ bảng lớn.

EXPLAIN ANALYZE SELECT * FROM audit_logs WHERE created_at BETWEEN '2023-02-01' AND '2023-02-28';

Bạn sẽ thấy trong kết quả EXPLAIN ANALYZE rằng PostgreSQL chỉ quét audit_logs_2023_02 và loại bỏ (pruning) các phân vùng khác, giúp truy vấn nhanh hơn đáng kể.

2. Phân vùng bảng là gì và tại sao chúng ta cần nó?

Sau khi đã thấy được “phép màu” của phân vùng bảng, giờ chúng ta đi sâu hơn một chút về bản chất của nó.

Khái niệm cơ bản

Hiểu đơn giản, phân vùng bảng là kỹ thuật chia một bảng logic (bảng chính) thành nhiều bảng vật lý nhỏ hơn (bảng con), dựa trên một hoặc nhiều cột được gọi là khóa phân vùng (partition key). Với PostgreSQL từ phiên bản 10 trở lên, việc này được hỗ trợ native, dễ dàng và hiệu quả hơn rất nhiều so với các phiên bản trước đó.

Lợi ích “thực chiến” của phân vùng bảng

Mình đã trải nghiệm và nhận thấy những lợi ích rõ rệt sau khi áp dụng:

  • Tăng tốc truy vấn đáng kể: Đây là lợi ích lớn nhất. Khi một truy vấn có điều kiện lọc trên khóa phân vùng (ví dụ WHERE created_at BETWEEN ...), PostgreSQL chỉ cần đọc các phân vùng liên quan và bỏ qua các phân vùng không chứa dữ liệu cần tìm. Mình đã chứng kiến thời gian truy vấn giảm từ vài chục giây xuống còn vài mili giây cho các bảng hàng trăm triệu bản ghi.

    -- Ví dụ minh họa (kết quả EXPLAIN sẽ chỉ ra chỉ quét 1 partition)
EXPLAIN SELECT * FROM audit_logs WHERE created_at > '2023-03-15' AND created_at < '2023-03-16';
  • Quản lý dữ liệu hiệu quả hơn: Việc xóa hoặc lưu trữ dữ liệu cũ trở nên cực kỳ đơn giản và nhanh chóng. Thay vì chạy một câu DELETE tốn kém trên cả bảng lớn (có thể gây ra nhiều VACUUM overhead), mình chỉ cần DETACH (tách) một phân vùng cũ và DROP (xóa) nó. Việc này diễn ra gần như tức thì, không làm ảnh hưởng đến hoạt động của hệ thống.

    -- Tách phân vùng tháng 1 năm 2023 ra khỏi bảng chính
ALTER TABLE audit_logs DETACH PARTITION audit_logs_2023_01;

-- Xóa hẳn phân vùng đó nếu không còn cần nữa
DROP TABLE audit_logs_2023_01;
  • Cải thiện hiệu suất bảo trì: Các lệnh như VACUUM và ANALYZE chỉ cần chạy trên các phân vùng con nhỏ hơn, giúp chúng hoàn thành nhanh hơn, giảm tải cho hệ thống. Điều này đặc biệt quan trọng trong các môi trường production có lượng giao dịch cao.
  • Giảm tắc nghẽn (Contention): Khi dữ liệu được phân tán trên nhiều bảng con, khả năng xảy ra tranh chấp khóa (lock contention) trên một bảng duy nhất sẽ giảm đi, giúp hệ thống chạy mượt mà hơn.

Các loại phân vùng phổ biến

PostgreSQL hỗ trợ ba loại phân vùng chính, mỗi loại phù hợp với một kiểu dữ liệu và truy vấn khác nhau:

  • RANGE Partitioning (Phân vùng theo phạm vi): Phổ biến nhất. Dữ liệu được phân chia dựa trên các khoảng giá trị của khóa phân vùng. Thường dùng cho các cột thời gian (created_at, log_date) hoặc các cột ID có tính chất tăng dần (transaction_id).

    -- Ví dụ phân vùng theo năm
CREATE TABLE sales (
    sale_id BIGSERIAL,
    sale_date DATE,
    amount DECIMAL(10, 2)
) PARTITION BY RANGE (sale_date);

CREATE TABLE sales_2022 PARTITION OF sales
    FOR VALUES FROM ('2022-01-01') TO ('2023-01-01');
  • LIST Partitioning (Phân vùng theo danh sách): Dữ liệu được chia dựa trên các giá trị rời rạc, cụ thể của khóa phân vùng. Thường dùng cho các cột có số lượng giá trị cố định và dễ xác định (region, status, category).

    -- Ví dụ phân vùng theo khu vực
CREATE TABLE users (
    user_id BIGSERIAL,
    username VARCHAR(100),
    region VARCHAR(50)
) PARTITION BY LIST (region);

CREATE TABLE users_north PARTITION OF users
    FOR VALUES IN ('North', 'Northeast');

CREATE TABLE users_south PARTITION OF users
    FOR VALUES IN ('South', 'Southeast');
  • HASH Partitioning (Phân vùng theo hàm băm): Dữ liệu được phân chia dựa trên giá trị băm của khóa phân vùng, nhằm phân phối dữ liệu đều giữa các phân vùng. Loại này ít phổ biến hơn vì việc quản lý khó hơn và thường chỉ dùng khi bạn không có cách nào khác để phân chia dữ liệu đều theo RANGE hay LIST.

3. Nâng cao: Quản lý và Tối ưu phân vùng

Việc tạo phân vùng ban đầu chỉ là bước khởi đầu. Để hệ thống hoạt động trơn tru và hiệu quả lâu dài, chúng ta cần các chiến lược quản lý và tối ưu cao hơn.

Tự động hóa việc tạo phân vùng mới

Trong môi trường production, bạn không thể ngồi đó tạo thủ công từng phân vùng mỗi tháng. Mình thường dùng một script nhỏ chạy định kỳ bằng cron job hoặc một hàm PL/pgSQL với trigger/event scheduler để tạo các phân vùng cho tương lai (ví dụ: tạo trước 3-6 tháng tới).

Đây là một đoạn script Bash đơn giản mình hay dùng để tạo phân vùng tháng:

#!/bin/bash

DB_NAME="your_database"
DB_USER="your_user"
TABLE_NAME="audit_logs"

# Lấy tháng và năm hiện tại
CURRENT_DATE=$(date +%Y-%m-01)

# Tạo phân vùng cho 2 tháng tới
for i in $(seq 0 1); do
    PARTITION_DATE=$(date -d "$CURRENT_DATE + $i months" +%Y-%m-01)
    NEXT_PARTITION_DATE=$(date -d "$CURRENT_DATE + $((i+1)) months" +%Y-%m-01)
    PARTITION_NAME="${TABLE_NAME}_$(date -d "$PARTITION_DATE" +%Y_%m)"

    echo "Checking for partition ${PARTITION_NAME}..."

    # Kiểm tra xem partition đã tồn tại chưa trước khi tạo
    psql -U "$DB_USER" -d "$DB_NAME" -tAc "SELECT 1 FROM pg_class WHERE relname='${PARTITION_NAME}'" | grep -q 1
    if [ $? -eq 0 ]; then
        echo "Partition ${PARTITION_NAME} already exists. Skipping."
    else
        echo "Creating partition ${PARTITION_NAME}..."
        psql -U "$DB_USER" -d "$DB_NAME" <<-EOSQL
            CREATE TABLE ${PARTITION_NAME} PARTITION OF ${TABLE_NAME}
            FOR VALUES FROM ('${PARTITION_DATE} 00:00:00+00') TO ('${NEXT_PARTITION_DATE} 00:00:00+00');
EOSQL
        echo "Partition ${PARTITION_NAME} created."
    fi
done

Lưu script này vào một file (ví dụ: create_partitions.sh), cấp quyền thực thi (chmod +x create_partitions.sh) và đặt vào cron job để chạy hàng tháng.

Phân vùng mặc định (DEFAULT Partition)

Đôi khi, dữ liệu có thể không khớp với bất kỳ phân vùng nào bạn đã định nghĩa. Để tránh lỗi, bạn có thể tạo một phân vùng DEFAULT để chứa tất cả các bản ghi “ngoại lệ” đó.

CREATE TABLE audit_logs_default PARTITION OF audit_logs DEFAULT;

Cảnh báo: Phân vùng DEFAULT có thể trở thành một điểm nóng (hotspot) nếu có quá nhiều dữ liệu rơi vào đó, làm mất đi lợi ích của phân vùng. Mình chỉ dùng nó như một “catch-all” tạm thời và luôn có quy trình để kiểm tra và xử lý dữ liệu trong phân vùng này. Nếu có quá nhiều dữ liệu vào đây, đó là dấu hiệu bạn cần điều chỉnh lại chiến lược phân vùng.

Detach và Attach phân vùng “không downtime”

Khả năng DETACH (tách) và ATTACH (gắn) một phân vùng là một trong những tính năng mạnh mẽ nhất để quản lý dữ liệu mà không gây gián đoạn.

  • DETACH: Tách một bảng con ra khỏi bảng chính. Bản con đó vẫn tồn tại như một bảng độc lập. Hữu ích khi bạn muốn lưu trữ dữ liệu cũ (archive) hoặc xóa chúng một cách nhanh chóng.
  • ATTACH: Gắn một bảng độc lập (phải có cấu trúc cột giống hệt bảng chính và không có dữ liệu nằm ngoài phạm vi phân vùng) vào bảng chính như một phân vùng con mới. Điều này cực kỳ hữu ích khi bạn muốn nạp một lượng lớn dữ liệu vào một phân vùng riêng, xử lý nó, rồi mới gắn vào bảng chính.
    Ví dụ: Bạn có dữ liệu lịch sử từ một nguồn khác cần nhập vào. Hãy tạo một bảng mới với cấu trúc tương tự, nạp dữ liệu vào bảng đó, sau đó ATTACH nó vào bảng chính. Việc này nhanh hơn rất nhiều so với INSERT từng dòng vào bảng đã được phân vùng.

    -- Tạo bảng tạm để chứa dữ liệu
CREATE TABLE audit_logs_temp (
    log_id BIGSERIAL NOT NULL,
    action_type VARCHAR(50) NOT NULL,
    user_id INT NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

-- ... Nạp dữ liệu vào audit_logs_temp ...

-- Gắn bảng tạm vào làm partition
ALTER TABLE audit_logs ATTACH PARTITION audit_logs_temp
FOR VALUES FROM ('2024-01-01 00:00:00+00') TO ('2024-02-01 00:00:00+00');

Partition Pruning và Constraint Exclusion

Đây là hai kỹ thuật mà PostgreSQL sử dụng để tối ưu truy vấn trên các bảng phân vùng:

  • Partition Pruning (Cắt tỉa phân vùng): Mặc định bật từ PostgreSQL 11. Khi có một câu truy vấn, optimizer của PostgreSQL sẽ phân tích điều kiện WHERE và chỉ chọn các phân vùng có khả năng chứa dữ liệu cần tìm để quét. Các phân vùng khác sẽ bị loại bỏ hoàn toàn khỏi kế hoạch thực thi. Đây là lý do chính giúp truy vấn nhanh hơn rất nhiều.
  • Constraint Exclusion (Loại trừ theo ràng buộc): Đây là một kỹ thuật cũ hơn (trước PostgreSQL 10 thường dùng cho partitioning thủ công bằng trigger) nhưng vẫn hoạt động song song với partition pruning. Nó dựa trên các ràng buộc CHECK trên từng phân vùng con để loại bỏ chúng. Với native partitioning, partition pruning làm công việc này hiệu quả hơn.

Bạn có thể kiểm tra xem partition pruning có đang hoạt động hay không bằng cách dùng EXPLAIN. Nếu thấy các dòng Partition pruning: ... là nó đang hoạt động.

4. Tips thực tế và kinh nghiệm cá nhân

Sau thời gian làm việc trực tiếp với partitioning, mình có vài lời khuyên nhỏ nhưng có võ muốn chia sẻ:

  • Khi nào nên dùng:

    • Bảng có kích thước siêu lớn (hàng chục triệu bản ghi trở lên), và vẫn đang tiếp tục tăng trưởng.
    • Các truy vấn thường xuyên lọc dữ liệu dựa trên một khoảng thời gian hoặc một tập hợp giá trị cụ thể.
    • Bạn cần xóa hoặc lưu trữ dữ liệu cũ một cách thường xuyên và nhanh chóng.
  • Khi nào nên cân nhắc kỹ:

    • Bảng của bạn còn nhỏ, chưa đạt đến mức gây ra vấn đề về hiệu suất. Chi phí quản lý các phân vùng có thể lớn hơn lợi ích mang lại.
    • Các truy vấn của bạn ít khi lọc theo khóa phân vùng. Khi đó, PostgreSQL vẫn sẽ phải quét tất cả các phân vùng, thậm chí có thể chậm hơn do overhead.
  • Chọn khóa phân vùng (Partition Key) thông minh: Đây là yếu tố then chốt. Khóa phân vùng lý tưởng là cột có tính chất tăng dần (như thời gian created_at) hoặc có các giá trị rời rạc, ít thay đổi (như region). Tránh chọn các cột có giá trị quá phân tán hoặc thường xuyên thay đổi.
  • Kích thước phân vùng: Không có một con số thần thánh nào. Phân vùng quá nhỏ sẽ gây ra overhead quản lý (quá nhiều file, quá nhiều bảng con để theo dõi). Phân vùng quá lớn sẽ làm mất đi lợi ích về hiệu suất. Mình thường nhắm đến kích thước mỗi phân vùng là vài GB đến vài chục GB, hoặc chứa khoảng vài triệu đến vài chục triệu bản ghi. Đối với các bảng log, phân vùng theo tháng là lựa chọn tốt.
  • Kinh nghiệm cá nhân với dữ liệu: Trong quá trình làm việc, có những lúc mình cần chuyển đổi định dạng dữ liệu nhanh chóng để import vào các bảng đã phân vùng. Đặc biệt khi dữ liệu đầu vào là CSV và mình cần nó ở định dạng JSON để chèn vào cột JSONB chẳng hạn. Lúc đó, mình hay dùng converter tại toolcraft.app/vi/tools/data/csv-to-json. Nó chạy trực tiếp trên trình duyệt nên mình không phải lo lắng về việc lộ dữ liệu nhạy cảm, rất tiện lợi và an toàn khi xử lý dữ liệu để chèn vào các bảng đã phân vùng theo đúng cấu trúc mình mong muốn.
  • Giám sát hiệu suất: Sau khi triển khai phân vùng, luôn theo dõi hiệu suất hệ thống và các truy vấn quan trọng. pg_stat_statements và EXPLAIN ANALYZE là những công cụ không thể thiếu để xác nhận rằng phân vùng đang hoạt động như mong đợi và mang lại lợi ích.

Kết luận

Phân vùng bảng trong PostgreSQL là kỹ thuật mạnh mẽ, rất cần thiết để quản lý các bảng dữ liệu khổng lồ trong môi trường production. Nó không chỉ giúp tăng tốc độ truy vấn một cách đáng kinh ngạc mà còn đơn giản hóa việc bảo trì và quản lý dữ liệu. Mặc dù có một chút “đường cong học tập” ban đầu, nhưng những lợi ích nó mang lại chắc chắn sẽ vượt xa công sức bạn bỏ ra. Hãy bắt đầu áp dụng partitioning ngay hôm nay để tối ưu database và nâng cao hiệu suất hệ thống!

Share:
Tags: