Üretim Verisi için Historian Seçimi: Zaman Serisi Veritabanları

Historian projelerinde ilk ay sorun çıkmaz. Disk dolmaya başladığında, ham veri silinip özet tablolar boş geldiğinde ya da kesinti sonrası bir saatlik veri yanlış zamana yazıldığında seçimin bedeli ödenir. Historian, sensör, sayaç ve durum verisini zaman damgasıyla saklayıp geriye dönük sorgulatan sistemdir; bu işi bugün hem ticari endüstriyel historian’lar hem de InfluxDB, TimescaleDB gibi zaman serisi veritabanları (TSDB) yapıyor. Aşağıda iki yaklaşımı sıkıştırma, saklama, sorgu, yedekleme ve OT entegrasyonu açısından, sahada karşılaştığımız hatalar üzerinden karşılaştırıyoruz.

Historian ile genel amaçlı veritabanı arasındaki fark

Üretim verisi yapı olarak basittir: tag kimliği, zaman damgası, değer ve çoğu zaman bir kalite bilgisi. Zorluk hacimde ve erişim desenindedir. Veri neredeyse yalnız eklenir, güncellenmez. Sorguların hemen hepsi “şu tag’in şu aralıktaki değerleri” biçimindedir. Yeni veri, eski veriden çok daha sık okunur.

İlişkisel bir veritabanı bu yükü taşır. Ama şu işleri ekip elle çözmek zorunda kalır:

• Zamana göre bölümleme (partitioning) ve eski bölümlerin tek komutla silinmesi,
• Sütun bazlı sıkıştırma ve sıkıştırılmış veriye sorgu,
• Zaman aralığı başına ortalama, minimum, maksimum, son değer gibi toplu değerlerin hızlı üretilmesi,
• Eşit aralıklı olmayan veriden enterpolasyonla eşit aralıklı seri çıkarılması,
• Bağlantı koptuğunda sonradan gelen geç verinin doğru yere yazılması.

Endüstriyel historian’lar bunları ürünün içinde, OT protokol sürücüleri ve tag yönetimiyle birlikte getirir. TSDB’ler depolama ve sorgu tarafında güçlüdür; veri toplama, tag meta verisi ve operatör araçları için ek bileşen ister. Bu ek bileşenleri kimin işleteceği sorusu, çoğu zaman lisans fiyatından daha belirleyicidir.

Sıkıştırma, deadband ve örnekleme stratejileri

Seçim toplantılarında en çok karışan kavram “sıkıştırma”dır. Aynı kelime iki farklı şeyi anlatır.

Değer bazlı (kayıplı) sıkıştırma

Birçok ticari historian saklanan nokta sayısını azaltan kayıplı algoritmalar kullanır. İlk kademe istisna (exception) deadband’idir: yeni değer son gönderilenden belirli bir miktar farklı değilse iletilmez. İkinci kademe genellikle swinging door türü bir eğim algoritmasıdır: art arda gelen noktalar tanımlı tolerans içinde bir doğru üzerinde kalıyorsa ara noktalar atılır, yalnız eğimin değiştiği noktalar yazılır. Okunduğunda doğrusal enterpolasyonla aslına çok yakın görünen, ama çok daha az nokta içeren bir seri elde edilir.

Tolerans doğruysa yöntem iyi çalışır. Yanlışsa kısa tepeleri siler. Sahada en sık gördüğümüz hata, tüm tag’lere aynı yüzdesel toleransın toplu atanmasıdır; motor akımındaki kısa sıçrama, arıza analizi günü trendde yoktur. Toleransı enstrümanın ölçüm belirsizliğine yakın tutun, kalite açısından kritik tag’lerde daha sıkı ayarlayın.

Depolama bazlı (kayıpsız) sıkıştırma

