TimescaleDB Compression: Tối ưu hóa lưu trữ chuỗi thời gian với Hypercore và lưu trữ dạng cột

TimescaleDB, một phần mở rộng mạnh mẽ của PostgreSQL dành cho dữ liệu chuỗi thời gian (time-series), nổi tiếng với khả năng nén dữ liệu ấn tượng có thể đạt tới 98%. Tuy nhiên, để đạt được con số này, TimescaleDB sử dụng một phương pháp tiếp cận hoàn toàn khác so với các thuật toán nén chung có trong các cơ sở dữ liệu OLTP thông thường.

Bài viết này sẽ đi sâu vào cách hoạt động của động cơ Hypercore, sự khác biệt giữa nó và cơ chế TOAST của PostgreSQL, cũng như cách cấu hình để tận dụng tối đa khả năng nén cho các dự án IoT hay giám sát hệ thống.

TimescaleDB Hypercore Compression

Sự khác biệt giữa TimescaleDB và PostgreSQL TOAST

PostgreSQL có sẵn một cơ chế nén gọi là TOAST (The Oversized-Attribute Storage Technique). Tuy nhiên, TimescaleDB giải quyết một vấn đề cơ bản khác:

• TOAST: Xử lý các giá trị riêng lẻ quá lớn (chuỗi dài, jsonb, bytea). Nén từng giá trị một cách độc lập.
• TimescaleDB Hypercore: Tối ưu hóa các mô hình xuyên suốt nhiều dòng (cross-row patterns) trong dữ liệu chuỗi thời gian.

Hai cơ chế này bổ trợ cho nhau chứ không cạnh tranh. TimescaleDB thậm chí còn sử dụng TOAST nội bộ cho một số kiểu dữ liệu nhất định khi cần thiết.

Bảng so sánh dưới đây cho thấy quy mô khác biệt về hiệu quả nén:

Đặc điểm	TOAST (PostgreSQL gốc)	TimescaleDB Hypercore
Mục tiêu thiết kế	Giá trị đơn lẻ > 2 KB	Mô hình across-row trong time-series
Kích hoạt	Dòng vượt quá ngưỡng (~2 KB)	Chính sách theo chunk (ví dụ: dữ liệu cũ hơn 7 ngày)
Thuật toán	pglz, lz4	Delta encoding, Delta-of-delta, RLE, Gorilla XOR
Tỷ lệ nén float	~1.0× (không nén)	10-20×
Tỷ lệ nén timestamp	~1.0× (kiểu độ dài cố định)	50-100×

Như vậy, với khối lượng công việc điển hình của IoT chứa các số thực (float) và dấu thời gian (timestamp) — những thứ mà TOAST gần như không thể nén — TimescaleDB có thể đạt tỷ lệ nén từ 10 đến 100 lần.

Động cơ Hypercore và nén dạng cột (Columnar Compression)

Trong TimescaleDB, quá trình nén được xử lý bởi một động cơ gọi là Hypercore. Đây là một động cơ kết hợp giữa hàng và cột (hybrid row-columnar):

• Dữ liệu mới được ghi vào các chunk dạng hàng (row-based) của Postgres để đảm bảo tốc độ INSERT và UPDATE nhanh.
• Các chunk cũ hơn sẽ tự động được chuyển đổi sang dạng nén cột (columnar).

Việc chuyển đổi này giúp các truy vấn phân tích đọc ít byte hơn và chạy nhanh hơn, đồng thời giảm đáng kể chi phí lưu trữ.

Cách Hypercore xử lý dữ liệu

Khi chuyển đổi một chunk, Hypercore nhóm các dòng thành các lô (batch) khoảng 1000 dòng. Mỗi lô này trở thành một dòng duy nhất trong bảng nén, trong đó các cột là các mảng dữ liệu.

Mỗi lô nén:

• Đóng gói dữ liệu dạng cột vào các mảng nén chứa tối đa 1000 giá trị cho mỗi cột.
• Sử dụng định dạng ưu tiên cột (column-major) bên trong lô, cho phép quét hiệu quả bằng cách đặt các giá trị của cùng một cột cạnh nhau.
• Áp dụng các kỹ thuật nén cấp cột nâng cao như Run-length encoding (RLE), Delta encoding, và Gorilla compression.

Các thuật toán nén chuyên biệt

TimescaleDB không sử dụng "một kích cỡ vừa cho tất cả". Nó chọn thuật toán dựa trên kiểu dữ liệu của từng cột để đạt hiệu quả cao nhất.

1. Delta Encoding và Delta-of-Delta

Đây là kỹ thuật cực kỳ hiệu quả cho dữ liệu số thay đổi nhỏ.

