Sürekli Sorguların Temelleri

InfluxDB'de Sürekli Sorgular (Continuous Queries - CQ), zaman serisi verileri üzerinde otomatik olarak ve düzenli aralıklarla çalıştırılan, agrega işlevleri içeren sorgulardır. Temel amacı, ham, yüksek çözünürlüklü veriyi, daha düşük çözünürlüklü ve özetlenmiş veri noktalarına dönüştürerek veri indirgeme ve performans iyileştirmesi sağlamaktır. Bu mekanizma, uzun vadeli trend analizlerinin hızlı bir şekilde yapılabilmesi için kritik bir rol oynar.

Bir Sürekli Sorgu, tanımlandığı andan itibaren geçmiş veriler üzerinde bir kez çalıştırılabilir ve ardından gelecekteki veriler için önceden belirlenmiş bir zaman aralığında (örneğin, her 1 saatte bir) otomatik olarak yürütülmeye devam eder. Bu özellik, kullanıcıyı veri toplama işlemlerini manuel olarak zamanlamak zorunda kalmaktan kurtarır. CQ'ların çıktısı, genellikle aynı veritabanı içinde otomatik olarak yeni bir measurement'a (ölçüm) yazılır. Bu yaklaşım, ham verinin saklama politikası (retention policy) gereği silinmesi durumunda bile, özetlenmiş değerlerin korunabilmesini mümkün kılar ve veri mimarisi için esneklik sunar.

Bileşen Açıklama Örnek
Kaynak Measurement Ham verinin okunduğu ölçüm. `cpu_usage`
Hedef Measurement Özet verinin yazıldığı yeni ölçüm. `cpu_usage_hourly`
Çalışma Aralığı CQ'nun tetiklenme sıklığı (GROUP BY time() değeri). `1h`
Agrega Fonksiyonu Veriyi özetlemek için kullanılan fonksiyon. `MEAN()`, `SUM()`

Sürekli Sorguların en temel kullanım senaryosu, saniye veya milisaniye bazında gelen sistem metriklerini, dakikalık, saatlik veya günlük ortalamalara dönüştürmektir. Bu işlem, dashboard sorgularının yanıt sürelerini önemli ölçüde düşürür ve depolama alanından tasarruf sağlar. Örneğin, bir sensörden saniyede bir gelen sıcaklık okumasını saklamak yerine, dakikalık ortalamaların saklanması, veri hacmini 60 kat azaltabilir. Bu, InfluxDB'nin zaman serisi veri yönetimindeki gücünü ve verimliliğini ortaya koyan temel bir araçtır.

Tasarım ve Performans

Sürekli Sorguların verimli çalışması, doğru tasarım kararlarına bağlıdır. Yanlış yapılandırılmış bir CQ, veritabanı sunucusunda aşırı yüke ve beklenmeyen kaynak tüketimine neden olabilir. Tasarım aşamasında dikkat edilmesi gereken ilk unsur, sorgunun çalışma aralığı ile veri noktalarının geliş sıklığı arasındaki ilişkidir. Eğer bir CQ, veri geliş aralığından daha sık çalıştırılırsa, birçok çalıştırma işlemi boş sonuç döndürebilir ve bu da gereksiz işlem yükü yaratır.

Performansı etkileyen bir diğer kritik faktör, CQ'nun kapsadığı zaman penceresinin boyutudur. Özellikle `RESAMPLE` ifadesi kullanılmadığında, sorgu varsayılan olarak yalnızca son çalıştırılma zamanından bu yana gelen verileri işler. Ancak, bir CQ oluşturulurken `GROUP BY time()` cümlesinde belirtilen süreden daha uzun bir `FOR` süresi tanımlanırsa veya `RESAMPLE` kullanılırsa, sorgnun işlemek zorunda olduğu veri miktarı artar. Bu durum, sorgu yürütme süresini uzatır ve sistem kaynakları üzerindeki baskıyı yükseltir. Bu nedenle, performans ve güncellik dengesi iyi kurulmalıdır.

