Zaman Serisi Veritabanı (Time-Series Database) Rehberi [2026]

Zaman Serisi Verisi Neden Farklıdır?

Her saniye milyonlarca sensör okuması, uygulama metriği, finansal işlem ve enerji tüketim verisi üretiliyor. Bu verilerin ortak noktası, her birinin bir zaman damgasına bağlı olması ve kronolojik düzende anlam kazanmasıdır. Geleneksel ilişkisel veritabanları bu tür verileri depolayabilse de, zaman serisi verisinin kendine özgü erişim kalıpları ve ölçek gereksinimleri karşısında ciddi performans sorunlarıyla karşılaşır. Standart bir B-tree indeksi, sürekli artan zaman damgalı veriler için optimize değildir ve milyarlarca satıra ulaştığında sorgu performansı dramatik şekilde düşer.

Zaman serisi veritabanları (TSDB), zaman damgalı verilerin yüksek hızda yazılması, verimli sıkıştırılması ve hızlı sorgulanması için özel olarak tasarlanmış sistemlerdir. IoT platformlarından uygulama izleme altyapılarına, finansal analitikten enerji yönetimine kadar geniş bir kullanım yelpazesine sahiptir. Bu rehberde TSDB mimarisinden lider araçların karşılaştırmasına, veri modelleme stratejilerinden ölçeklendirme yaklaşımlarına kadar kapsamlı bir bakış sunuyoruz.

Zaman Serisi Verisinin Karakteristik Özellikleri

Append-Heavy Yazım Profili

Zaman serisi verisi neredeyse tamamen ekleme (append) odaklıdır. Mevcut veri noktaları nadiren güncellenir veya silinir; yeni veriler sürekli olarak akışa eklenir. Bu özellik, yazma optimizasyonunu TSDB tasarımının merkezine yerleştirir. Write-ahead log (WAL) yapıları ve batch insert mekanizmaları, yüksek yazma throughput'u sağlamak için kullanılır. Bir IoT platformunda binlerce sensörden saniyede yüz binlerce veri noktası gelebilir; bu yazma hacmi geleneksel veritabanlarını kolayca tıkayabilir.

Zaman Sıralı Erişim

Sorgular genellikle belirli bir zaman aralığına odaklanır: "son 24 saatteki CPU kullanımı", "geçen haftaki sıcaklık ortalaması", "bu ayki enerji tüketim trendi" gibi. Zaman bazlı indeksleme ve partitioning, bu erişim kalıbını optimize eder. Eski veriler otomatik olarak daha düşük çözünürlüğe indirgenerek (downsampling) depolama maliyetleri kontrol altında tutulur. Veri yaşlandıkça detay ihtiyacı azalır; saniye bazındaki ham veri yerini saatlik veya günlük ortalamaya bırakır.

Aggregation-Heavy Sorgular

Ham veri noktaları yerine ortalama, minimum, maksimum, yüzdelik dilim, standart sapma ve hareketli ortalama gibi istatistiksel fonksiyonlar sıklıkla sorgulanır. TSDB'ler bu tür hesaplamaları önceden yaparak (pre-aggregation) veya sorgu zamanında optimize ederek hızlı sonuç döner. Continuous aggregate yapıları, sık kullanılan sorguları önceden hesaplayarak yanıt süresini dramatik şekilde kısaltır. Bu özellik, dashboard ve raporlama senaryolarında kritik performans avantajı sağlar.

TSDB Mimari Temelleri

Columnar Storage ve Sıkıştırma

Zaman serisi veritabanlarının çoğu sütunsal (columnar) depolama kullanır. Aynı tipteki değerler (sıcaklık, nem, basınç gibi) bir arada depolandığında sıkıştırma oranı önemli ölçüde artar. Delta encoding, ardışık zaman damgaları veya yakın değerler arasındaki farkı saklar. Run-length encoding, tekrarlayan değerleri sıkıştırır. Dictionary encoding ise düşük kardinaliteli string değerleri (cihaz tipi, konum gibi) verimli şekilde depolar. Bu teknikler bir arada kullanıldığında zaman serisi verisinde 10x-20x sıkıştırma oranları sağlanabilir, bu da depolama maliyetlerini dramatik şekilde düşürür.

Retention Policy ve Downsampling

