Mengatasi Degradasi Performa pada TimescaleDB

Pertumbuhan volume data time-series yang mencapai puluhan juta baris per hari sering memicu penurunan performa query drastis. Masalah utama biasanya berakar pada ukuran indeks B-Tree yang melampaui kapasitas shared_buffers (RAM), menyebabkan disk thrashing dan cache eviction. TimescaleDB memitigasi ini melalui hypertables yang memecah data ke dalam chunks berbasis interval waktu. Namun, hypertables tetap memerlukan strategi indeks chunk yang presisi dan implementasi compression policy berbasis kolom untuk menjaga performa prapembacaan data historis.

Strategi Indexing Chunk yang Efisien

Secara default, TimescaleDB membuat indeks pada kolom waktu saat hypertable diinisialisasi. Pada beban kerja nyata, query analitik hampir selalu menyertakan filter entitas tertentu seperti device_id atau tenant_id.

Penggunaan indeks tunggal pada kolom time memaksa PostgreSQL melakukan Bitmap Index Scan yang mahal ketika menyaring entitas. Solusinya adalah membuat composite index dengan urutan kolom yang tepat: letakkan kolom berdensitas/kardinalitas tinggi yang digunakan untuk filtering presisi di awal, diikuti oleh kolom rentang waktu.

-- Setup hypertable dengan chunk interval 1 hari
CREATE TABLE metrics (
    time TIMESTAMPTZ NOT NULL,
    device_id INT NOT NULL,
    cpu_usage DOUBLE PRECISION,
    mem_usage DOUBLE PRECISION
);

SELECT create_hypertable('metrics', 'time', chunk_time_interval => INTERVAL '1 day');

-- Composite index optimal untuk filter spesifik entitas dan rentang waktu
CREATE INDEX idx_metrics_device_time ON metrics (device_id, time DESC);

Urutan (device_id, time DESC) memungkinkan engine mengeksekusi Index Scan langsung menuju data relevan pada chunk tertentu tanpa membaca indeks chunk secara menyeluruh.

Konfigurasi Compression Policy: Segmentby dan Orderby

TimescaleDB mengonversi data baris standar menjadi format hybrid columnar saat kompresi diaktifkan. Konfigurasi segmentby dan orderby menentukan layout data fisik terkompresi:

  • timescaledb.compress_segmentby: Mengelompokkan data berdasarkan nilai diskret. Setiap kelompok diperlakukan sebagai blok mandiri. Kolom ini harus digunakan untuk parameter filter pencarian utama (seperti device_id).
  • timescaledb.compress_orderby: Mengurutkan data di dalam segmen. Standarnya adalah kolom waktu secara menurun (time DESC), memungkinkan dekompresor memotong segmen data yang tidak diperlukan (chunk-exclusion dan chunk pruning).
-- Mengaktifkan kompresi pada hypertable
ALTER TABLE metrics SET (
    timescaledb.compress,
    timescaledb.compress_segmentby = 'device_id',
    timescaledb.compress_orderby = 'time DESC'
);

-- Menerapkan policy kompresi otomatis untuk chunk lebih tua dari 7 hari
SELECT add_compression_policy('metrics', INTERVAL '7 days');

Benchmarking Throughput dan Rasio Kompresi

Verifikasi rasio kompresi dan status chunk menggunakan sistem view internal TimescaleDB:

-- Memeriksa rasio kompresi per chunk dan keseluruhan hypertable
SELECT 
    hypertable_name,
    before_compression_total_bytes,
    after_compression_total_bytes,
    ROUND(100.0 * (before_compression_total_bytes - after_compression_total_bytes) / before_compression_total_bytes, 2) AS compression_ratio_percentage
FROM hypertable_compression_stats('metrics');

Dalam pengujian tipikal data metrik metrologi IoT, skema columnar TimescaleDB umumnya mengurangi footprint disk hingga 80-90%, sekaligus memangkas I/O read secara substansial karena data yang dibaca dari disk berukuran jauh lebih ringkas.

Evaluasi EXPLAIN ANALYZE: Sebelum vs Sesudah Optimasi

Berikut perbandingan eksekusi query agregasi data historis 14 hari untuk satu perangkat tertentu.

Sebelum Optimasi (Data Uncompressed, Indeks Standar time)

EXPLAIN ANALYZE
SELECT time_bucket('1 hour', time) AS bucket, AVG(cpu_usage)
FROM metrics
WHERE device_id = 42 AND time >= NOW() - INTERVAL '14 days'
GROUP BY bucket ORDER BY bucket DESC;

/*
Planning Time: 2.145 ms
Execution Time: 482.312 ms
-> Append (cost=0.42..15234.80 rows=4032 width=16)
     -> Bitmap Heap Scan on _hyper_1_1_chunk (cost=12.45..1080.20 rows=288 width=16)
          Recheck Cond: (device_id = 42)
          Filter: (time >= ...)
          -> Bitmap Index Scan on metrics_time_idx (cost=0.00..12.38 rows=450 width=0)
Buffers: shared read=18420
*/

Sesudah Optimasi (Composite Index & Native Compression Aktif)

/*
Planning Time: 1.831 ms
Execution Time: 18.640 ms
-> Append (cost=0.28..412.30 rows=4032 width=16)
     -> Custom Scan (DecompressChunk) on _hyper_1_1_chunk (cost=0.28..28.50 rows=288 width=16)
          Filter: (device_id = 42 AND time >= ...)
Buffers: shared hit=421 read=32
*/

Waktu eksekusi terpangkas lebih dari 95%. Pengurangan operasi I/O (shared read turun drastis) terjadi karena TimescaleDB membaca segmen terkompresi secara langsung tanpa melakukan random seek ke seluruh indeks chunk.

Peringatan Produksi: Data dalam format terkompresi tidak dapat diubah (immutable secara default) sebelum didekompresi, kecuali hypertables dikonfigurasi secara eksplisit dengan dukungan DML batch insert pada versi TimescaleDB modern. Rancang rentang waktu policy kompresi di luar jendela mutasi data aplikasi (backfilling window).