Tasarım sürecinde, CQ'ların hedef measurement'ları üzerinde uygun Saklama Politikaları (Retention Policies - RP) tanımlamak da büyük önem taşır. Ham veri, kısa süreli bir RP ile saklanıp düzenli olarak silinirken, CQ ile oluşturulan özet veri, daha uzun süreli bir RP'ye yazılabilir. Bu strateji, depolama maliyetlerini kontrol altında tutarken, tarihsel trend analizi için gerekli olan uzun vadeli özet verilerin korunmasını sağlar. Ayrıca, çok sayıda CQ tanımlanmış bir sistemde, bu sorguların çalışma zamanlarının çakışmaması için dikkatli bir zamanlama yapmak, sistemin genel cevap verebilirliğini olumlu yönde etkileyecektir.

InfluxQL ve CQ Sözdizimi

Sürekli Sorguların tanımlanması, InfluxDB'nin sorgu dili olan InfluxQL kullanılarak yapılır. Temel sözdizimi, bir `SELECT` sorgusunu `CREATE CONTINUOUS QUERY` ifadesi ile sarmalamaktan oluşur. Sorgu, bir kaynak measurement'dan veri seçer, bir veya daha fazla agrega fonksiyonu uygular ve sonucu genellikle farklı bir hedef measurement'a yazar. Bu süreçte `GROUP BY time()` cümlesi, sorgunun hangi zaman aralıklarında çalışacağını ve veriyi nasıl gruplayacağını belirleyen olmazsa olmaz bir yapı taşıdır.

Basit bir Sürekli Sorgu örneği, CPU kullanım verisinin saatlik ortalamasını hesaplamak için kullanılabilir. Bu sorgu, her saat başında otomatik olarak tetiklenir, son bir saatlik penceredeki tüm `cpu_usage` değerlerinin ortalamasını alır ve bu özet değeri `cpu_usage_hourly` measurement'ına kaydeder. Sorgu çalıştırıldığında, ilgili zaman aralığı için hedef measurement'ta tek bir nokta oluşur. Bu mekanizma, verinin sürekli ve otomatik olarak indirgenmesini sağlar. InfluxQL, `MEAN()`, `SUM()`, `MAX()`, `MIN()`, `COUNT()` gibi standart agrega fonksiyonlarının yanı sıra, `FIRST()`, `LAST()`, `PERCENTILE()` gibi istatistiksel fonksiyonları da CQ'larda kullanım için destekler. 

CREATE CONTINUOUS QUERY "cq_cpu_hourly" ON "telegraf"
BEGIN
  SELECT MEAN("usage_idle") AS "mean_usage_idle"
  INTO "downsampled_telegraf"."autogen".cpu_usage_hourly
  FROM "cpu"
  GROUP BY time(1h), *
END

Daha gelişmiş senaryolar için `RESAMPLE` anahtar kelimesi kullanılır. Bu ifade, CQ'nun çalışma sıklığından (`EVERY`) ve işlediği verinin kapsadığı zaman penceresinden (`FOR`) bağımsız olarak kontrol sağlar. Örneğin, her 5 dakikada bir çalışan ancak son 1 saatlik veriyi işleyen bir sorgu tanımlanabilir. Bu, kayan pencereli ortalamalar gibi daha karmaşık hesaplamalar için esnklik sağlar. `GROUP BY` kısmına eklenen etiket anahtarları (yıldız `*` ile tüm etiketler veya belirli anahtarlar), özet verinin etiket bazında da ayrıştırılarak saklanmasını mümkün kılar ve bu da sorgulama esnekliğini büyük ölçüde artırır.

Sözdizimi Öğesi Zorunluluk Açıklama
CREATE CONTINUOUS QUERY Evet CQ tanımını başlatan anahtar ifade.
INTO Evet Sonuçların yazılacağını hedefi belirtir. Hedef, farklı bir retention policy bile içerebilir.
GROUP BY time() Evet Sorgunun çalışma aralığını ve veri gruplama periyodunu tanımlar.
RESAMPLE Hayır CQ'nun çalışma ve veri aralığını özelleştirmek için kullanılan gelişmiş bir seçenektir.
GROUP BY * Hayır Özet veriyi tüm etiketler bazında saklamak için kullanılır. Performans etkisi dikkate alınmalıdır.

