Zaman serisi veritabanı (time series database, TSDB), sensör, sayaç ve makinelerden gelen zaman damgalı ölçümleri yüksek hızda yazmak, sıkıştırarak saklamak ve zaman aralığına göre hızlı sorgulamak için tasarlanmış veritabanıdır. Nesnelerin İnterneti (IoT) sahasında ilişkisel veritabanını zorlayan üç işi, yani sürekli yazmayı, otomatik saklama politikasını ve zaman bazlı özetlemeyi yerleşik olarak yapar.
Kısaca
- Zaman serisi veritabanı veriyi zamana göre bölümler, sütun bazında sıkıştırır ve eski veriyi tek işlemle siler ya da özetler.
- Birkaç düzine sensör ve dakikalık okuma için ilişkisel tablo yeterlidir; binlerce seri ve saniye altı okumada amaca özel çözüm gerekir.
- Dört yaygın seçenek vardır: düz ilişkisel tablo, zaman serisi eklentili ilişkisel veritabanı, amaca özel zaman serisi veritabanı ve endüstriyel historian.
- Siemens'in 2024 raporuna göre büyük bir tesis ayda ortalama 27 saati plansız duruşa kaptırıyor; arıza analizi silinmemiş sensör geçmişine dayanır.
- Saklama politikası kullanım sorularından türetilir: ham veri kısa süre, dakikalık özetler daha uzun, saatlik özetler yıllarca tutulur.
Sensör verisi neden sıradan tabloya sığmıyor?
Tipik hikâye şöyle başlar: bir tesiste 40 makineye sıcaklık, titreşim ve akım sensörü takılır, her biri saniyede bir değer gönderir. İlk haftalarda veri, ERP'nin (Kurumsal Kaynak Planlaması) ya da mevcut uygulamanın kullandığı ilişkisel veritabanında bir "olcumler" tablosuna yazılır ve her şey yolunda görünür. Birkaç ay sonra tablo yüz milyonlarca satıra ulaşır, "geçen ayın saatlik ortalaması" sorgusu dakikalar sürer ve disk beklenenden hızlı dolar.
Yavaşlamanın nedeni ilişkisel veritabanının kötü olması değildir; iş yükünün türü farklıdır. Sipariş ya da fatura kaydı nadiren yazılır, sık güncellenir ve tek tek okunur. Sensör verisi ise tam tersidir: sürekli eklenir, neredeyse hiç güncellenmez ve hep zaman aralığı olarak, çoğunlukla özetlenerek okunur.
Sensör verisinin hacmi büyüdükçe iki kötü seçenek kalır. Ya ham veri belli aralıklarla silinir ve arıza sonrası geçmişe bakılamaz, ya da veri tutulur ama kimse sorgulamaya sabredemez. Zaman serisi veritabanı bu ikilemi, veriyi zaman eksenine göre bölümleyip sıkıştırarak ve eskidikçe özetleyerek çözer. Sensör verisi, büyük verinin hacim ve hız boyutlarının tipik bir örneğidir; kavramı büyük veri nedir yazımızda anlattık.
Sensör geçmişini kaybetmenin maliyeti nedir?
Sahadan ölçülen veri miktarı hızla artıyor. IoT Analytics'in State of IoT 2025 raporuna göre bağlı IoT cihazı sayısının 2025'te %14 artarak 21,1 milyara ulaşacağı, 2030'da ise 39 milyara çıkacağı öngörülüyor. Her cihaz, saklanması ve sorgulanması gereken bir zaman serisi demek.
Verinin asıl değeri bir şey ters gittiğinde ortaya çıkar:
Siemens'in kestirimci bakım şirketi Senseye ile hazırladığı hesaba göre dünyanın en büyük 500 şirketi plansız duruşlar yüzünden yılda yaklaşık 1,4 trilyon dolar, yani gelirlerinin %11'ini kaybediyor. (Siemens/Senseye, The True Cost of Downtime 2024)
Siemens'in aynı raporuna göre büyük bir üretim tesisi hâlâ ayda ortalama 27 saati plansız duruşa kaptırıyor. Arızanın kök nedenini üretim verisiyle bulmak ya da kestirimci bakım modelini eğitmek için arıza öncesindeki günlerin sensör verisine ihtiyaç vardır; disk dolduğu için silinmiş ya da sorgulanamayan geçmiş, bu analizi baştan imkânsız kılar.
Veriye güven de ayrı bir kalemdir. Drexel Üniversitesi LeBow İşletme Fakültesi ile veri bütünlüğü yazılımı satan Precisely'nin 2025 Outlook: Data Integrity Trends and Insights araştırmasında (2024) ankete katılanların %67'si kurumunun kullandığı veriye tam güvenmediğini söylüyor. Sensör verisinde bu güvensizliğin tipik nedenleri boşluklar, çift kayıtlar ve saat kaymasıdır; doğru tasarlanmış bir zaman serisi deposu bunları görünür kılar.
Zaman serisi veritabanı nasıl çalışır?
Zaman serisi veritabanı, her ölçümü dört parçalı bir kayıt olarak tutar: zaman damgası, ölçüm adı (ör. sıcaklık), ölçülen değer ve etiketler (tesis, hat, makine, sensör kimliği). Etiketler sorguların filtrelendiği boyutlardır; değerler ise sayısal ölçümlerdir. Etiket ve değer ayrımı doğru yapılmazsa, örneğin her okumaya benzersiz bir kimlik etiket olarak verilirse, kardinalite (benzersiz etiket kombinasyonu sayısı) patlar ve performans düşer.
Zaman serisi motoru, veriyi zaman aralıklarına (gün, hafta gibi parçalara) böler ve her parçayı sütun bazında sıkıştırır. Ardışık sensör değerleri birbirine çok benzediği için sıkıştırma oranı ilişkisel satır depolamaya göre belirgin biçimde yüksektir. Eski parçalar tek komutla silinebilir ya da ucuz depolamaya taşınabilir; satır satır silme gerekmez.
Zaman serisi veritabanının üçüncü yeteneği zamana özgü sorgulardır. "Her 5 dakikanın ortalaması", "boşlukları son değerle doldur", "son değeri getir" ve "iki seri arasındaki farkı hesapla" gibi işlemler yerleşik fonksiyonlarla yapılır. Sürekli özetler (continuous aggregates) sayesinde saatlik ve günlük ortalamalar veri geldikçe hesaplanır; panel her açıldığında milyonlarca satır taranmaz.
Zaman serisi veritabanı seçenekleri nelerdir? Sensör verisi için karşılaştırma
"Zaman serisi veritabanı" tek bir ürün sınıfı değildir. İşletmenin ölçeğine, mevcut ekibine ve verinin nereye akacağına göre dört yaygın seçenek vardır:
| Seçenek | Ne zaman uygun? | Güçlü yanı | Dikkat edilecek nokta |
|---|---|---|---|
| İlişkisel veritabanı (düz tablo) | Birkaç düzine sensör, dakikalık okuma, kısa geçmiş | Ek altyapı gerekmez, ekip tanır | Hacim büyüdükçe sorgu ve disk sorunu |
| İlişkisel veritabanı + zaman serisi eklentisi | Sensör verisini iş verisiyle aynı SQL ortamında birleştirmek | SQL, birleştirme (join), tanıdık yedekleme araçları | Şema ve bölümleme tasarımı baştan yapılmalı |
| Amaca özel zaman serisi veritabanı | Binlerce seri, saniye altı okuma, yoğun yazma | Yüksek yazma hızı, yerleşik saklama ve özetleme | Farklı sorgu dili, iş verisiyle birleştirmek ek entegrasyon ister |
| Endüstriyel historian | SCADA/PLC ağırlıklı tesis, operatör odaklı trend | Saha protokolleriyle hazır bağlantı | Dış sistemlere veri açmak ve lisans modeli sınırlayıcı olabilir |
Zaman serisi deposu seçimi veri gölü ile veri ambarı kararından ayrıdır, ama onunla bağlantılıdır. Ham yüksek frekanslı veri zaman serisi deposunda kalır; saatlik ve vardiyalık özetler ise üretim, kalite ve maliyet verisiyle birleşmek üzere veri ambarına aktarılır.
Zaman serisi veritabanı nasıl kurulur? 7 adım
- Kullanım sorularını yazın. "Arıza öncesi 72 saatlik titreşim trendi", "vardiya bazlı enerji tüketimi", "soğuk odada eşik aşımı" gibi somut sorular, hangi çözünürlükte ne kadar geçmiş tutulacağını belirler.
- Sensör ve sinyal envanteri çıkarın. Her sinyalin birimi, okuma sıklığı, kaynağı (PLC, sayaç, kablosuz sensör) ve sahibi listelenir. Eski makinelerde sinyalin nereden alınacağı eski makineleri dijitalleştirme çalışmasının parçasıdır; PLC (Programlanabilir Mantıksal Denetleyici) ve SCADA verisini standart bir modelle okumak için OPC UA sık kullanılan seçenektir.
- Veri modelini tasarlayın. Etiket ve değer ayrımı, adlandırma standardı ve kardinalite sınırı yazılı hâle getirilir; sonradan değiştirmek en pahalı karardır.
- Toplama katmanını kurun. Saha cihazları veriyi genellikle MQTT gibi bir mesajlaşma katmanına yayınlar. MQTT'nin QoS 1 (Quality of Service, "en az bir kez" teslim) düzeyi kayıp riskini azaltır ama çift kayıt üretebilir; yazma tarafı bunu tolere edecek şekilde tasarlanır. Bağlantı seçimi için LoRa, NB-IoT ve GSM karşılaştırması yol gösterir.
- Saklama ve özetleme politikası belirleyin. Örneğin ham veri kısa süre, dakikalık özetler daha uzun, saatlik özetler yıllarca tutulur. Politika kullanım sorularından türetilir; "her şeyi sonsuza kadar sakla" politika değildir.
- Kalite kurallarını ekleyin. Geç gelen ve sırası bozuk veri, cihaz saat kayması, fiziksel olarak imkânsız değerler ve boşluklar yakalanıp işaretlenir. Genel ilkeler için veri kalitesi ve mükerrer kayıt yazısına bakabilirsiniz.
- Tüketicileri bağlayın. Uzaktan izleme paneli, alarm kuralları, BI raporları ve yapay zeka modelleri aynı depodan beslenir; erişim yetkisi ve üretim ağıyla ayrım, OT (operasyonel teknoloji) güvenliği ilkelerine göre netleştirilir.
Türkiye'deki mevzuat da sensör verisinin saklama politikasını etkileyebilir (Ekim 2026 itibarıyla). 5627 sayılı Enerji Verimliliği Kanunu'na göre endüstriyel işletmeler ve enerji yöneticisi çalıştırmakla yükümlü bina yönetimleri, istenen enerji tüketim bilgilerini her yıl Mart sonuna kadar Genel Müdürlüğe bildirmek zorundadır. Kanun belirli bir saklama süresi öngörmese de bu bildirimi sağlam veriye dayandırmak için sayaç özetlerini en az bir tam raporlama dönemini kapsayacak şekilde tutmak mantıklıdır; kapsamınızı hukuk ya da enerji yöneticinizle teyit edin.
Zaman serisi veritabanı projelerinde sık yapılan hatalar
Zaman serisi projelerindeki ilk hata, ölçeği bugünkü sensör sayısına göre seçmektir. Pilot 20 sensörle başlar, bir yıl içinde üç tesise ve binlerce sinyale yayılır; bölümleme ve saklama kararı bu büyümeyi hesaba katmalıdır. İkinci hata, cihaz saatine körü körüne güvenmektir; zaman damgasının cihazda mı, ağ geçidinde mi yoksa sunucuda mı atandığı yazılı olmalıdır. Veri sahada ön işlemden geçiyorsa bu kural uç bilişim katmanı için de geçerlidir.
Üçüncü hata, zaman serisi deposunu raporlama veritabanı gibi kullanmaktır. Yönetim paneli için gereken şey çoğunlukla saniyelik ham veri değil, doğru tanımlanmış göstergedir; bu ayrım BI dashboard ve KPI tasarımı rehberinde ayrıntılı anlatılıyor. Son olarak, sensör verisinin hangi gecikmeyle görünmesi gerektiği gerçek zamanlı raporlama ihtiyacına göre belirlenmeli; her panelin saniyelik olması gerekmez.
Digital Bridge sensör verisi altyapısını nasıl kuruyor?
Digital Bridge olarak sensör verisi projelerine bir ihtiyaç analiziyle başlıyoruz: hangi kararlar sensör verisine dayanacak, hangi sinyaller var, ne kadar geçmiş gerekiyor ve veri kimde duracak. Bu keşifte mevcut PLC, SCADA ve sayaç altyapısını yerinde inceliyor; katalog cihazın yetmediği noktalarda IoT cihaz tasarımı ve imalatı seçeneğini değerlendiriyoruz.
Ardından bir hat, bir istasyon ya da bir enerji noktasıyla pilot kuruyoruz. Pilotta veri modeli, saklama politikası ve kalite kuralları gerçek veriyle sınanır; sorgu süresi ve disk büyümesi ölçülür. Uzak sahalar söz konusuysa veri uzaktan izleme platformumuza akar ve alarm, harita, trend ekranları aynı depodan beslenir.
Projenin son aşaması entegrasyondur. Saatlik ve vardiyalık özetleri veri ambarı ve ETL (Çıkar, Dönüştür, Yükle) süreçleriyle ERP ve üretim verisinin yanına taşıyor, BI dashboard üzerinden yönetime sunuyoruz. Aynı geçmiş, kestirimci bakım modellerinin ve enerji izleme ve yönetimi raporlarının da girdisi olur. Sensör verisi altyapısının maliyet tarafını merak ediyorsanız veri ambarı maliyet kalemleri yazısı kalemleri ayrıntılı açıklıyor.
Sonraki adım
Sensör verinizin bugün nerede tutulduğunu, ne kadar geriye gidebildiğinizi ve hangi sorulara yanıt veremediğinizi birlikte değerlendirelim. Sinyal envanterinizle ya da yalnızca bir makine listesiyle bizimle iletişime geçin; pilot kapsamını ve uygun depolama seçeneğini yazılı olarak paylaşalım. Diğer veri rehberleri için Veri ve Analitik konu sayfasına göz atabilirsiniz.