📈 Data Time-Series

Timestamp, tag, field — dan kenapa database IoT bukan database biasa.

Setiap titik = timestamp + measurement + tag + field

📌 1. Anatomi Data Time-Series

titik = {
    "ts":  1234.0,              # TIMESTAMP — kapan (jantung time-series)
    "m":   "suhu",              # MEASUREMENT — apa yang diukur
    "tags": {"ruang": "kamar",  # TAG — metadata untuk FILTER (indeks cepat)
             "device": "dht22-01"},
    "v":   27.5                 # FIELD/VALUE — nilainya
}

Bagian	Peran	Contoh
Timestamp	Kapan kejadian terjadi	2026-09-10 08:30:00
Measurement	Apa yang diukur	suhu, daya, posisi
Tag	Metadata tetap untuk filter	ruang=kamar, gedung=A
Field	Nilai yang berubah	27.5 °C

💡 Kenapa tag penting? Query "suhu di ruang kamar" harus cepat — tag di-indeks, field tidak. Jangan taruh nilai yang sering berubah di tag.

📌 2. Database Time-Series (TSDB)

Database umum (MySQL/PostgreSQL) bisa menyimpan data IoT, tapi TSDB dioptimasi untuk pola IoT: tulis sangat cepat, baca per rentang waktu, kompresi tinggi.

TSDB	Karakter
InfluxDB	Populer, query language Flux/InfluxQL, ada versi cloud
TimescaleDB	Ekstensi PostgreSQL — SQL biasa, hiperscale
QuestDB	Sangat cepat untuk ingest + SQL
Prometheus	Standar monitoring infrastruktur (pull-based)

Di simulator, TimeSeriesDB memberikan API yang mirip konsepnya:

db = TimeSeriesDB()

print("=== REKAMAN DATA SUHU (12 titik, tiap 5 detik) ===")
for i in range(12):
    v = read_sensor("dht22_temp")
    db.write("suhu", v, tags={"ruang": "kamar", "device": "dht22-01"})
    delay(5)

data = db.query("suhu")
print("Titik data  :", len(data))
print("5 titik awal:")
for p in data[:5]:
    print("  t=%5.1fs  %5.1f°C  tags=%s" % (p["ts"], p["v"], p["tags"]))
print("Statistik   :", db.stats("suhu"))

Output:

📌 3. Agregasi: Menyusutkan Data

Data mentah tiap 5 detik = 17.280 titik/hari per sensor. Untuk grafik "suhu rata-rata per jam", kita agregasi: kelompokkan ke bucket waktu, hitung mean/min/max/sum.

db = TimeSeriesDB()

for i in range(30):
    db.write("suhu", read_sensor("dht22_temp"))
    db.write("rth", read_sensor("dht22_hum"))
    delay(5)

print("Total titik :", len(db.points))
print()
print("=== AGREGASI RATA-RATA PER 30 DETIK (suhu) ===")
for b in db.aggregate("suhu", 30, "mean"):
    print("  t=%5.0fs  mean=%5.2f°C  (%d sampel)" % (b["ts"], b["value"], b["count"]))
print()
print("=== AGREGASI MAX PER 30 DETIK (rth) ===")
for b in db.aggregate("rth", 30, "max"):
    print("  t=%5.0fs  max=%5.1f%%  (%d sampel)" % (b["ts"], b["value"], b["count"]))

Output:

📌 4. Retention Policy & Downsampling

Pola storage bertingkat (piramida data) yang umum di produksi:

resolusi penuh  (5 dtk)  → disimpan 7 hari
menit-an        (1 mnt)  → disimpan 1 tahun     (agregasi mean)
jam-an          (1 jam)  → disimpan 10 tahun    (agregasi mean)
harian          (1 hari) → disimpan selamanya

TimeSeriesDB(max_points=N) mensimulasikan retention: saat melebihi N titik, data terlama dibuang otomatis.

⚠️ Simpan semua data mentah selamanya = biaya storage membengkak. Pertanyaan desain pertama selalu: berapa lama dan sehalus apa data ini perlu diingat?

🧠 Latihan

Simpan 2 measurement (suhu dan co2) dengan tag berbeda, lalu query masing-masing — pastikan tidak tercampur.
Hitung agregasi max dan min per 30 detik untuk suhu. Apa bedanya dengan mean? Kapan max lebih bermakna? (Petunjuk: alarm.)
Buat TimeSeriesDB(max_points=10), tulis 15 titik, lalu cetak len(db.points) dan timestamp titik tertua. Berapa titik yang "terbuang"?
Sebuah sistem menyimpan 100 sensor × 1 titik/menit × 4 field. Estimasi jumlah titik per bulan. Berapa jika di-downsample ke 1 titik/jam setelah 7 hari?