Beban time-series tersebar di banyak ranah, dan setiap ranah membawa karakteristik berbeda pada sisi penulisan serta pembacaan. Topik ini memetakan empat ranah utama, yaitu pemantauan infrastruktur, sensor IoT, pasar keuangan, dan data event, beserta pihak yang lazim mengelola masing-masing. Setelah membaca topik ini, pemetaan antara kebutuhan domain dan pilihan basis data time-series menjadi lebih nyata.
Pemantauan infrastruktur dan aplikasi#
Pemantauan infrastruktur adalah ranah yang paling lazim digunakan sebagai contoh data time-series. Metrik seperti penggunaan CPU, jejak memori, latensi permintaan HTTP, dan jumlah koneksi aktif dikumpulkan secara periodik dari setiap host, kontainer, atau layanan. Pola penulisan didominasi oleh penambahan ke ujung termutakhir, sedangkan pola pembacaan didominasi oleh agregasi atas jendela waktu, seperti rerata, kuantil, dan maksimum, untuk keperluan dashboard dan alerting. Karakteristik ini membuat basis data time-series menjadi pilihan alami.
Di ekosistem open source, Prometheus menjadi standar de facto untuk pengumpulan metrik berbasis pull, dengan penyimpanan internal yang berbentuk deret waktu. Data historis yang lebih panjang sering dialihkan ke basis data time-series eksternal seperti Thanos, Mimir, atau VictoriaMetrics. Di sisi visualisasi, Grafana menjadi standar yang hampir universal, dan query yang digunakan biasanya adalah PromQL atau Flux. Pemilik beban ini adalah tim platform atau tim SRE (site reliability engineering), dan SLA pemantauan biasanya lebih longgar daripada SLA aplikasi inti.
Sensor IoT dan telemetri lapangan#
Ranah IoT menambah satu dimensi yang tidak ada di pemantauan infrastruktur, yaitu ketidakpastian jaringan dan keterbatasan daya. Sensor di lapangan sering tidak selalu tersambung, sehingga data bisa datang terlambat (late arrival) atau bahkan tidak terurut (out-of-order). Perangkat mungkin mengirim batch hanya beberapa jam sekali untuk menghemat baterai, sehingga pola penulisan tidak lagi berbentuk aliran searah yang halus. Pola pembacaan sering melibatkan query last-known-value untuk mengetahui status terakhir per perangkat, bukan agregasi atas jendela panjang.
Pemiliknya biasanya tim operasi lapangan atau tim produk yang bertanggung jawab atas aset fisik. Pilihan basis data beragam, mulai dari InfluxDB yang populer di ekosistem IoT karena dukungan line protocol dan skema tag/field yang ringkas, hingga TimescaleDB yang dipilih karena kebutuhan akan SQL penuh dan integrasi dengan tabel relasional lain. Karakteristik kardinalitas tag seperti device_id menjadi pertimbangan besar di ranah ini, sebab jumlah perangkat dapat mencapai jutaan, dan setiap perangkat unik menambah satu deret baru pada indeks.
Pasar keuangan dan data event#
Pasar keuangan menghasilkan data tick yang sangat padat. Setiap perdagangan, setiap perubahan kuotasi, dan setiap perubahan order book adalah titik data dengan cap waktu presisi tinggi, sering milidetik atau mikrodetik. Pola penulisan berbentuk burst yang mengikuti jam perdagangan, sedangkan pola pembacaan didominasi oleh agregasi candlestick (OHLC, open-high-low-close) dan perhitungan indikator teknikal berbasis jendela bergeser. Volume pada jam sibuk dapat mencapai ratusan ribu titik per detik untuk satu instrumen saja, sehingga pemilihan mesin sangat memengaruhi biaya infrastruktur.
Data event adalah kerabat dekat yang strukturnya mirip, yaitu peristiwa dengan cap waktu, tetapi nilainya bersifat kategoris atau bahkan string JSON. Contohnya adalah clickstream pada situs web, log audit, dan jejak transaksi. Banyak organisasi yang menyatukan keduanya ke dalam basis data time-series yang sama, dengan skema tag/field yang cukup luwes untuk menampung tipe data beragam. Pemiliknya adalah tim data atau tim engineering produk, dan tuntutan retensi bervariasi dari beberapa minggu untuk debugging hingga beberapa tahun untuk audit kepatuhan.
Pemilik dan operator masing-masing ranah#
Tabel berikut merangkum keempat ranah, pihak yang lazim mengelola, dan sebagian pilihan mesin yang umum dijumpai saat ini. Pemiliknya bervariasi, dan variasi tersebut menentukan SLA, kebijakan retensi, dan ekspektasi terhadap basis data time-series yang digunakan. Banyak keputusan desain yang tampak teknis sebenarnya berakar pada siapa pemiliknya dan apa yang menjadi prioritas operasionalnya.
| Ranah | Pemilik lazim | Karakter penulisan | Pilihan umum |
|---|---|---|---|
| Pemantauan | SRE atau platform | Aliran searah, presisi detik | Prometheus, Thanos, Mimir |
| IoT | Operasi lapangan atau produk | Burst, late arrival, batch hemat daya | InfluxDB 3.x, TimescaleDB |
| Keuangan | Tim data atau quant | Burst padat, presisi sub-milidetk | kdb+, ClickHouse, TimescaleDB |
| Event | Tim engineering produk | Volume tinggi, nilai kategoris | ClickHouse, InfluxDB 3.x |
Pemetaan ini tidak baku. Banyak organisasi yang menggunakan satu mesin untuk beberapa ranah, dan keputusan akhir sering dipengaruhi oleh ekosistem alat yang sudah ada. Yang penting dipahami adalah bahwa sifat time-series tampak serupa dari jauh, tetapi implikasi praktis pada skema dan operasional sangat dipengaruhi oleh ranah yang dilayani. Pemantauan, misalnya, dapat menerima kehilangan beberapa titik data tanpa dampak bisnis besar, sedangkan keuangan tidak. Perbedaan toleransi ini memengaruhi pilihan retensi, kebijakan replikasi, dan postur pemulihan bencana, bukan hanya pilihan mesin.
Demo visualisasi data time-series#
Tampilan visual adalah ujung yang paling sering dilihat dari basis data time-series. Demo berikut menampilkan dua deret sederhana (suhu dan kelembapan) sebagai grafik garis statis yang dirender sepenuhnya di sisi klien. Tidak ada panggilan jaringan, tidak ada pustaka eksternal, dan data tertanam langsung di dalam berkas. Tujuannya menunjukkan bahwa pemahaman dasar tentang time-series tidak tergantung pada stack kompleks, dan bentuk dasar grafik garis tetap sama meskipun mesin di belakangnya berbeda.
Kode sumber demo
<!doctype html>
<html lang="id">
<head>
<meta charset="utf-8" />
<title>Visualisasi deret waktu sederhana</title>
<style>
body { font-family: system-ui, -apple-system, sans-serif; margin: 16px; color: #1f2937; }
h2 { font-size: 16px; margin: 0 0 8px 0; font-weight: 600; }
.legend { display: flex; gap: 16px; margin-bottom: 8px; font-size: 13px; }
.legend span { display: inline-flex; align-items: center; gap: 6px; }
.swatch { width: 12px; height: 12px; border-radius: 2px; }
svg { width: 100%; height: 220px; background: #fafafa; border: 1px solid #e5e7eb; }
.grid { stroke: #e5e7eb; stroke-width: 1; }
.axis { font-size: 10px; fill: #6b7280; }
.line-suhu { fill: none; stroke: #ef4444; stroke-width: 2; }
.line-lembap { fill: none; stroke: #3b82f6; stroke-width: 2; }
</style>
</head>
<body>
<h2>Telemetri 60 menit pertama sensor-01</h2>
<div class="legend">
<span><span class="swatch" style="background:#ef4444"></span> Suhu (C)</span>
<span><span class="swatch" style="background:#3b82f6"></span> Kelembapan (%)</span>
</div>
<svg id="chart" viewBox="0 0 480 220" preserveAspectRatio="none">
<line class="grid" x1="0" y1="55" x2="480" y2="55" />
<line class="grid" x1="0" y1="110" x2="480" y2="110" />
<line class="grid" x1="0" y1="165" x2="480" y2="165" />
<polyline id="line-suhu" class="line-suhu" />
<polyline id="line-lembap" class="line-lembap" />
<text class="axis" x="6" y="14">25</text>
<text class="axis" x="6" y="219">22</text>
<text class="axis" x="436" y="14">65</text>
<text class="axis" x="436" y="219">55</text>
<text class="axis" x="200" y="219">00:00</text>
<text class="axis" x="430" y="219">01:00</text>
</svg>
<script>
// 12 titik contoh (interval 5 menit dalam 1 jam pertama).
const suhu = [24.06, 23.81, 24.18, 24.42, 24.55, 24.61, 24.59, 24.50, 24.36, 24.18, 24.02, 23.91];
const lembap = [60.34, 61.36, 59.61, 58.92, 58.40, 58.18, 58.30, 58.78, 59.55, 60.41, 61.10, 61.51];
function buatPolyline(data, yMin, yMax) {
const W = 480, H = 220, padX = 8, padY = 8;
const xStep = (W - 2 * padX) / (data.length - 1);
return data.map((v, i) => {
const x = padX + i * xStep;
const y = H - padY - ((v - yMin) / (yMax - yMin)) * (H - 2 * padY);
return x.toFixed(1) + "," + y.toFixed(1);
}).join(" ");
}
document.getElementById("line-suhu").setAttribute("points", buatPolyline(suhu, 22, 25));
document.getElementById("line-lembap").setAttribute("points", buatPolyline(lembap, 55, 65));
</script>
</body>
</html>Pola yang ditampilkan, yaitu dua deret yang berfluktuasi seiring waktu, adalah inti visualisasi time-series. Mesin basis data yang dipilih pada akhirnya harus mampu menjawab pertanyaan yang sama: nilai terbaru, rerata selama satu jam, dan puncak selama satu hari. Perbedaan antara TimescaleDB dan InfluxDB 3.x pada jalur ini terletak pada cara menjawab, bukan pada bentuk pertanyaannya. Pada dashboard produksi yang sebenarnya, deret seperti ini sering diperhalus oleh fungsi downsampling agar kepadatan titik tidak menenggelamkan layar.
Kesalahan umum#
- Menyamakan kebutuhan retensi pemantauan dengan kebutuhan audit keuangan. Pemantauan biasanya cukup mingguan, sedangkan audit keuangan sering menuntut beberapa tahun. Menyatukan keduanya tanpa kebijakan retensi terpisah membebani penyimpanan.
- Mengabaikan late arrival di ranah IoT. Skema yang menganggap data selalu terurut dapat menolak atau menurunkan data yang datang terlambat, padahal hal itu lazim di lapangan.
- Memilih basis data hanya karena populer di ranah lain. TimescaleDB dan InfluxDB 3.x memiliki kekuatan yang berbeda, dan keputusan sebaiknya didasarkan pada pola akses dan ekosistem alat yang sudah digunakan.
Ringkasan#
- Empat ranah utama time-series adalah pemantauan, IoT, keuangan, dan data event.
- Setiap ranah memiliki karakter penulisan dan pembacaan yang khas, yang memengaruhi pilihan skema dan kebijakan retensi.
- Pemiliknya berbeda-beda, yaitu SRE, operasi lapangan, tim data, dan tim engineering produk.
- Pilihan mesin dipengaruhi oleh ekosistem alat yang sudah ada, bukan hanya spesifikasi teknis.
Referensi#
- Overview — Prometheus — Penjelasan resmi tentang model data Prometheus yang berbasis deret waktu dengan label.
- Storage — Prometheus — Detail penyimpanan lokal Prometheus dan alasan retensi jangka pendek menjadi default.
- Grafana documentation — Grafana Labs — Dokumentasi resmi perangkat visualisasi yang lazim digunakan untuk dashboard time-series.