Time-Series Veritabanı Nedir? InfluxDB ve TimescaleDB

Time-Series Veritabanı Nedir, Ne Zaman Gerekir?

Zaman serisi verisi, bir varlığın zaman içindeki durumunu art arda kaydeden ölçümlerdir: sensör sıcaklıkları, sunucu CPU kullanımı, uygulama metrikleri, finansal fiyat akışları. Bu verinin ortak özelliği; neredeyse tamamen ekleme (append) ağırlıklı olması, zaman damgasının birincil eksen olması ve sorguların çoğunlukla "son N dakika", "şu aralıkta ortalama" gibi zaman pencerelerine odaklanmasıdır.

Bu profildeki veriyi ilişkisel bir veritabanında tutmak mümkündür, ancak ölçek büyüdükçe indeks bakım maliyeti, saklama (retention) yönetimi ve aralık sorgularının performansı sorun olmaya başlar. Time-series veritabanları (TSDB) tam bu üç noktayı hedefler: yüksek yazma hacmi, zaman aralığı sorguları ve otomatik veri yaşlandırma.

İki yaygın yaklaşım vardır:

• InfluxDB: Baştan time-series için tasarlanmış, kendi sorgu dili ve saklama politikaları olan bağımsız bir veritabanı.
• TimescaleDB: PostgreSQL üzerine kurulu bir eklenti (extension). SQL kullanır, mevcut PostgreSQL bilgisi ve araçları geçerlidir.

Bu rehber orta seviye geliştiriciler için iki sistemin temel kullanımını, veri modelleme kararlarını ve sık yapılan hataları ele alır. Sürüm numarası vermekten kaçınıyorum; InfluxDB 2.x ile 3.x arasında ve Flux ile SQL arasında önemli farklar olduğu için kullandığınız sürümün kendi dokümantasyonunu doğrulama kaynağı olarak alın. Aşağıdaki örnekler kavramsaldır; çalıştırmadan önce kendi ortamınızda test edin.

Veri Modelleme: İki Sistemin Ortak Mantığı

Her iki sistemde de veri kabaca şu eksenlerde düşünülür:

• Measurement / hypertable: Veri grubunun adı (örneğin cpu, temperature).
• Tag / etiket sütunları: Düşük kardinaliteli, filtrelenen ve gruplanan boyutlar (host, region, servis adı).
• Field / değer sütunları: Asıl ölçülen sayısal (veya boolean/string) değerler.
• Timestamp: Kaydın zamanı.

Kritik kural: etiketler (tag) ile değerler (field) karıştırılmamalıdır. Etiketler indekslenir ve sorgularda filtre olarak kullanılır; değerler indekslenmez ve hesaplamaya girer. Yüksek kardinaliteli bir alanı (örneğin her istek için benzersiz bir request_id) etiket yapmak, indeks patlamasına ve yazma performansının çökmesine yol açar. Bu, iki sistemde de en sık yapılan modelleme hatasıdır.

InfluxDB ile Çalışma

InfluxDB'de yazma ve sorgulama, kullandığınız sürüme göre farklı API'lerle yapılır. 2.x hattında satır protokolü (line protocol) ile yazma ve Flux ile sorgulama yaygındır; 3.x hattında ise SQL ve InfluxQL öne çıkar. Bu yüzden aşağıdaki örnekler biçim gösterir, sürüm garantisi vermez.

Satır Protokolü Biçimi

InfluxDB'nin satır protokolü şu yapıdadır:

measurement,tag1=deger1,tag2=deger2 field1=deger1,field2=deger2 timestamp

Örnek:

cpu,host=server01,region=eu field=usage value=0.64 1700000000000000000

Burada cpu measurement, host ve region etiket, value alan (field), sondaki sayı ise nanosecond cinsinden zaman damgasıdır. Zaman damgasını atlarsanız sunucu kendi saatini kullanır; dağıtık sistemlerde bu, sıralama sorunlarına yol açabilir, bu yüzden istemci tarafında zamanı açıkça göndermek daha güvenlidir.

Flux ile Sorgulama (2.x hattı)

from(bucket: "metrics")
  |> range(start: -1h)
  |> filter(fn: (r) => r._measurement == "cpu" and r.host == "server01")
  |> aggregateWindow(every: 1m, fn: mean)

Bu sorgu son bir saatteki cpu verisini alır, server01 ile filtreler ve her bir dakikalık pencerede ortalama alır. aggregateWindow çağrısı, ham veriyi indirgeyerek döndürülen nokta sayısını azaltır; bu, hem ağ hem de görselleştirme tarafında önemlidir.

Saklama Politikaları ve Downsampling

Zaman serisi verisi hızla büyür. InfluxDB'de retention policy (2.x'te bucket ayarları) ile verinin ne kadar tutulacağını tanımlarsınız; süresi geçen veri otomatik silinir. Uzun vadeli analiz için tipik desen downsampling'dir: ham veriyi kısa süre tutup, periyodik görevlerle (task) dakikalık/saatlik ortalamaları ayrı bir bucket'a yazmak. Böylece hem depolama hem sorgu maliyeti düşer.

TimescaleDB ile Çalışma

TimescaleDB, PostgreSQL'in üzerine kurulu olduğu için standart SQL kullanır ve psql, ORM'ler, yedekleme araçları gibi mevcut PostgreSQL ekosistemiyle çalışır. Temel kavram hypertable'dır: sıradan bir tablo gibi görünen, ancak arka planda zaman aralıklarına (chunk) bölünen yapıdır.

Eklentiyi Etkinleştirme ve Hypertable Oluşturma

CREATE EXTENSION IF NOT EXISTS timescaledb;

