Veritabanı & Zaman Serisi Veri Yönetimi 38 okunma

TimescaleDB ile Zaman Serisi Verileri

IoT, metrik ve finans verileri için zaman serisi veritabanlarının avantajları, TimescaleDB'nin PostgreSQL üzerinde nasıl çalıştığı ve sorgu optimizasyonları ele alınır.

TimescaleDB ile Zaman Serisi Verileri

TimescaleDB / Time-Series Databases: Zaman Serisi Verilerini Ölçekleme

IoT sensörleri, uygulama metrikleri, finansal piyasa verileri veya log akışları... Günümüzde üretilen verilerin büyük bir kısmı zaman serisi (time-series) formatındadır. Bu veriler, yüksek hacimli (saniyede milyonlarca veri noktası), sürekli akan ve zaman damgasına göre indekslenen yapıdadır. Geleneksel ilişkisel veritabanları (RDBMS) bu tür yükleri kaldırmakta zorlanırken, özel zaman serisi veritabanları devreye girer.

TimescaleDB, bu ihtiyaca yönelik olarak PostgreSQL üzerine inşa edilmiş, açık kaynaklı bir zaman serisi veritabanıdır. Bir "extension" (eklenti) olarak çalıştığı için, PostgreSQL'in tüm gücünü (SQL, ACID, olgun ekosistem) korurken, zaman serisi verileri için özel olarak tasarlanmış performans ve ölçeklenebilirlik özelliklerini sunar.

1. Zaman Serisi Veritabanları Neden Özel Bir Yaklaşım Gerektirir?

Zaman serisi verilerinin kendine özgü zorlukları vardır:

  • Yüksek Yazma Hacmi (High Ingestion Rate): Saniyede milyonlarca satır eklenebilir.

  • Veri Ekleme Ağırlıklı (Append-Only): Veriler genellikle güncellenmez veya silinmez, sadece eklenir.

  • Zaman Bazlı Sorgular: Veriler neredeyse her zaman belirli bir zaman aralığına göre filtrelenir (WHERE time > now() - interval '1 day').

  • Özetleme ve Downsampling (Veri Seyreltme): Eski veriler, depolama maliyetini düşürmek için özetlenir (örneğin, saniyelik verilerden saatlik ortalamalara geçiş).

TimescaleDB, bu zorlukları aşmak için PostgreSQL'i otomatik bölümlendirme (partitioning), sıkıştırma (compression) ve önceden hesaplanmış özetler (continuous aggregates) ile güçlendirir.

2. TimescaleDB'nin Üç Temel Gücü

TimescaleDB, PostgreSQL'i zaman serisi iş yükleri için optimize eden üç ana özellik sunar:

A. Hypertables (Süper Tablolar) - Otomatik Bölümlendirme

Zaman serisi verilerini yönetmenin en temel zorluğu, tek bir devasa tablonun performansını korumaktır. TimescaleDB, verileri zaman ve isteğe bağlı olarak başka bir anahtar (ör. device_id) üzerinden otomatik olarak daha küçük "chunk" (parça) tablolarına böler.

  • Nasıl Çalışır? Siz normal bir PostgreSQL tablosu oluşturur ve onu bir hypertable olarak tanımlarsınız. TimescaleDB, verileri otomatik olarak zaman aralıklarına (ör. günlük veya haftalık) göre chunk'lara ayırır.

  • Avantajları:

    • Performans: Yeni veriler (sıcak chunk) bellekte tutulurken, eski veriler (soğuk chunk) diskte saklanır.

    • Bakım Kolaylığı: Eski chunk'ları sıkıştırmak, silmek veya arşivlemek çok kolaydır.

    • Ölçeklenebilirlik: Veri hacmi arttıkça, yeni chunk'lar otomatik olarak eklenir.

sql

-- Bir hypertable oluşturma (Zaman serisi verileri için)
CREATE TABLE sensor_data (
    time TIMESTAMPTZ NOT NULL,
    device_id INTEGER NOT NULL,
    temperature FLOAT,
    humidity FLOAT
);