Zaman serisi verisi süresiz saklandığında depolama maliyetleri hızla artar. Retention policy, verinin ne kadar süre ham haliyle saklanacağını belirler. Süresi dolan veriler otomatik olarak silinir veya downsample edilerek daha düşük çözünürlükte saklanır. Katmanlı bir saklama stratejisi tipik olarak şu şekilde yapılandırılır: son bir haftalık veri saniye bazında, son bir aylık veri dakika bazında, son bir yıllık veri saat bazında, daha eski veriler ise günlük bazda tutulabilir. Bu strateji, hem depolama verimliliğini hem de geçmişe dönük analiz yeteneğini korur.

Chunk ve Partition Yönetimi

TSDB'ler veriyi zaman bazlı parçalara (chunk/partition) böler. Her chunk belirli bir zaman aralığını kapsar. Bu yapı, zaman bazlı sorguların yalnızca ilgili parçaları taramasını sağlayarak sorgu performansını artırır. Eski chunk'lar sıkıştırılabilir, farklı depolama katmanlarına (sıcak/soğuk depolama) taşınabilir veya tamamen silinebilir. Chunk boyutunun doğru belirlenmesi, yazma ve okuma performansı arasında denge kurar.

InfluxDB: Zaman Serisi Veritabanı Öncüsü

Mimari ve Veri Modeli

InfluxDB, zaman serisi verisi için sıfırdan tasarlanmış bir veritabanıdır. Veri modeli measurement (ölçüm), tag (indeksli etiket), field (değer) ve timestamp bileşenlerinden oluşur. Tag'ler metadata bilgisi taşır ve otomatik olarak indekslenir; field'lar ise ölçüm değerlerini içerir ve indekslenmez.

Tag tasarımı, InfluxDB performansının en kritik faktörüdür. Yüksek kardinaliteye sahip tag'ler (benzersiz değer sayısı yüksek olan UUID, IP adresi, kullanıcı ID gibi) indeks boyutunu şişirir ve sorgu performansını düşürür. Tag olarak yalnızca düşük kardinaliteli alanlar (cihaz tipi, bölge, ortam gibi) kullanılmalıdır. Yüksek kardinaliteli değerler field olarak saklanmalıdır.

Flux Sorgu Dili

InfluxDB 2.x ile birlikte gelen Flux, fonksiyonel bir sorgu ve veri işleme dilidir. Pipe-forward operatörü ile veriler bir dizi dönüşüm adımından geçirilir. Filtreleme, aggregation, join, pivot, window fonksiyonları ve alert tanımlama gibi işlemler tek bir dil ile yapılır.

Flux'ın güçlü yönü, veri dönüştürme ve analiz yeteneklerinin doğrudan sorgu diline entegre olmasıdır. Matematiksel hesaplamalar, string manipülasyonu ve hatta HTTP istekleri Flux içinde gerçekleştirilebilir. Ancak SQL'e alışkın geliştiriciler için öğrenme eğrisi dikkat edilmesi gereken bir noktadır. InfluxDB 3.x sürümü Apache Arrow ve DataFusion üzerine inşa edilerek SQL ve InfluxQL desteği sunmakta ve sorgu performansını önemli ölçüde artırmaktadır.

Continuous Query ve Task

InfluxDB task'ları, belirli aralıklarla çalışan otomatik sorgulardır. Downsampling, alert kontrolü ve veri dönüştürme işlemleri task olarak tanımlanır. Örneğin, her 5 dakikada bir ham sensör verilerini saatlik ortalamaya dönüştüren bir task, depolama optimizasyonu sağlar. Task'lar dead-man alertleri (veri akışının durması durumunda uyarı) için de kullanılabilir.

TimescaleDB: PostgreSQL Uzantısı Olarak TSDB

Hypertable Yapısı

TimescaleDB, PostgreSQL üzerine inşa edilmiş bir zaman serisi uzantısıdır. Hypertable kavramı, tek bir tablo görünümü altında otomatik olarak zaman bazlı chunk'lara bölünmüş bir yapı sunar. Kullanıcı standart SQL ile tablo üzerinde işlem yapar; bölümleme ve optimizasyon arka planda otomatik olarak gerçekleşir.

PostgreSQL ekosisteminin tüm avantajlarından faydalanılır: ACID uyumluluğu, join desteği, JSON/JSONB, full-text search, PostGIS coğrafi sorgular, foreign data wrappers ve zengin uzantı ekosistemi. Mevcut PostgreSQL bilgi birikimi, araçları ve ORM kütüphaneleri doğrudan kullanılabilir. Bu, TimescaleDB'nin en büyük rekabet avantajıdır: yeni bir sorgu dili veya araç seti öğrenmek gerekmez.