CREATE TABLE metrics (
    time        TIMESTAMPTZ       NOT NULL,
    host        TEXT              NOT NULL,
    region      TEXT              NOT NULL,
    value       DOUBLE PRECISION  NOT NULL
);

SELECT create_hypertable('metrics', 'time');

create_hypertable çağrısı, tabloyu zaman ekseninde parçalara böler. Bu işlem, tablo boşken veya veri yüklenmeden önce yapılmalıdır; mevcut veri üzerinde yapılabilecek durumlar olsa da boş tabloda başlamak en temiz yaklaşımdır.

Sorgulama

SELECT
    time_bucket('1 minute', time) AS bucket,
    host,
    avg(value) AS avg_value
FROM metrics
WHERE time > now() - INTERVAL '1 hour'
  AND host = 'server01'
GROUP BY bucket, host
ORDER BY bucket;

time_bucket fonksiyonu, verilen aralığa göre zamanı gruplar. Bu, InfluxDB'deki aggregateWindow'un SQL karşılığıdır. WHERE koşulunda zaman filtresinin bulunması kritiktir; chunk'ların budanmasını (chunk pruning) sağlar ve yalnızca ilgili zaman aralığındaki veri okunur.

İndeksleme ve Sıkıştırma

Etiket olarak kullandığınız sütunlara indeks eklemek sorgu performansını belirgin şekilde etkiler:

CREATE INDEX ON metrics (host, time DESC);

TimescaleDB ayrıca yerel sıkıştırma (compression) sunar. Eski chunk'ları sıkıştırarak depolamayı ciddi oranda azaltabilirsiniz. Sıkıştırılmış veriye yazma kısıtlıdır; bu yüzden sıkıştırmayı yalnızca artık yazılmayan, geçmiş zaman aralıklarına uygulamak gerekir.

Sürekli Toplamlar (Continuous Aggregates)

Downsampling için TimescaleDB'de continuous aggregate kullanılır. Bu yapı, belirli bir sorgunun sonucunu materyalize eder ve yeni veri geldikçe günceller:

CREATE MATERIALIZED VIEW metrics_hourly
WITH (timescaledb.continuous) AS
SELECT
    time_bucket('1 hour', time) AS bucket,
    host,
    avg(value) AS avg_value
FROM metrics
GROUP BY bucket, host;

Bu görünüm, ham tabloyu her sorguda taramak yerine önceden hesaplanmış sonucu döndürür. Uzun zaman aralıklı panolar için bu yaklaşım kritik hale gelir.

Yaygın Hatalar

• Yüksek kardinaliteli etiketler: request_id, user_id, session_id gibi neredeyse benzersiz değerleri tag yapmak. Her ikisinde de indeks/dizin patlamasına yol açar. Bunlar ya field olmalı ya da hiç tutulmamalıdır.
• Zaman filtresi olmadan sorgu: Time-series sorgularında zaman aralığı neredeyse her zaman zorunludur. TimescaleDB'de bu, chunk pruning'i devre dışı bırakır; InfluxDB'de sınırsız tarama ve bellek sorunlarına yol açar.
• Çok fazla nokta döndürmek: Ham veriyi olduğu gibi panoya göndermek. Downsampling veya aggregateWindow/time_bucket ile indirgemek gerekir.
• Zaman damgasını istemci yerine sunucuya bırakmak: Özellikle çok düğümlü yazma senaryolarında sıralama ve gecikme sorunları yaratır.
• Retention/downsampling'i sonradan eklemek: Veri büyüdükten sonra politika tanımlamak, geçmiş veriyi temizlemeyi ve dönüştürmeyi zorlaştırır. Baştan planlanmalıdır.

Güvenlik Notları

• Kimlik doğrulama ve yetkilendirme: InfluxDB'de token'lar, TimescaleDB'de PostgreSQL rolleri kullanılır. Yazma ve okuma token'larını/rollerini ayırın; bir metrik toplayıcının yalnızca yazma yetkisi olması yeterlidir.
• Şifreleme: Hem istemci-veritabanı arası trafikte TLS, hem de disk üzerinde şifreleme değerlendirilmelidir. TimescaleDB tarafında bu, PostgreSQL'in TLS ve disk şifreleme mekanizmalarına bağlıdır.
• Ağ erişimi: TSDB'ler genellikle iç ağda çalışır. Doğrudan internete açmak yerine bir toplayıcı/gateway arkasında tutun. InfluxDB'nin HTTP API'si geniş yüzey alanına sahiptir; erişimi kısıtlayın.
• Etiketlerde hassas veri: Etiketlere kullanıcı adı, e-posta, IP gibi kişisel veri koymak, hem kardinalite hem de gizlilik açısından risklidir. Bu verileri ayrı tutun.

Seçim İçin Pratik Kriterler

• Mevcut PostgreSQL altyapınız varsa ve SQL bilgisi ağır basıyorsa: TimescaleDB daha az sürtünmeyle entegre olur. İlişkisel tablolarla birleştirme (JOIN) ihtiyacı varsa bu belirleyici olabilir.
• Yüksek yazma hacmi, kendi sorgu dili ve yerleşik retention/task mekanizması istiyorsanız: InfluxDB baştan bu iş için tasarlanmıştır.
• Karma ihtiyaçlar: İkisini birlikte kullanmak da yaygındır; örneğin kısa vadeli yüksek çözünürlüklü veri bir sistemde, uzun vadeli analitik diğerinde.

Karar verirken sürüm farklarını (özellikle InfluxDB'nin 2.x ve 3.x hatları arasındaki API ve sorgu dili değişimlerini) mutlaka kendi ortamınızda doğrulayın. Bu rehberdeki örnekler kavramsal biçim gösterir; üretime almadan önce kullandığınız sürümün resmi dokümantasyonuyla eşleştirin.