Türkçe
English
Saha mühendisi şöyle anlatıyor: "SCADA historian'ımız 4 yıl önce SQL Server'a 200 GB ile başladı. Bugün 4.5 TB. Aylık disk + lisans 1500 USD'yi geçti. 5 yıllık veri sorgusu 2-3 dakika sürüyor. Yöneticiye 10 yıllık trend istediklerinde 'sistem dondu' demek zorunda kalıyoruz."
Bu manzara her tesisin tarihsel veri büyüdükçe karşılaştığı sorundur. Çözüm bir yedek diski daha eklemek değil — time-series veritabanına geçiş.
Klasik SQL Server historian'ın sınırı
- Yapı: her örnek bir satır → satır overhead'i (8-16 byte) örnek verisinden (4-8 byte) daha büyük
- İndeksleme: tag_id + timestamp birleşik indeks devamlı büyür, RAM'i şişirir
- Disk: raw veri 1 byte/sample ihtiyacı varken SQL Server 20-40 byte/sample tutar
- Aggregat sorgusu: "son 5 yılda günlük ortalama" sorgusu milyarlarca satıra full scan yapar
- Lisans: Standard Edition ~3K USD/core, Enterprise ~14K USD/core
Time-Series DB neden farklı?
Time-series DB'ler zaman-damgalı veri için optimize edilmiştir:
- Sütun bazlı depolama: aynı tag'in örnekleri ardışık tutulur, sıkıştırma 5-15x
- Otomatik partition: zaman aralığına göre veri bölünür, eski partition'lar sorguya katılmaz
- Continuous aggregates: dakikalık, saatlik, günlük aggregat'lar arka planda hesaplanır, sorgu anında hazır
- Retention policy: 1 günlük veri 30 gün, dakikalık 6 ay, saatlik 5 yıl gibi katmanlı saklama
- Açık kaynak: TimescaleDB (PostgreSQL eklentisi) ve InfluxDB Community ücretsiz
TimescaleDB vs InfluxDB
| Özellik | TimescaleDB | InfluxDB |
|---|---|---|
| Temel | PostgreSQL eklentisi | Bağımsız DB |
| Sorgu dili | Standart SQL | Flux (özel) / InfluxQL |
| Ekosistem | Tüm PostgreSQL araçları çalışır | Kendi araçları (Telegraf, Kapacitor) |
| Sıkıştırma | ~10x | ~15x |
| Yatay ölçek | Distributed hypertables | InfluxDB Enterprise (ödenir) |
| İlişkisel veri | Var (PostgreSQL gücü) | Yok / sınırlı |
| Saha tercihimiz | Çoğunluk | Saf IoT senaryolarda |
Pratik öneri: SCADA + ERP entegrasyonu varsa TimescaleDB (PostgreSQL ile aynı veritabanında ilişkisel ve zaman serisi). Saf telemetri ise InfluxDB.
Saha rakamları — geçiş örneği
5000 tag, 1 sn örnekleme, 3 yıl retention:
| Metrik | SQL Server | TimescaleDB |
|---|---|---|
| Disk boyutu | 4.2 TB | 320 GB |
| "Son 1 yıl, günlük ort." sorgu | 2.5 dk | 0.8 sn |
| Yıllık lisans | ~8.000 USD (Standard) | 0 USD |
| Disk + backup yıllık | 3.500 USD | 800 USD |
| Yedekli setup | Lisans 2x | Streaming replication ücretsiz |
| 3 yıl TOPLAM | ~35.000 USD | ~2.500 USD |
Geçiş adımları
- Yeni DB'yi paralel kur. SCADA aynı veriyi her iki tarafa da yazsın (dual-write).
- Tarihsel veriyi taşı. Eski SQL'den batch script ile yeni DB'ye. CSV intermediary kullan, doğrudan link değil.
- Sorguları yeni DB'ye çevir. Önce raporlama dashboardları, sonra alarm geri-dönüş analizleri.
- 2-4 hafta paralel çalış. Karşılaştırmalı doğruluk kontrol et.
- Eski DB'yi okunabilir-only yap. Yazımları kes, sadece eski sorgular için tut.
- 3-6 ay sonra eski DB'yi tamamen kaldır. Lisans iptali.
Continuous aggregates — sihirli kısım
TimescaleDB'de bir kez tanımlanır, otomatik güncellenir:
CREATE MATERIALIZED VIEW telemetry_hourly
WITH (timescaledb.continuous) AS
SELECT
time_bucket('1 hour', ts) AS hour,
tag_id,
avg(value) AS avg_val,
max(value) AS max_val,
min(value) AS min_val
FROM telemetry
GROUP BY 1, 2;"Son 5 yıl saatlik ortalama" sorgusu milisaniyede döner çünkü pre-aggregated veri okur.
Retention politikası örneği
- Raw (1 sn): 30 gün
- 1 dk aggregat: 6 ay
- 5 dk aggregat: 2 yıl
- 1 saatlik aggregat: 10 yıl
Disk 1/30 oranında küçülür, "tarihsel" sorgular hâlâ mümkündür.
Mevcut historian'ınızın boyutu + günlük veri yazma hızını paylaşın — geçiş öncesi/sonrası benzeri bir karşılaştırma simülasyonu yapabiliriz.