# Zaman serisi verisi için TimescaleDB mi, InfluxDB mu?

> Günde 100M satır düz bir tabloda patlar: hypertable ile zamana göre parçalayın, ortalamaları continuous aggregate'e alın, eski chunk'ları sıkıştırın.

- Soruldu: 2026-06-08
- Yanıtlandı: 2026-06-11
- Soran: Uğur
- Etiketler: veritabani, postgresql, olcekleme
- Kaynak: https://muhammetsafak.com/tr/sor-bakalim/zaman-serisi-verisi-timescaledb-mi-influxdb-mu/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** IoT cihazlarından her 10 saniyede bir sıcaklık ve nem verisi alıyoruz; günlük akış 100M satıra ulaşıyor. Bu zaman serisi verisini standart bir MySQL tablosunda tutmaya çalışınca indeks boyutları RAM'i aşıyor ve geçmişe dönük ortalama (aggregation) sorguları çalışmaz hale geliyor.

Bu senaryoda TimescaleDB (hypertable) veya InfluxDB gibi çözümler mimari olarak bize ne sağlar?


Kısa cevap: Günde 100M satır düz bir MySQL tablosunda patlar — çünkü B-tree indeks ve tam tablo agregasyonu RAM'e sığmaz. Zaman serisi motorları bunu **yapısal** olarak çözer. SQL'de düşünüyor ve agregasyon istiyorsanız doğru araç TimescaleDB.

## Kısa cevap

Sorunun kökü model değil ölçek: zaman serisinde veri sürekli büyür; indeks şişer; "son 30 günün ortalaması" gibi sorgular tüm tabloyu tarar. Standart bir tablo bunu kaldırmaz. TimescaleDB'nin chunk'ları özünde zamana göre partitioning; aynı işi eklenti olmadan, düz declarative partitioning ile nasıl kuracağınızı [PostgreSQL partitioning kaydında](/tr/sor-bakalim/postgresql-tablo-partitioning-sifir-kesinti-ile-gecis/) anlatmıştım.

## Neden

1. **Hypertable veriyi zaman bazlı chunk'lara böler.** Insert'ler ve zaman aralığı sorguları yalnızca ilgili chunk'lara dokunur; tüm tabloyu tarama derdi biter. İndeks de chunk başına olduğu için RAM'i ezmez.
2. **SQL ekosistemini bırakmıyorsunuz.** TimescaleDB bir Postgres eklentisi olduğu için hâlâ saf SQL, `JOIN` ve mevcut Postgres ekosistemindesiniz — yeni bir dil/araç öğrenmenize gerek yok.
3. **InfluxDB amaca özel ama ayrı bir dünya.** InfluxDB zaman serisi için sıfırdan tasarlanmış, ama işletmeniz ve öğrenmeniz gereken ayrı bir sistem. InfluxDB 3 Core SQL ve `JOIN` destekliyor, yine de mevcut Postgres ekosisteminiz değil. Sizin gibi zaten SQL'de düşünen ve agregasyon isteyen biri için sürtünme yaratır.

## Ne yapmalı

1. **Tabloyu hypertable'a çevirin.** TimescaleDB'yi kurup zaman serisi tablosunu hypertable olarak tanımlayın; parçalama işini motora bırakın.
2. **Ortalamaları continuous aggregate'e alın.** Sürekli toplulaştırma (continuous aggregate), saatlik/günlük ortalamaları arka planda önceden hesaplar (materialize). "Geçmişe dönük ortalama" sorgunuz ham milyonlarca satırı değil, hazır özeti okur — anında döner.
3. **Eski chunk'ları sıkıştırın.** TimescaleDB eski chunk'ları native compression ile sıkıştırır; disk ve I/O dramatik düşer.
4. **Influx'a ancak ayrı bir metrik stack istiyorsanız yönelin.** Adanmış bir TSDB kurmak gibi net bir gerekçe yoksa, ikinci bir sistem yükünü üstlenmeyin.

**Sonuç:** TimescaleDB hypertable + continuous aggregate + sıkıştırma — sizin senaryonuzda en düşük sürtünmeli kazanç. Influx'u yalnızca ayrı bir TSDB istiyorsanız düşünün. İki durumda da eski ham veriyi downsample edip retention ile düşün; süresiz ham tutmak hiçbir motoru kurtarmaz. "PostgreSQL her şeye yeter mi?" sorusunun zaman serisindeki cevabı: eklentisiyle çoğunlukla evet.

## İlgili Yazılar

- [PostgreSQL Her Şeye Yeter mi?](https://sade.dev/tr/journal/postgresql-her-seye-yeter-mi) — sade.dev
- [PostgreSQL tablo partitioning'e sıfır kesinti ile nasıl geçerim?](https://muhammetsafak.com/tr/sor-bakalim/postgresql-tablo-partitioning-sifir-kesinti-ile-gecis/) — Sor Bakalım
- [Heap erişimini önlemek ve index-only scan almak için covering index'e (INCLUDE) ne zaman geçmeliyim?](https://muhammetsafak.com/tr/sor-bakalim/index-only-scan-covering-indexe-ne-zaman-gecmeliyim/) — Sor Bakalım
- [Sadece 'pending' satırları taranan bir kuyruk tablosunda partial index kullanmalı mıyım?](https://muhammetsafak.com/tr/sor-bakalim/sadece-pending-satirlari-taranan-bir-kuyruk-tablosunda-partial-index-kullanmali-miyim/) — Sor Bakalım