Sözdizimi içinde en dikkat edilmesi gereken noktalardan biri, INTO yan tümcesinin doğru yapılandırılmasıdır. Bu ifade, hedef veritabanı, saklama politikası ve measurement adını içerir. Agrega fonksiyonlarının kullanımı sırasında, `AS` anahtar kelimesi ile alanlara anlamlı yeni isimler vermek, ileride yapılacak sorgulamaların okunabilirliğini artıracaktır. Tüm bu yapılar bir araya geldiğinde, InfluxQL, zaman serisi veri akışlarını otomatikleştirilmiş bir şekilde yönetmek için güçlü ve ifade edici bir araç seti sunar.

Yönetim ve En İyi Uygulamalar

Etkili bir Sürekli Sorgu yönetimi, bu sorguların yaşam döngüsünün izlenmesini, bakımını ve iyileştirilmesini kapsar. InfluxDB, tanımlı CQ'ları listelemek, silmek ve bazen değiştirmek (genellikle silip yeniden oluşturarak) için gerekli komutları sağlar. `SHOW CONTINUOUS QUERIES` komutu, her veritabanı için aktif olan sorguları ve tanımlarını göstrir, bu da sistem duruşunun anlaşılmasında ilk adımdır. CQ'ların düzgün çalışıp çalışmadığını doğrulamak için, hedef measurement'daki veri noktalarının beklenen zaman aralıklarında ve doğru değerlerle oluştuğunu periyodik olarak kontrol etmek gerekir.

En iyi uygulamaların başında, CQ'ların oluşturulma sırası gelir. Mevcut büyük miktarda ham veri üzerinde yeni bir CQ oluşturulduğunda, bu sorgu geçmişe yönelik tüm veriyi işlemeye çalışabilir ve bu da sunucuda uzun süreli ve yüksek kaynak tüketen bir işleme neden olabilir. Bu riski azaltmak için, CQ oluşturulurken `CREATE CONTINUOUS QUERY ... WITH RESAMPLE FOR ...` yapısı kullanılarak geriye dönük işlenecek zaman penceresi sınırlandırılmalı veya sorgu boş zamanlarda oluşturulmalıdır. Ayrıca, agrega fonksiyonlarının yalnızca gerekli alanlara uygulanması, gereksiz hesaplama yükünü önler.

Performans optimizasyonu açısından, `GROUP BY *` ifadesinin kullanımı dikkatle değerlendirilmelidir. Bu ifade, her bir benzersiz etiket kombinasyonu için ayrı bir zaman serisi oluşturur. Eğer kaynak veride çok sayıda benzersiz etiket kombinasyonu varsa, bu durum "seri patlamasına" (series cardinality explosion) yol açarak depolama alanı tüketimini ve sorgu gecikmelerini hızla artırabilir. Bunun yerine, yalnızca gruplamada gerçekten gerekli olan etiket anahtarlarını belirtmek çok daha verimli olacaktır. Bir diğer kritik uygulama, CQ'ların çıktısını yazdığı hedef measurement'lar için, ham veriden farklı ve genellikle daha uzun olan saklama politikaları ayarlamaktır. Bu sayede, detaylı veri belirli bir süre sonra silinirken, özetlenmiş veri uzun süre muhafaza edilebilir, böylece depolama maliyetleri ile veri erişim ihtiyaçları dengelenmiş olur.

Son olarak, CQ'ların çalışma zamanları ve sistem yükü izlenmelidir. Bir CQ'nun çalışmasının normalden uzun sürdüğü tespit edilirse, `RESAMPLE FOR` penceresinin çok geniş olup olmadığı veya işlenen veri miktarının beklenmedik şekilde artıp artmadığı incelenmelidir. Otomasyonun getirdiği rahatlık, arka planda sorunsuz çalışan bir altyapıya bağlıdır; bu nedenle düzenli denetim ve performans ayarlaması, uzun vadeli sistem sağlığı için hayati önem taşır. Bu süreçler, veri pipeline'ının güvenilirliğini ve verimliliğini garanti altına alır.

Veri Doğruluğu ve Kayıp Veri

