Cách Chọn chunk_time_interval Cho Hypertable TimescaleDB (Quy Tắc 25% RAM)
Hướng dẫn tính toán tất định chunk_time_interval (1h, 6h, 1d, 7d) trên TimescaleOps để toàn bộ B-tree index của chunk đang ghi nằm gọn dưới 25% RAM.
Theo tài liệu phân mảnh chính thức của TimescaleDB, tốc độ ghi sẽ nghẽn bởi thao tác đọc-ghi trang ngẫu nhiên ngay khi cây chỉ mục B-tree của chunk hiện hành tràn khỏi vùng đệm shared_buffers. Trên TimescaleOps, chúng tôi áp dụng phương trình ngân sách 25% RAM để chọn mốc 7d, 1d, 6h hoặc 1h.
| Quy Mô Luồng Mẫu | Chu Kỳ Chunk / Phân Vùng | RAM DDR5 Khuyến Nghị | Dung Lượng Ổ Đĩa Ước Tính | Cấu Hình Hạ Tầng Tham Chiếu |
|---|---|---|---|---|
| 1K metrics/s (86M/day) | 7d (INTERVAL 7 days) |
8 GB DDR5 | ~38 GB / yr | Hostinger KVM 2 (8GB) |
| 10K metrics/s (864M/day) | 1d (INTERVAL 1 day) |
16 GB DDR5 | ~365 GB / yr | InterServer KVM 16GB / Hostinger KVM 4 |
| 50K metrics/s (4.3B/day) | 6h (INTERVAL 6 hours) |
32 GB DDR5 | ~1.82 TB / yr | InterServer Ryzen Storage / UltaHost VDS |
| 500K metrics/s (43B/day) | 1h (INTERVAL 1 hour) |
128 GB DDR5 | ~18.1 TB / yr | InterServer Bare-Metal 128GB + 20TB ZFS |
-- Audit uncompressed hypertable chunk index sizes against 25% of system RAM
SELECT
chunk_schema || '.' || chunk_name AS chunk,
pg_size_pretty(index_bytes) AS btree_index_size,
pg_size_pretty(table_bytes) AS heap_size,
is_compressed
FROM chunks_detailed_size('fleet_grid_telemetry')
ORDER BY chunk_name DESC
LIMIT 8;
-- Update future chunk_time_interval online without rewriting closed chunks
SELECT set_chunk_time_interval('fleet_grid_telemetry', INTERVAL '6 hours');1. Vì Sao Vượt Ngưỡng 25% RAM Khiến Luồng Ghi Hypertable Bị Nghẽn IOPS?
Mỗi bản ghi mới đi vào hypertable chưa nén đều phải cập nhật chỉ mục kép như (asset_id, ts DESC). Dù cột thời gian tăng dần, khóa thiết bị lại phân tán ngẫu nhiên trên toàn bộ lá B-tree của chunk đang mở. Giữ tổng dung lượng index của chunk nóng dưới 25% RAM (tương ứng shared_buffers) giúp thao tác tìm trang diễn ra ngay trong RAM.
2. Tránh Bẫy Chia Chunk Quá Nhỏ Gây Phình Bảng Danh Mục pg_catalog
Đặt chunk 5–10 phút cho luồng 1K/s sẽ sinh ra hơn 50.000 chunk mỗi năm, khiến bộ lập kế hoạch truy vấn tốn thời gian khóa metadata trên pg_catalog. Nguyên tắc trên TimescaleOps là chọn khoảng thời gian rộng nhất (7d -> 1d -> 6h -> 1h) nằm dưới trần 25% RAM và đóng trước chu kỳ nén tự động.
3. Dự Phòng Hệ Số Đệm Khi Cảm Biến Gửi Bù Dữ Liệu Qua Biên Hai Chunk
Khi trạm thu thập 4G mất sóng gửi bù dữ liệu sang chunk liền kề, cả hai chunk cùng mở trong bộ nhớ. Công thức TimescaleOps nhân sẵn hệ số lưu trú 1.25x–1.85x để tránh tràn RAM lúc giao thời.
Câu Hỏi Kỹ Thuật Về TS-01 // CHUNK-25RAM Trên TimescaleOps
Chạy lệnh set_chunk_time_interval có làm khóa bảng hay ghi lại các chunk cũ không?
Không. Lệnh này chỉ áp dụng cho các chunk mới sinh ra trong tương lai nên an toàn khi chạy trực tiếp trên hệ thống đang vận hành.
Các chunk đã nén cột trong TimescaleDB có chiếm ngân sách 25% RAM cho index không?
Rất nhỏ. Khi chuyển sang định dạng nén cột, TimescaleDB gỡ bỏ B-tree từng dòng và chỉ giữ siêu dữ liệu min/max nhẹ theo từng lô 1.000 dòng.
Nên đặt thông số shared_buffers bao nhiêu trên VPS chuyên chạy TimescaleDB?
Theo khuyến nghị chính thức từ công cụ timescaledb-tune, nên đặt shared_buffers = 25% tổng RAM vật lý, phần còn lại dành cho OS Page Cache và bộ nhớ giải nén work_mem.