TSDB’ler genellikle her noktayı saklar ve kayıpsız sıkıştırır: zaman damgalarında delta kodlama, kayan noktalı değerlerde XOR tabanlı kodlama, tekrarlayan değerlerde run-length kodlama. Sabit veya yavaş değişen sinyallerde oran yüksek, gürültülü analoglarda düşüktür. Kayıpsız sıkıştırma veriyi değiştirmez. Gürültü de saklanır. Bu yüzden kaynakta veya toplayıcıda küçük bir deadband yine işe yarar.

Örnekleme

Periyodik okuma (her saniye, her 5 saniye) ile değişimde gönderme (report by exception) arasındaki seçim, saklanacak nokta sayısını doğrudan belirler. Sayaç ve durum sinyallerinde değişimde gönderme, sıcaklık gibi yavaş analoglarda deadband’li değişimde gönderme kullanın. Titreşim gibi hızlı sinyalleri historian’a zorlamayın; ayrı bir yüksek frekans toplama sistemi çoğu zaman daha doğru sonuç verir.

Ticari historian ve açık kaynak TSDB karşılaştırması

Ölçüt	Ticari endüstriyel historian	Açık kaynak TSDB
OT bağlantısı	Protokol sürücüleri ve tag tarayıcı ürünle gelir	Ayrı toplayıcı katman gerekir
Sıkıştırma	Kayıplı + kayıpsız, tag bazında ayar	Çoğunlukla kayıpsız, ham nokta saklanır
Sorgu	Üreticiye özel API, SQL katmanı ürüne göre değişir	SQL (TimescaleDB) veya kendi sorgu dili/SQL (InfluxDB sürümüne göre)
Tag meta verisi	Birim, açıklama, alarm limitleri yerleşik	Şemayı ekip tasarlar
Lisans	Çoğunlukla tag sayısına veya sunucuya göre	Ücretsiz çekirdek, kurumsal özellikler sürüme göre
Beceri ihtiyacı	Ürün yönetimi	Veritabanı işletimi ve şema tasarımı

Karar tabloya bakarak değil, şu sorulara verilen dürüst cevaplarla çıkar: Tesiste bu sistemi gece arıza geldiğinde ayağa kaldıracak veritabanı yetkinliği var mı? Operatör ve süreç mühendisleri hazır trend aracına mı ihtiyaç duyuyor? Veriyi kurumsal BI araçlarıyla SQL üzerinden paylaşmak öncelikli mi? Tag sayısı iki katına çıktığında lisans nasıl değişiyor?

Toplama katmanının protokol seçimi bu kararla doğrudan bağlantılıdır; iki protokolün davranış farkları için OPC UA mı MQTT mi yazısına bakın.

Saklama politikası ve aşağı örnekleme

Ham veriyi sonsuza kadar tutmak nadiren gerekir ve disk bütçesini en hızlı tüketen alışkanlıktır. Sürdürülebilir model katmanlı saklamadır: ham veri kısa süre, dakikalık özet tablolar orta süre, saatlik veya vardiyalık özet tablolar uzun süre tutulur. Özet tabloda yalnız ortalama tutmayın. Minimum, maksimum ve örnek sayısı da yazılmalı; yoksa tepe değerler ve veri boşlukları üst katmanda görünmez olur.

TimescaleDB’de bu model hypertable, sıkıştırma politikası, sürekli toplama (continuous aggregate) ve saklama politikasıyla kurulur:

CREATE TABLE tag_data (
  time     timestamptz      NOT NULL,
  tag_id   integer          NOT NULL,
  value    double precision,
  quality  smallint
);
SELECT create_hypertable('tag_data', 'time',
       chunk_time_interval => INTERVAL '1 day');

ALTER TABLE tag_data SET (
  timescaledb.compress,
  timescaledb.compress_segmentby = 'tag_id',
  timescaledb.compress_orderby   = 'time DESC'
);
SELECT add_compression_policy('tag_data', INTERVAL '7 days');

