SCADA İçin Zaman Serisi Veritabanı: PostgreSQL + TimescaleDB Neden Güçlü Bir Kombinasyon?

SCADA projelerinde saniyede binlerce, hatta yüz binlerce veri noktası akar.
Sıcaklık, basınç, motor akımı, sayaç değerleri… Hepsi zaman damgası ile birlikte sürekli üretilir.

Bu kadar yoğun zaman serisi verisini doğru bir veritabanı mimarisiyle toplamazsanız, sistem önce yavaşlar, sonra bakım ve raporlama ciddi bir operasyonel yük haline gelir.

Bu yazı, PostgreSQL kullanan SCADA projelerinde TimescaleDB eklentisinin neden doğru bir tercih olduğunu netleştirmek için hazırlandı.
Teknik detaylara gireceğiz, ancak dili sade tutacağız. Amaç; hem OT hem IT ekiplerinin aynı masada bu metni okuyup “bizim mimari için doğru çözüm bu” diyebilmesini sağlamak.

SCADA Sistemlerinde Zaman Serisi Veritabanı Neden Ayrı Bir Konudur?

SCADA tarafında tutulan verinin büyük bölümü yapısal olarak basittir:

Zaman damgası
Ölçüm değeri
Tag adı (veya cihaz/sinyal kimliği)

Ancak hacim olağanüstü büyüktür.

Örnek sinyaller:

Sıcaklık sensörleri
Basınç transmitterleri
Enerji analizörleri (akım, gerilim, güç)
Üretim hattı hızları, sayaçlar

Binlerce tag’in her saniye kayıt ürettiğini düşünelim.
Çok kısa sürede milyonlarca satır oluşur.

Klasik PostgreSQL ile Nereye Kadar?

Birçok SCADA sistemi hâlâ saf PostgreSQL veya benzeri ilişkisel veritabanları kullanır. Bu mümkündür, hatta belirli bir hacme kadar sorunsuz çalışır. Ancak veri büyüdükçe tipik problemler ortaya çıkar:

Sürekli insert yükü nedeniyle disk I/O artar
Zaman damgası indeksleri hızla büyür
Uzun tarih aralıklı sorgular yavaşlar
Eski verinin arşivlenmesi manuel ve riskli hale gelir

Sorun PostgreSQL’in zayıf olması değil; zaman serisi deseninin farklı olmasıdır.

SCADA verisi:

Çok hızlı yazılır
Sık sık okunur (trend, grafik, alarm)
Neredeyse hiç güncellenmez
Yıllarca saklanmak istenir

Bu desen için ek bir optimizasyon katmanı gerekir. İşte TimescaleDB tam bu noktada devreye girer.

TimescaleDB Nedir? PostgreSQL’e Ne Katar?

TimescaleDB, PostgreSQL üzerinde çalışan bir zaman serisi eklentisidir (extension).
Yani yeni bir veritabanı öğrenmezsiniz; PostgreSQL’inizi zaman serisi için güçlendirirsiniz.

Temel fark şudur:

PostgreSQL → Genel amaçlı ilişkisel veritabanı
TimescaleDB → PostgreSQL’i zaman serisi için optimize eder

SCADA açısından bu çok kritiktir çünkü:

Mevcut PostgreSQL altyapısı aynen korunur
SQL bilgisi birebir geçerlidir
Zaman serisi veriler, ilişkisel verilerle aynı veritabanında yaşar

Hypertable Mantığı: SCADA Verisi Nasıl Ölçeklenir?

TimescaleDB’nin kalbi hypertable yapısıdır.

Bir hypertable:

Mantıksal olarak tek bir tablo gibi görünür
Fiziksel olarak zaman bazlı parçalara (chunk) ayrılır

Bu ne kazandırır?

Yıllarca veri birikse bile tablo “şişmez”
Sorgular yalnızca ilgili zaman aralığındaki chunk’ları okur
Eski veriler sıkıştırılabilir, yeniler hızlı kalır

SCADA senaryosunda bu şu anlama gelir:

Son 1 saatlik trend çok hızlı
Son 1 yıllık rapor tutarlı hızda
5–10 yıllık arşiv yönetilebilir