Sürekli Sorgular kullanılırken, özellikle gerçek zamanlı sistemlerde, veri doğruluğu ve bütünlüğünün nasıl etkilendiği kritik bir konudur. Temel bir risk, CQ'nun çalıştığı zaman penceresi ile ham verinin InfluxDB'ye yazılma zamanı arasındaki senkronizasyon eksikliğinden kaynaklanır. Bir CQ belirli bir zaman aralığı için veriyi işlerken, o aralığa ait bazı veri noktaları ağ gecikmesi veya veri kaynağındaki sorunlar nedeniyle henüz veritabanına ulaşmamış olabilir. Bu durum, özet verinin eksik veya yanlış hesaplanmasına yol açabilir.

Bu problemi hafifletmek için `GROUP BY time()` cümlesine bir offset (kaydırma) eklemek yaygın bir stratejidir. Örneğin, her saatin başında son bir saatlik veriyi işlemek yerine, her saatin başında son bir saatten 10 dakika öncesine kadar olan veriyi işleyen bir CQ tanımlanabilir. Bu 10 dakikalık gecikme, genellikle gecikmeli gelen veri noktalarının (straggler data points) veritabanına yazılması için bir tampon süresi sağlar. Böylece, özet hesaplanırken daha eksiksiz bir veri seti kullanılmış olur ve veri kaybı olasılığı azalır. Ancak, bu yaklaşım özet verinin güncelliğinden bir miktar taviz verir, bu da tasarım ödünleşimini gösterir.

Kayıp veri riskini yönetmenin bir diğer yolu, CQ'ların performansını ve başarı durumlarını izlemektir. CQ'nun beklenen sıklıkta çalışıp çalışmadığını, hedef measurement'da düzenli aralıklarla veri noktası üretip üretmediğini kontrol eden izleme sorguları veya alarmlar oluşturulabilir. Ayrıca, veri kaynağından gelen akışın sürekliliği de göz önünde bulundurulmalıdır. Uzun süreli kesintiler yaşayan bir kaynaktan gelen veriyi işleyen bir CQ, bu kesinti penceresinde hedefe hiç veri yazmayacak veya mevcut veriyi tekrar işleyecektir. Bu tür senaryolara yönelik stratejilerin (örneğin, kesinti sonrası veriyi yeniden işlemek için manuel müdahale) önceden belirlenmesi, veri bütünlüğünü korumada önemli bir adımdır.

v2.x ve v3.x'teki Durum

InfluxDB'nin 2.x ve 3.x sürümleriyle birlikte, Sürekli Sorgular kavramı ve uygulaması önemli değişikliklere uğramıştır. InfluxDB 2.x'te, CQ'ların geleneksel rolü büyük ölçüde Görevler (Tasks) tarafından üstlenilmiştir. Görevler, Flux adı verilen daha güçlü ve esnek bir veri işleme betik dili kullanır. Flux, veri işlemeyi daha programatik ve modüler bir hale getirerek, CQ'lar ile yapılamayan karmaşık dönüşümler, birleştirmeler ve hesaplamalar için olanak sağlar. Bu geçiş, otomatik veri indirgeme ihtiyacının ortadan kalktığı anlamına gelmez, ancak bu işlevselliğin uygulanma şekli daha modern ve kapsamlı bir araç setiyle gerçekleşir.

InfluxDB 3.x (eski adıyla InfluxDB IOx) ise, temel alınan depolama motoru ve sorgu mimarisinde köklü bir değişiklik getirmektedir. Bu yeni nesil mimari, sütunsal depolama ve dağıtık işleme gibi özelliklerle, ham, yüksek çözünürlüklü veri üzerinde bile son derece hızlı sorgular çalıştırmayı hedefler. Bu bağlamda, performans kazanmak için veriyi önceden özetleme zorunluluğu geleneksel InfluxDB 1.x'e kıyasla önemli ölçüde azalmıştır. Ancak, depolama maliyetlerini yönetmek ve belirli dashboard'ları hızlandırmak amacıyla veri indirgeme ihtiyacı devam etmektedir. InfluxDB 3.x ekosisteminde bu ihtiyaç, zamanla gelişen ve Görevlere benzer veya tamamen yeni yüksek seviyeli materialized view kavramlarıyla karşılanması beklenmektedir. Sürekli Sorgular, bu nedenle, InfluxDB 1.x'in temel bir özelliği olarak kalırken, yeni sürümlerde daha geniş bir veri işleme ve otomasyon çerçevesinin bir parçası haline gelmiştir.