Continuous Aggregate

TimescaleDB continuous aggregate, materialized view kavramını zaman serisi verisi için optimize eder. Saatlik, günlük veya haftalık toplamlar önceden hesaplanır ve yeni veri geldikçe artımlı olarak güncellenir. Sorgu zamanında ham veri yerine önceden hesaplanmış sonuçlara erişmek, yanıt süresini büyük ölçüde kısaltır.

Real-time aggregation modu, henüz materialize edilmemiş en güncel verileri ham tablodan okuyarak continuous aggregate sonuçlarıyla birleştirir. Bu sayede kullanıcı her zaman güncel sonuçlara erişir. Continuous aggregate'ler üzerine yeni continuous aggregate tanımlamak (hierarchical aggregation) da mümkündür: saatlik toplamlardan günlük, günlük toplamlardan aylık özet oluşturulabilir.

Sıkıştırma ve Veri Yaşam Döngüsü

TimescaleDB native compression, eski chunk'ları sıkıştırarak depolama alanını 10x-20x azaltır. Sıkıştırılmış veriler hala sorgulanabilir durumdadır. Sıkıştırma politikaları, belirli bir yaştan sonra chunk'ların otomatik olarak sıkıştırılmasını sağlar. Segmentby parametresi, sık filtreleme yapılan sütunları belirler ve sıkıştırılmış veri üzerinde sorgu performansını optimize eder. Orderby parametresi ise sıkıştırma verimliliğini etkiler. Retention politikası ile eski chunk'ların otomatik silinmesi, veri yaşam döngüsü yönetimini tamamlar.

Prometheus: Metrik Odaklı Monitoring

Prometheus, Cloud Native Computing Foundation (CNCF) bünyesindeki bir monitoring ve alerting sistemidir. Pull-based model ile hedef sistemlerden metrikleri düzenli aralıklarla (scrape interval) toplar. PromQL sorgu dili, güçlü ve esnek metrik analizi imkanı sunar. Counter, gauge, histogram ve summary olmak üzere dört temel metrik tipi desteklenir.

Prometheus'un tasarım felsefesi güvenilirlik üzerine kuruludur. Her Prometheus sunucusu bağımsız çalışır ve dış bağımlılığı yoktur; ağ kesintisi durumunda bile yerel depodan metrik sunmaya devam eder. Ancak uzun süreli veri saklama (varsayılan olarak 15 gün) ve yüksek erişilebilirlik için Thanos, Cortex veya VictoriaMetrics gibi çözümlerle genişletilmesi gerekir.

Kubernetes ekosistemiyle doğal entegrasyonu, servis keşfi (service discovery) yetenekleri ve geniş exporter kütüphanesi Prometheus'u bulut-native uygulamalar için standart monitoring aracı konumuna getirmiştir. Alertmanager bileşeni ile koşul bazlı uyarılar tanımlanarak Slack, PagerDuty veya e-posta ile bildirim gönderilir.

QuestDB: Yüksek Performanslı Analitik

QuestDB, özellikle yüksek yazma throughput'u ve hızlı analitik sorgular için optimize edilmiş bir TSDB'dir. Column-oriented depolama, SIMD (Single Instruction Multiple Data) talimatları ve bellek haritalı dosyalar (memory-mapped files) kullanarak saniyede milyonlarca satır yazma kapasitesine ulaşır. Benchmark testlerinde InfluxDB ve TimescaleDB'ye kıyasla önemli performans farkları göstermektedir.

SQL desteği, PostgreSQL wire protocol uyumluluğu ve InfluxDB line protocol desteği ile mevcut araçlarla kolay entegrasyon sağlar. Web tabanlı konsolu, hızlı veri keşfi ve sorgu geliştirme için pratik bir arayüz sunar. Finansal veri analizi, yüksek frekanslı IoT senaryoları ve gerçek zamanlı analitik gereksinimlerinde dikkat çeken bir alternatiftir.

TSDB Karşılaştırma ve Seçim Kriterleri

InfluxDB, TimescaleDB, Prometheus ve QuestDB'yi temel özellikler açısından karşılaştırdığımızda her birinin farklı senaryolarda öne çıktığını görürüz.