-- Tabloyu hypertable'a dönüştür (time sütunu baz alınarak)
SELECT create_hypertable('sensor_data', 'time');

B. Compression (Sıkıştırma) - Depolama Maliyetini Düşürme

Zaman serisi verileri, yüksek oranda tekrar eden değerler içerir (örneğin, aynı device_id binlerce kez tekrar eder). TimescaleDB, eski chunk'ları satır tabanlı (row-oriented) depolamadan sütun tabanlı (columnar) depolamaya dönüştürerek sıkıştırır.

  • Kazanç: Depolama alanında %80 ila %95 arasında bir tasarruf sağlanabilir. Ayrıca, sıkıştırılmış veriler üzerinde yapılan sorgular da genellikle daha hızlıdır.

  • Politika (Policy): Sıkıştırma, belirli bir süreden eski chunk'lar için otomatik olarak uygulanacak şekilde yapılandırılabilir.

C. Continuous Aggregates (Sürekli Özetler) - Hızlı Özet Sorguları

Zaman serisi verilerinde en sık yapılan sorgulardan biri, verileri belirli bir zaman aralığında özetlemektir (ör. "son 24 saatteki ortalama sıcaklık"). Bu tür sorgular, ham veriler üzerinde her seferinde hesaplanırsa çok yavaş olur.

  • Nasıl Çalışır? TimescaleDB, belirli bir zaman aralığı (ör. 1 saat) için önceden hesaplanmış özetleri (min, max, avg, sum) otomatik olarak günceller ve saklar.

  • Avantajı: Yeni veriler geldikçe, bu özetler artımlı olarak (incrementally) güncellenir. Bu sayede, milyarlarca satır üzerinde bile özet sorguları milisaniyeler içinde sonuç döndürür.

sql

-- Saatlik ortalama sıcaklık için bir continuous aggregate oluşturma
CREATE MATERIALIZED VIEW sensor_data_hourly
WITH (timescaledb.continuous)
AS
SELECT
    device_id,
    time_bucket(INTERVAL '1 hour', time) AS bucket,
    AVG(temperature) AS avg_temp,
    MAX(temperature) AS max_temp
FROM sensor_data
GROUP BY device_id, bucket;

3. Sorgu Optimizasyonu (İndeksleme Stratejileri)

Zaman serisi verilerinde doğru indeksleme, performans için hayati önem taşır.

  • Zaman Sütununu İndeksleyin: TimescaleDB, time sütununda otomatik olarak bir indeks oluşturur. Ancak, manuel olarak da indeks ekleyebilirsiniz.

  • Bileşik (Composite) İndeksler: Sorgularınız sıklıkla time ve başka bir sütunla (ör. device_id) filtreleniyorsa, bu iki sütunu birlikte indeksleyin.

    sql

    CREATE INDEX idx_sensor_data_device_time ON sensor_data (device_id, time DESC);

  • JSONB Alanları için GIN İndeksi: Eğer verilerinizde esnek JSONB alanları varsa ve bu alanlar üzerinden sorgulama yapıyorsanız, GIN indeksi oluşturun.

  • Aşırı İndekslemeden Kaçının: Her indeks, yazma (INSERT) performansını yavaşlatır. Sadece ihtiyaç duyulan indeksleri oluşturun.

"Active Chunk" Kuralı: TimescaleDB, aktif chunk'ın (en son verilerin bulunduğu parça) mevcut belleğin yaklaşık %25'ine sığmasını önerir. Bu, en hızlı sorgu performansını sağlar.

4. Zaman Serisi Veritabanları ile Karşılaştırma (InfluxDB, QuestDB)

Zaman serisi veritabanları arasında en sık karşılaştırılanlar InfluxDB, QuestDB ve TimescaleDB'dir.

  • TimescaleDB: Büyük ölçekli veriler ve karmaşık sorgular (JOIN, alt sorgular) gerektiren senaryolarda en iyi performansı gösterir. Standart SQL kullanır, bu da öğrenme eğrisini düşürür.

  • InfluxDB: Basit sorgularda iyidir ancak veri hacmi arttıkça performans düşüşü yaşar. Kendine özgü bir sorgu dili (InfluxQL/Flux) vardır.

  • QuestDB: Orta ölçekli verilerde istikrarlı performans sunar.

