Ana içeriğe geç

ADR-002: Zaman Serisi Veritabani Olarak TimescaleDB Secimi

DurumKabul Edildi
Tarih2025-12
Karar VerenGüçlü Ceyhan

Baglam​

Zeus 2.0, gunes enerjisi santrallerindeki cihazlardan surekli telemetri verisi toplar:

  • Veri frekansi: 5 saniye aralikla olcum
  • Cihaz sayisi: Yuzlerce inverter, enerji analizoru, meteoroloji istasyonu
  • Veri hacmi: Gunluk milyonlarca satir
  • Sorgulama ihtiyaci: Son 24 saat, haftalik/aylik grafikler, karsilastirma raporlari
  • Saklama suresi: 2 yil (730 gun) aktif veri, sonrasinda arsiv
  • Mevcut altyapi: PostgreSQL 15 zaten kullanilmakta

Karar​

TimescaleDB (PostgreSQL extension) zaman serisi verileri icin secildi. Mevcut PostgreSQL 15 uzerine extension olarak yuklendi.

Alternatifler​

InfluxDB​

  • Artilari: Zaman serisi icin ozel tasarim, Flux sorgu dili, yuksek yazma performansi
  • Eksileri: Ayri veritabani yonetimi, Flux ogrenme egrisi, SQLAlchemy/Alembic ile entegre edilemez, JOIN islemleri yok
  • Red nedeni: Mevcut PostgreSQL altyapisiyla entegre olmaz, ek operasyonel yuk

MongoDB Time-Series​

  • Artilari: Esnek sema, yatay olcekleme, time-series collection destegi (5.0+)
  • Eksileri: SQL destegi yok, mevcut ORM/migration altyapisi kullanilamaz, ACID garantileri sinirli
  • Red nedeni: Iliskisel veritabani ile JOIN ihtiyaci (cihaz-olcum-tenant iliskisi)

Apache Cassandra​

  • Artilari: Cok yuksek yazma performansi, yatay olcekleme, yuksek erisebilirlik
  • Eksileri: Operasyonel karmasiklik, CQL sinirlamalari, kucuk-orta olcek icin asiri muhendislik
  • Red nedeni: Zeus 2.0 olceginde gereksiz karmasiklik

Pure PostgreSQL (partition ile)​

  • Artilari: Ek bagimliligi yok, bilinen teknoloji
  • Eksileri: Manuel partition yonetimi, compression yok, continuous aggregate yok, retention policy manuel
  • Red nedeni: TimescaleDB'nin sagladigi otomasyon ve performans avantajlarindan vazgecmek mantikli degil

Gerekce​

TimescaleDB su temel avantajlari sundu:

  1. PostgreSQL uzerine extension: Mevcut ORM (SQLAlchemy 2.0), migration (Alembic) ve driver (asyncpg) altyapisi aynen korunur
  2. Otomatik partitioning (hypertable): Zaman bazli partitioning otomatik yonetilir — manuel partition olusturma/silme gerekmez
  3. Compression: 90 gun sonra veri otomatik sikistirilir — depolama maliyeti %90'a kadar duser
  4. Retention policy: 730 gun sonra eski veri otomatik silinir
  5. SQL ile sorgulanabilir: Standart SQL + time_bucket(), first(), last() gibi zaman serisi fonksiyonlari
  6. Continuous aggregate: Saatlik/gunluk ozet tablolar otomatik guncellenir — dashboard sorgulari hizlanir
  7. JOIN destegi: measurements tablosu ile devices, tenants tablolari arasinda standart SQL JOIN yapilabilir

Sonuclar​

Olumlu​

  • Tek veritabani yonetimi — PostgreSQL + TimescaleDB ayni instance'ta
  • SQLAlchemy modelleri ve Alembic migration'lari aynen calisiyor
  • time_bucket() ile grafik sorgulari cok basit ve hizli
  • Compression sayesinde disk kullanimi dramatik azaldi
  • Continuous aggregate ile dashboard yuku dusuruldu

Olumsuz​

  • Hypertable'lar Alembic op.create_table() ile olusturulamaz — op.execute() ile raw SQL kullanmak gerekir. Bu, migration yazarken ozel dikkat gerektirir: 
    # Yanlis — calismaz
    op.create_table('measurements', ...)

    # Dogru
    op.execute("SELECT create_hypertable('measurements', 'time')")
  • TimescaleDB surum yukseltmeleri PostgreSQL yukseltmesiyle koordine edilmelidir
  • Bazi PostgreSQL ozelliklerinde kisitlamalar vardir (ornegin UNIQUE constraint'ler partition key icermelidir)
  • Hypertable uzerinde ALTER TABLE islemleri standart tablolara gore daha dikkatli yapilmalidir