InfluxDB, entegre platform yaklaşımı ve geniş IoT ekosistemi ile öne çıkar. Telegraf collector, Kapacitor işleme motoru ve Chronograf görselleştirme araçı ile uçtan uca bir çözüm sunar. TimescaleDB, SQL uyumluluğu ve PostgreSQL ekosistemi avantajı ile mevcut ilişkisel veritabanı altyapısına sahip ekipler için idealdir. Zaman serisi verisi ile ilişkisel veriyi aynı veritabanında birleştirme yeteneği benzersiz bir avantajdır. Prometheus, Kubernetes-native monitoring için standarttır ancak uzun süreli depolama ve yüksek erişilebilirlik için ek çözümler gerektirir. QuestDB, ham performans ve düşük gecikme gerektiren senaryolarda güçlüdür.

Seçim kriterleri arasında mevcut ekip yetkinlikleri, ekosistem uyumu, ölçek gereksinimleri, sorgu karmaşıklığı ve operasyonel maliyet yer alır. SQL bilgisi güçlü bir ekip için TimescaleDB, tam entegre bir platform isteyen ekip için InfluxDB, Kubernetes-native bir yapı için Prometheus doğal seçimlerdir.

Zaman Serisi Veri Modelleme

Tag ve Metrik Tasarımı

Etkili bir veri modeli, sorgu kalıplarına göre tasarlanmalıdır. Sık filtreleme yapılan alanlar tag/label olarak, ölçüm değerleri field/metrik olarak tanımlanır. Örneğin bir IoT senaryosunda cihaz tipi, konum ve birim tag olarak; sıcaklık, nem ve basınç değerleri field olarak modellenir. Narrow table (her metrik ayrı satır) ve wide table (tüm metrikler aynı satırda) arasındaki seçim, sorgu kalıplarına ve TSDB'nin optimizasyon stratejisine bağlıdır.

Kardinalite Yönetimi

Yüksek kardinalite (benzersiz zaman serisi sayısı) TSDB'lerin en büyük düşmanıdır. Her benzersiz tag kombinasyonu yeni bir zaman serisi oluşturur. Kullanıcı ID, session ID veya request ID gibi yüksek kardinaliteli değerleri tag olarak kullanmak, indeks boyutunu kontrol edilemez şekilde büyütür ve bellek tüketimini artırır. Bu değerler field olarak saklanmalı veya ayrı bir ilişkisel veritabanında tutulmalıdır. Kardinalite izleme, TSDB operasyonlarının kritik bir parçasıdır.

Veri Alım Kalıpları

Batch ve Streaming Ingestion

Batch ingestion, büyük miktarda veriyi toplu olarak yazmak için uygundur. Geçmiş veri yüklemeleri, CSV importları ve periyodik veri aktarımları batch yöntemiyle yapılır. Streaming ingestion ise gerçek zamanlı veri akışı için kullanılır. Apache Kafka, MQTT, gRPC veya WebSocket gibi protokollerle sensörlerden veya uygulamalardan sürekli veri alınır. Kafka'nın tampon (buffer) ve yeniden oynatma (replay) yetenekleri, veri kaybını önlemede kritik rol oynar.

MQTT ve IoT Entegrasyonu

IoT senaryolarında MQTT, sensörlerden TSDB'ye veri iletiminde yaygın olarak kullanılan bir hafif mesajlaşma protokolüdür. MQTT broker (Mosquitto, EMQX, HiveMQ) sensör verilerini toplar ve Telegraf gibi bir collector aracılığıyla TSDB'ye yazar. Topic yapısı ve QoS seviyeleri, veri güvenilirliği ve ağ bant genişliği arasında denge kurar. QoS 0 (at most once) düşük bant genişliği senaryoları için, QoS 1 (at least once) ise veri kaybının kabul edilemeyeceği durumlar için tercih edilir.

Buffering ve Write Optimization

Yüksek hacimli yazma senaryolarında istemci tarafında buffer kullanmak, ağ round-trip sayısını azaltır ve yazma verimliliğini artırır. Batch size ve flush interval parametreleri, gecikme ve throughput arasındaki dengeyi belirler. Write-ahead log ve in-memory buffer yapıları, uygulama çökmesi durumunda veri kaybı riskini minimize eder. Back-pressure mekanizması, TSDB'nin kapasitesini aştığında veri kaynağını yavaşlatarak sistem stabilitesini korur.

Görselleştirme: Grafana Entegrasyonu

Grafana, zaman serisi verilerinin görselleştirilmesinde fiili standarttır. InfluxDB, TimescaleDB, Prometheus ve QuestDB dahil tüm önemli TSDB'ler ile native plugin'ler aracılığıyla entegre çalışır. Dashboard tanımları JSON formatında saklanarak versiyon kontrolüne alınabilir; bu da dashboard-as-code yaklaşımını mümkün kılar.