• Delta Encoding: Thay vì lưu giá trị tuyệt đối (ví dụ: 72.5, 72.7, 72.4), ta chỉ lưu sự thay đổi so với điểm dữ liệu trước đó (+0.2, -0.3).
• Delta-of-Delta: Áp dụng cho timestamp. Nếu khoảng thời gian giữa các lần đo là cố định (ví dụ: luôn 5 giây), thì "sự thay đổi của sự thay đổi" sẽ bằng 0. Điều này cho phép lưu trữ thời gian với cực ít byte.

2. Run-Length Encoding (RLE)

Dùng cho các cột có giá trị lặp lại liên tục qua nhiều dòng, chẳng hạn như machine_id, sensor_type hoặc trạng thái thiết bị.

Thay vì lưu chuỗi "MACHINE_001" 5 lần (tốn ~55 byte), RLE lưu giá trị đó một lần kèm theo bộ đếm (tốn ~15 byte). Với hàng triệu dòng, mức tiết kiệm là khổng lồ.

3. Gorilla XOR (Dựa trên thuật toán của Facebook)

Dùng cho các cột số thực (float) không có nhiều sự lặp lại nhưng có giá trị tương tự nhau (ví dụ: độ rung, nhiệt độ). Khi thực hiện phép XOR giữa hai số thực float liền kề, kết quả sẽ có nhiều bit 0 ở đầu và cuối. Ta chỉ cần lưu phần "bit có nghĩa" ở giữa thay vì cả 64 bit.

Cấu hình quan trọng: segmentby và orderby

Để đạt được tỷ lệ nén tối đa, việc chọn hai tham số này là quan trọng nhất. Chúng quyết định cách các dòng được nhóm lại với nhau trước khi nén.

segmentby

Đây là cột có giá trị được chia sẻ trên toàn bộ một lô (ví dụ: machine_id hoặc sensor_id). Giá trị này chỉ được lưu một lần cho mỗi lô.

• Nếu chọn sai (ví dụ segmentby có quá nhiều giá trị duy nhất cao), mỗi "segment" sẽ có quá ít dòng, các lô sẽ không được điền đầy và nén sẽ kém hiệu quả.
• Quy tắc: Mỗi segment nên chứa ít nhất 100 dòng trong một chunk, và tối ưu là 100–10.000 giá trị segmentby duy nhất cho mỗi chunk.

orderby

Thứ tự sắp xếp bên trong lô (thường là time DESC). Sắp xếp theo thời gian giúp delta encoding và delta-of-delta phát huy tối đa tác dụng, vì các giá trị liền kề sẽ có sự khác biệt nhỏ.

Ví dụ cấu hình:

ALTER TABLE iot_sensor_data SET (
  timescaledb.compress,
  timescaledb.segmentby = 'machine_id',
  timescaledb.orderby = 'time DESC'
);

Tác động đến hiệu suất truy vấn

Một câu hỏi thường gặp là: Nén có làm chậm truy vấn không?

Câu trả lời ngắn gọn: Với các truy vấn chuỗi thời gian điển hình, nó làm tăng tốc độ.

• Truy vấn nhanh hơn: Các truy vấn quét khoảng thời gian với tổng hợp (SUM, AVG, MAX) hoặc có bộ lọc trên cột segmentby sẽ chạy nhanh hơn nhiều do giảm I/O (đọc ít dữ liệu đĩa hơn).
• Truy vấn có thể chậm hơn: Tìm kiếm một dòng đơn lẻ (point lookup) hoặc UPDATE/DELETE trên chunk đã nén (do phải giải nén -> sửa -> nén lại).

Cách triển khai và kiểm tra

Để kích hoạt nén tự động cho dữ liệu cũ hơn 7 ngày:

-- Cấu hình columnstore cho giám sát cảm biến IoT
ALTER TABLE iot_sensor_data SET (
  timescaledb.compress,
  timescaledb.segmentby = 'machine_id',
  timescaledb.orderby = 'time DESC'
);

-- Chính sách tự động chuyển đổi chunk cũ hơn 7 ngày
SELECT add_compression_policy('iot_sensor_data', INTERVAL '7 days');

Bạn có thể kiểm tra xem segmentby có hoạt động hiệu quả với dữ liệu của mình hay không bằng cách đếm số lượng dòng cho mỗi giá trị ID trong một chunk cụ thể. Nếu hầu hết các ID đều có dưới 100 dòng, bạn nên cân nhắc lại chiến lược phân đoạn của mình.

Kết luận

Nếu bạn đang lên kế hoạch triển khai TimescaleDB, đặc biệt cho các ứng dụng IoT, giám sát sản xuất hay hệ thống tài chính, việc hiểu rõ cách Hypercore nén dữ liệu là rất quan trọng. Việc cấu hình đúng segmentby và orderby có thể giúp bạn đạt được tỷ lệ nén 15 thay vì chỉ 2 lần, giúp tiết kiệm đáng kể chi phí lưu trữ và cải thiện hiệu suất hệ thống.