Sonuç: Eğer PostgreSQL ekosistemine zaten aşinaysanız, SQL kullanmak istiyorsanız ve karmaşık sorgulara ihtiyacınız varsa, TimescaleDB güçlü bir tercihtir.

5. .NET / EF Core ile TimescaleDB Kullanımı

TimescaleDB, PostgreSQL üzerine inşa edildiği için standart Npgsql sürücüsü ile çalışır. Ancak, TimescaleDB'nin özel özelliklerini (hypertable, continuous aggregates) EF Core ile kullanmak için ek paketler mevcuttur.

Kurulum ve Yapılandırma:

  1. NuGet paketini ekleyin:

    text

    dotnet add package CmdScale.EntityFrameworkCore.TimescaleDB

  2. DbContext yapılandırmasında .UseTimescaleDb() metodunu zincirleyin:

    csharp

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder
        .UseNpgsql("Host=localhost;Database=my_timeseries_db;Username=postgres;Password=...")
        .UseTimescaleDb(); // TimescaleDB desteğini etkinleştir!
}

Model Tanımlama ve Migration:

TimescaleDB'nin hypertable ve continuous aggregate gibi özelliklerini EF Core Migration ile yönetmek için, migration dosyalarına manuel SQL eklemeniz gerekebilir.

csharp

// Migration'ın Up() metodunda:
protected override void Up(MigrationBuilder migrationBuilder)
{
    // Tabloyu hypertable'a dönüştür
    migrationBuilder.Sql("SELECT create_hypertable('\"SensorData\"', 'Time');");

    // Continuous aggregate oluştur
    migrationBuilder.Sql(@"
        CREATE MATERIALIZED VIEW sensor_data_hourly
        WITH (timescaledb.continuous) AS
        SELECT
            device_id,
            time_bucket(INTERVAL '1 hour', time) AS bucket,
            AVG(temperature) AS avg_temp
        FROM sensor_data
        GROUP BY device_id, bucket;
    ");
}

6. Ne Zaman TimescaleDB Kullanmalı?

Uygun Olduğu Senaryolar Uygun Olmadığı Senaryolar
IoT Veri Toplama: Sensörlerden gelen yüksek hacimli veri akışları. Karmaşık İlişkisel Veri: Çok sayıda tablo arasında JOIN yapılan geleneksel OLTP iş yükleri.
Uygulama Metrikleri: APM, performans monitörü, log toplama. Veri Ambarı / OLAP: Çok boyutlu analiz ve raporlama için özel veri ambarı çözümleri (ör. ClickHouse) daha uygun olabilir.
Finansal Zaman Serileri: Hisse senedi fiyatları, işlem hacimleri, anlık kur verileri. Düşük Hacimli, Basit Veri: Sadece birkaç bin satırı olan ve karmaşık sorgu gerektirmeyen projeler için standart PostgreSQL yeterlidir.
DevOps / SRE: Altyapı izleme, container metrikleri (Prometheus alternatifi).  

Sonuç:

TimescaleDB, zaman serisi verileri için PostgreSQL'in gücünü ve esnekliğini koruyarak, ölçeklenebilir ve performanslı bir çözüm sunar. Hypertables ile otomatik bölümlendirme, compression ile depolama maliyetlerinde %90'a varan tasarruf ve continuous aggregates ile anlık özet sorguları, onu bu alanda güçlü bir rakip haline getirir. Özellikle .NET ekosisteminde, EF Core ile entegrasyonu sayesinde, PostgreSQL bilen bir geliştiricinin TimescaleDB'ye geçişi oldukça kolaydır.

Eğer elinizde büyüyen bir zaman serisi veri kümesi varsa ve SQL'in rahatlığından vazgeçmek istemiyorsanız, TimescaleDB kesinlikle değerlendirmeniz gereken bir seçenektir.

Tüm yazılar