Değişken (variable) yapısı, tek bir dashboard üzerinde farklı cihazları, ortamları veya metrikleri dinamik olarak filtrelemeyi sağlar. Alert kuralları doğrudan Grafana üzerinden tanımlanarak Slack, PagerDuty, OpsGenie veya e-posta ile bildirim gönderilebilir. Grafana Loki (log) ve Tempo (trace) ile birlikte kullanıldığında tam bir gözlemlenebilirlik platformu oluşturur.

Ölçeklendirme ve Yüksek Erişilebilirlik

Tek sunucu kapasitesini aşan senaryolarda yatay ölçeklendirme stratejileri devreye girer. InfluxDB Enterprise ve InfluxDB Cloud kümeleme desteği sunar. TimescaleDB multi-node yapısı ile veriyi birden fazla düğüme dağıtır; ayrıca TimescaleDB Cloud yönetilen bir çözüm olarak operasyonel yükü azaltır. Prometheus ekosisteminde Thanos ve Cortex, yatay ölçeklendirme ve uzun süreli depolama sağlar.

Replikasyon, hem yüksek erişilebilirlik hem de okuma performansı için kritiktir. Yazma ve okuma yükünü farklı düğümlere dağıtmak, sistemin genel kapasitesini artırır. Tiered storage (sıcak/soğuk depolama) stratejisi, sık erişilen verileri hızlı disk'te, eski verileri ise nesne depolamada (S3, GCS) tutarak maliyet optimizasyonu sağlar. Smart Maple olarak IoT ve monitoring projelerimizde ölçeklendirme stratejilerini proje gereksinimlerine göre özelleştiriyoruz.

Kullanım Senaryoları

IoT Sensör Verisi

Endüstriyel IoT, akıllı bina ve tarım teknolojisi uygulamalarında binlerce sensörden gelen sıcaklık, nem, basınç, titreşim ve enerji tüketim verileri TSDB'lerde depolanır. Anomali tespiti, trend analizi ve prediktif bakım bu veriler üzerinden gerçekleştirilir. Makine öğrenmesi modelleri, TSDB'deki geçmiş verilerle eğitilerek arıza tahmini yapabilir.

Uygulama Metrikleri ve Monitoring

CPU kullanımı, bellek tüketimi, istek sayısı, yanıt süresi, hata oranı ve kuyruk derinliği gibi uygulama metrikleri Prometheus veya InfluxDB'de toplanarak sistem sağlığı izlenir. SLO/SLI takibi, kapasite planlama ve performans regresyon tespiti bu verilere dayanır.

Finansal Tick Verisi

Borsa tick verileri, kripto para fiyatları ve döviz kurları milisaniye veya mikrosaniye hassasiyetinde zaman serisi verisidir. Yüksek yazma hızı ve düşük gecikme gerektiren bu senaryo, QuestDB ve TimescaleDB gibi performans odaklı çözümlerle ele alınır. Mum grafikleri, hareketli ortalamalar ve volatilite hesaplamaları TSDB'nin aggregation yetenekleriyle verimli şekilde yapılır.

Enerji ve Karbon Takibi

Enerji tüketim verileri, karbon emisyon ölçümleri ve sürdürülebilirlik metrikleri zaman serisi olarak izlenir. Saatlik, günlük ve aylık tüketim raporları continuous aggregate yapılarıyla verimli şekilde üretilir. Fiyat karşılaştırma platformları, enerji piyasası verilerini TSDB'de saklayarak tarihsel analiz sunar.

Sonuç

Zaman serisi veritabanları, IoT'den monitoring'e, finansal analitikten enerji yönetimine kadar geniş bir kullanım alanında kritik altyapı bileşenidir. Doğru TSDB seçimi, veri hacmi, sorgu kalıpları, ekosistem uyumu ve operasyonel gereksinimlerine bağlıdır.

TimescaleDB SQL bilgi birikimini değerlendirmek isteyen ekipler için, InfluxDB entegre bir IoT platformu arayanlar için, Prometheus Kubernetes-native monitoring ihtiyacı olanlar için ve QuestDB yüksek performanslı analitik senaryoları için öne çıkar. IoT platform geliştirme ve gözlemlenebilirlik stratejisi konularını da inceleyerek zaman serisi altyapınızı bütünsel bir perspektifle tasarlayabilirsiniz.