CREATE MATERIALIZED VIEW tag_1m
WITH (timescaledb.continuous) AS
SELECT time_bucket('1 minute', time) AS bucket, tag_id,
       avg(value) AS avg_v, min(value) AS min_v,
       max(value) AS max_v, count(*) AS n
FROM tag_data
GROUP BY bucket, tag_id;

SELECT add_continuous_aggregate_policy('tag_1m',
       start_offset => INTERVAL '1 day',
       end_offset   => INTERVAL '1 minute',
       schedule_interval => INTERVAL '1 minute');

SELECT add_retention_policy('tag_data', INTERVAL '90 days');

Buradaki tuzak şudur: ham veri saklama süresi, özetin yenileme penceresinden (start_offset) uzun olmalıdır. Aksi halde sistem, silinmiş ham veri üzerinden özeti yeniden hesaplamaya çalışır. Parametrelerin güncel davranışını TimescaleDB dokümantasyonundan kendi sürümünüze göre doğrulayın. InfluxDB’de aynı katmanlama, farklı saklama süreli bucket’lar ve periyodik aşağı örnekleme görevleriyle yapılır; ayrıntılar sürümden sürüme değiştiği için InfluxData dokümantasyonu esas alınmalıdır.

Örnek depolama boyutu hesabı

Aşağıdaki hesap bir örnek hesaptır; gerçek değer sıkıştırma oranına ve sinyal davranışına göre değişir.

• Tag sayısı: 5.000
• Ortalama kayıt sıklığı: tag başına saniyede 1 nokta (en kötü durum, deadband yok)
• Nokta başına ham boyut: 8 bayt zaman + 4 bayt tag kimliği + 8 bayt değer + 2 bayt kalite ≈ 22 bayt; satır ve indeks ek yüküyle yaklaşık 40 bayt varsayalım

Günlük nokta sayısı 5.000 × 86.400 = 432 milyon; sıkıştırma öncesi 432 milyon × 40 bayt ≈ 17 GB/gün eder. 90 günlük ham saklama sıkıştırmasız 1,5 TB civarına çıkar. Kayıpsız sıkıştırma veriyi örneğin 10 kat küçültürse 90 gün için yaklaşık 155 GB yeter. Deadband ile ortalama kayıt sıklığı tag başına 10 saniyede bire inerse rakam yine 10’a bölünür.

Hesabın sahadaki karşılığı net: depolama boyutunu disk değil, tag başına gerçek kayıt sıklığı belirler. Sunucu siparişinden önce mevcut sistemden birkaç günlük örnek veri alın, hedef platforma yükleyin ve sıkıştırma oranını ölçün. Varsayımla boyutlandırılan historian ya fazla pahalıya kurulur ya da altıncı ayda disk alarmı verir.

Yedekleme, yüksek erişilebilirlik ve DMZ replikasyonu

Historian çoğu tesiste üretimi durdurmaz; ama kaybettiği veriyi geri getiremezsiniz. İki ayrı soru sorun: Historian sunucusu kapalıyken veri kaybolur mu? Disk veya veritabanı bozulursa geçmiş geri gelir mi?

İlk sorunun cevabı toplayıcı katmandadır. Edge gateway veya toplayıcı ajan, historian’a ulaşamadığında veriyi yerelde tamponlamalı (store and forward) ve bağlantı dönünce kaynak zaman damgasını koruyarak geriye dönük yazmalıdır. Tamponun kaç saat dayandığını kâğıt üstünde değil, ağ kablosunu çekerek test edin. İkinci soru için düzenli veritabanı yedeği ve geri dönüş testi gerekir. PostgreSQL tabanlı çözümlerde sürekli WAL arşivleme ile zaman noktasına geri dönüş yapılabilir; ticari historian’larda üreticinin arşiv dosyası yedekleme yöntemi izlenir. Geri yüklenmemiş yedek, yedek değildir.

