Phương Trình Tính chunk_time_interval (25% RAM), Nén Cột & Ổ Cứng NVMe Trên TimescaleOps
Giải thích hệ phương trình toán học PostgreSQL 16 và TimescaleDB đứng sau công cụ tính cảm biến IoT, chunk_time_interval 25% RAM và dung lượng NVMe của TimescaleOps.
Mọi con số dung lượng và đoạn mã SQL sinh ra trên TimescaleOps đều được tính toán tất định từ cấu trúc byte vật lý của dòng dữ liệu PostgreSQL 16, giới hạn lưu trú B-tree trong RAM và thông số mã hóa cột Gorilla XOR / Delta-of-Delta / ZSTD theo tài liệu chính thức.
// Hệ Phương Trình Tất Định TimescaleOps (src/sizer-engine.mjs)
rows_per_sec = sensor_count * sampling_hz
rows_per_day = rows_per_sec * 86,400
heap_bytes_per_row = ceil((40 + metrics_per_row * 4) / 8) * 8
index_bytes_per_row = 18
daily_raw_gb = rows_per_day * (heap_bytes_per_row + index_bytes_per_row) / 1e9
// 1. Quy tắc giữ B-Tree Index của Chunk Hypertable đang mở <= 25% RAM DDR5
ram_target_25pct_gb = 0.25 * recommended_ram_gb
active_chunk_idx_gb = chunk_days * daily_index_gb * residency_factor
optimal_chunk = max(interval in ['7d','1d','6h','1h']
where interval <= hot_days
and active_chunk_idx_gb <= ram_target_25pct_gb)
// 2. Dung lượng ổ nóng NVMe chưa nén + Kho lạnh nén cột
hot_uncompressed_gb = daily_raw_gb * hot_days * 1.12
compressed_cold_gb = (daily_heap_gb / compression_factor) * 1.28 * cold_days
total_retained_nvme = ceil((hot_uncompressed_gb + compressed_cold_gb) * 1.20 / 5) * 5| Tham Số Mô Hình | Giá Trị Mặc Định | Nguồn Tài Liệu Kỹ Thuật Chính Thức |
|---|---|---|
HeapTupleHeaderData |
23 bytes + 1B null bitmap (8B MAXALIGN) | PostgreSQL 16 Storage Page Layout Documentation |
Composite B-Tree Index Row |
~18 bytes / row | PostgreSQL 16 B-Tree Deduplication on (device_id, ts DESC) |
Active Chunk RAM Ceiling |
25% of System DDR5 RAM | TimescaleDB timescaledb-tune shared_buffers Sizing Guide |
Columnar Batch Size |
1,000 rows per compressed segment | TimescaleDB Gorilla XOR + Delta-of-Delta Columnar Storage Docs |
-
TRỤ CỘT 01 // HÌNH HỌC TUPLE POSTGRESQL 16 Tiêu Đề Tuple 23-Byte Của PostgreSQL 16 & Khử Trùng Khóa B-Tree Hypertable
Chúng tôi mô hình hóa dòng hypertable cảm biến IoT độ rộng vừa gồm 23 byte HeapTupleHeaderData, 1 byte bitmap null, 8 byte TIMESTAMPTZ, 8 byte khóa số nguyên định danh thiết bị/trạm và các cột cảm biến REAL 4 byte căn chỉnh theo bội số 8 byte, cộng thêm 18 byte mỗi dòng cho chỉ mục kép (device_id, ts DESC).
-
TRỤ CỘT 02 // RÀO CHẮN 25% RAM CHO CHUNK NÓNG Giữ Chỉ Mục Chunk Đang Ghi & Biên Giao Thời Nằm Gọn Trong shared_buffers
Bộ chọn chunk của TimescaleOps kiểm tra lần lượt từ khoảng rộng xuống hẹp (7d -> 1d -> 6h -> 1h). Khoảng chia được chọn phải nhỏ hơn hoặc bằng số ngày nóng chưa nén và có dung lượng chỉ mục B-tree nhân hệ số biên (1.25x–1.85x) nằm dưới 25% tổng RAM máy chủ.
-
TRỤ CỘT 03 // HỆ SỐ NÉN CỘT GORILLA, DELTA-OF-DELTA & ZSTD Mô Hình Hóa Hệ Số Nén Chunk Lạnh & Siêu Dữ Liệu Lô 1.000 Dòng Trong TimescaleDB
Khi chunk cũ chuyển sang định dạng lô cột 1.000 dòng phân nhóm theo mã thiết bị và sắp xếp theo ts DESC, toàn bộ cây B-tree từng dòng được gỡ bỏ, chỉ còn siêu dữ liệu phân đoạn nhẹ (nhân hệ số 1.28x trên dữ liệu nén). Kỹ sư có thể tùy chỉnh trực tiếp hệ số nén từ 6x đến 15x ngay trong công cụ #tso-calc.
-
TRỤ CỘT 04 // ĐỆM NHẬT KÝ WAL & KHOẢNG TRỐNG AN TOÀN 20% Dự Phòng 12% Đệm WAL/Sort & 20% Dung Lượng Trống NVMe/ZFS Trên TimescaleOps
Vận hành ổ đĩa PostgreSQL hoặc ZFS đầy trên 85% làm giảm hiệu suất ghi NVMe và dễ thiếu không gian tạm khi nén lại các chunk lớn. Vì vậy đầu ra Tổng NVMe Cần Cấp luôn cộng sẵn 12% đệm WAL trên tầng nóng và 20% khoảng trống toàn ổ.