SCADA İçin Kritik Gereksinimler ve TimescaleDB Karşılığı

SCADA tarafında tipik gereksinimleri ve TimescaleDB’nin bunlara verdiği karşılığı netleştirelim:

Yüksek yazma hızı
→ Zaman serisi için optimize edilmiş insert yolları, chunk yapısı

Hızlı trend ve grafik sorguları
→ Zaman bazlı indeksleme, chunk pruning

Uzun dönem veri saklama (yıllar)
→ Otomatik sıkıştırma, eski veriyi daha az yer kaplayacak şekilde tutma

Alarm, KPI ve enerji analizleri
→ Tam SQL desteği, window function’lar, join’ler

Yüksek erişilebilirlik ve yedekleme
→ PostgreSQL ekosisteminin olgun HA, replication ve backup araçları

Yazma Performansı: SCADA Yükünü Kaldırır mı?

Tipik bir SCADA senaryosu düşünelim:

20.000 – 50.000 tag
Çoğu 1 saniye örnekleme
Bazıları 100 ms

TimescaleDB, doğru yapılandırıldığında bu yükü rahatlıkla taşır:

Doğru chunk süresi (ör. günlük veya saatlik)
Toplu insert (batch) kullanımı
Uygun indeksleme

Pratikte:

Saniyede on binlerce insert stabil şekilde mümkündür
SCADA projelerinin büyük çoğunluğu için fazlasıyla yeterlidir

Burada önemli nokta: ham performanstan çok sürdürülebilirliktir.
TimescaleDB, performansı yıllar boyunca tutarlı şekilde korur.

Sorgu Performansı: Trend mi, Rapor mu, Analiz mi?

SCADA sorgularını üç ana grupta düşünebiliriz:

Operatör trendleri (son dakika / saat)
Mühendislik raporları (günlük / aylık)
Uzun dönem analizler (yıl bazlı)

TimescaleDB bu üçü için de güçlüdür:

time_bucket() ile zaman bazlı gruplama
Join’ler ile cihaz, bakım, üretim tabloları entegrasyonu
Window function’lar ile gelişmiş analizler

Örneğin:

“Son 2 yılda bakım yapılan makinelerin enerji tüketimi”
“Vardiya bazlı üretim verimliliği”
“Arıza öncesi sensör davranış analizi”

Bunların hepsi tek SQL sorgusu ile yapılabilir.

Uzun Dönem Veri Saklama ve Regülasyon Avantajı

Enerji, su, doğal gaz, gıda, ilaç gibi sektörlerde:

Veri 3–5 yıl, hatta daha uzun süre saklanmak zorundadır
Denetimlerde geçmiş veriler istenir

TimescaleDB bu noktada ciddi avantaj sağlar:

Eski veriyi otomatik sıkıştırma
Sıcak ve soğuk veriyi aynı tabloda yönetme
Yedekleme ve geri yükleme süreçlerinin kurumsal standartlara uygun olması

Bu, SCADA projelerinde yasal ve operasyonel riskleri azaltır.

SQL Avantajı: Ekip Yetkinliği ve Geliştirme Hızı

TimescaleDB’nin en büyük gücü şudur:
Yeni bir dil öğrenmezsiniz.

SQL bilen herkes üretken olabilir
BI araçları (Power BI, Grafana, Tableau vb.) doğrudan bağlanır
IT ekipleri PostgreSQL yönetimini zaten bilir

Bu da şu anlama gelir:

Daha az eğitim maliyeti
Daha hızlı geliştirme
Daha az operasyonel sürpriz

SCADA İçin Ne Zaman PostgreSQL + TimescaleDB Doğru Seçimdir?

Aşağıdaki senaryolarda TimescaleDB çok güçlü bir tercihtir:

Uzun dönem (3–10 yıl) veri saklama ihtiyacı varsa
SCADA verisi ile bakım, arıza, üretim gibi ilişkisel veriler birlikte analiz edilecekse
SQL bilen geniş bir IT ekibi varsa
Denetim, raporlama ve izlenebilirlik kritikse
Mevcut PostgreSQL altyapısı zaten kullanılıyorsa