Kurumsal kullanıcıların OT ağındaki historian’a doğrudan bağlanmasına izin vermeyin. Yerleşik yapı, OT tarafındaki birincil historian’ın verisini DMZ’deki bir replikaya göndermesi ve raporlama araçlarının yalnız replikaya erişmesidir. Ağ tarafındaki yerleşim OT DMZ tasarımı yazısında anlatılıyor. Replikasyon yönü OT’den DMZ’ye olmalı. Replika kesildiğinde birincil historian’ın çalışmaya devam ettiğini devreye almada mutlaka deneyin.

Seçim kriterleri tablosu

Gereksinim	Ağırlık verilecek yön
Hazır OT sürücüleri ve operatör trendi	Ticari historian
Kurumsal BI ile SQL üzerinden paylaşım	SQL tabanlı TSDB veya SQL katmanı olan historian
Çok sayıda tag, sınırlı lisans bütçesi	Açık kaynak TSDB + toplayıcı katman
Veritabanı işletim yetkinliği yok	Ticari historian veya yönetilen hizmet
Validasyon ve denetim izi gereksinimi	Denetim izi ve elektronik kayıt özelliği belgelenmiş ürün
Hızlı sinyaller (kHz düzeyi)	Historian dışı, ayrı yüksek frekans sistemi

Seçimden sonra en sık karşılaştığımız hata, platformu tag isimlendirme ve meta veri standardı olmadan devreye almaktır. Bir yıl sonra aynı sensör üç farklı adla, iki farklı birimle durur. Hangi platform seçilirse seçilsin tag adları ve birimler baştan belirlenmeli, veri kalitesi ve zaman damgası kuralları yazılı olmalıdır; bu konu üretim verisinde zaman damgası ve veri kalitesi yazısında ayrıntılı işleniyor. Toplama altyapısının tamamı için IIoT ve üretim verisi toplama hizmetimize, historian üzerine kurulacak ekranlar için üretim izleme ve dashboard sayfamıza bakabilirsiniz.

Sık sorulan sorular

Küçük bir tesiste historian yerine doğrudan SQL Server kullanılabilir mi?

Birkaç yüz tag ve dakikalık örnekleme gibi düşük hacimlerde, doğru indekslenmiş ve bölümlenmiş bir ilişkisel tablo iş görür. Sorun hacim büyüyünce başlar: sıkıştırma, eski verinin parça parça silinmesi ve zaman aralığı sorguları elle çözülmesi gereken işlere dönüşür. Büyüme bekleniyorsa baştan zaman serisi yeteneği olan bir platform seçmek daha az iş çıkarır.

Deadband ayarı historian’da mı yapılmalı, gateway’de mi?

İkisi farklı işe yarar. Gateway veya OPC UA aboneliğindeki deadband ağ ve sunucu yükünü düşürür; historian tarafındaki sıkıştırma saklama alanını düşürür. Kaynakta küçük bir gürültü deadband’i kullanın, asıl sıkıştırmayı historian’a bırakın. İki tarafta da büyük deadband kullanmak hatayı katlar.

Ham veriyi ne kadar süre saklamak gerekir?

Tek doğru süre yok; karar, ham veriye kimin ve neden döneceğine göre verilir. Arıza analizi için genellikle haftalar ile birkaç ay yeter, uzun dönem trend ve raporlama dakikalık veya saatlik özet tablolardan yapılır. Müşteri, izlenebilirlik veya mevzuat gereği daha uzun saklama gerekiyorsa bu gereklilik yazılı alınmalı ve saklama politikası ona göre kurulmalıdır.

Açık kaynak bir TSDB seçersek OPC UA bağlantısını ne sağlar?

Zaman serisi veritabanları genellikle OPC UA istemcisi içermez. Araya bir toplayıcı katman girer: edge gateway, Telegraf gibi bir ajan, Node-RED akışı veya MQTT broker üzerinden veri yazan bir servis. Bu katmanın tamponlama, yeniden bağlanma ve kalite bilgisini taşıma yeteneği, veritabanı seçimi kadar belirleyicidir.