DEV Community: Tarık Anafarta

TimescaleDB'deki verileri okuyup alarm yapısına dönüştürmek

Tarık Anafarta — Mon, 16 Mar 2026 10:23:02 +0000

Alarm üretim mantığı genelde manuel yazılıyor. Bu ya PostgreSQL tarafında bir trigger + NOTIFY akışıyla başlatılıyor, ya da uygulama tarafında çalışan bir servis ile okuyup dönüştürülüyor.

Elimizde TimescaleDB üzerinde bir hypertable olduğunu düşünelim:

sensör verisi geliyor
bazı kayıtlar alarm üretmeli
bazı alarmlar tek satırdan çıkıyor, bazıları ise pencere bazlı hesap gerektiriyor, yani son 5 dakikanın ortalaması %80'i geçti mi? gibi

TimescaleDB bu tip akışlar için ne kadar uygun?

TimescaleDB, PostgreSQL'in üzerinde çalıştığı için PostgreSQL'in trigger mekanizmasını destekliyor. Resmi dokümana göre hypertable üzerinde oluşturulan trigger'lar alttaki chunk'lara da yayılıyor.

Ayrıca TimescaleDB'de job mekanizması var ve continuous aggregate desteği de var. Yani alarmı doğrudan her satır insert edildiğinde üretmek zorunda değiliz. Özellikle pencere bazlı kurallarda önce aggregate üretmek, sonra alarm çıkarmak daha mantıklı.

Yaklaşım 1: PostgreSQL LISTEN/NOTIFY ile alarm akışı

Bu modelin mantığı basit:

TimescaleDB hypertable'ına veri gelir.
'AFTER INSERT' trigger çalışır.
Trigger, uygun gördüğü kayıt için pg_notify(...) çağırır.
Uygulamadaki bir listener servis ilgili kanalı dinler.
Listener, payload'daki anahtar bilgiyle gerçek kaydı okur.
Alarm nesnesini oluşturur ve alarms tablosuna yazar.

Artıları nelerdir?

Öncelikle gecikme düşük. NOTIFY, commit sonrası dinleyicilere sinyal gönderir. Yani veri başarılı şekilde commit olduktan hemen sonra uygulaman uyanabilir. Ayrı bir queue ürünü kurmadan, veritabanının içinden olay sinyali alabiliyorsun.

Dikkat edilmesi gereken noktalar:

PostgreSQL dokümanına göre:

bildirimler transaction commit edilmeden teslim edilmiyor
dinleyici transaction içindeyse mesaj ona da transaction bitince teslim ediliyor
aynı transaction içinde aynı kanal ve aynı payload tekrar tekrar gönderilirse tek bildirime indirgenebiliyor
payload varsayılan yapılandırmada 8000 bayttan kısa olmak zorunda
queue dolarsa NOTIFY çağıran transaction commit anında hata alabiliyor

Yani kısaca NOTIFY veri taşımıyor. Sadece olay sinyali veriyor.

NOTIFY için basit örnek

CREATE TABLE sensor_events (
  event_id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  ts timestamptz NOT NULL,
  device_id text NOT NULL,
  metric text NOT NULL,
  value double precision NOT NULL
);

SELECT create_hypertable('sensor_events', by_range('ts'));

CREATE OR REPLACE FUNCTION notify_alarm_candidate()
RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN
  IF NEW.metric = 'temperature' AND NEW.value >= 80 THEN
    PERFORM pg_notify('alarm_candidates', NEW.event_id::text);
  END IF;

  RETURN NEW;
END;
$$;

CREATE TRIGGER trg_notify_alarm_candidate
AFTER INSERT ON sensor_events
FOR EACH ROW
EXECUTE FUNCTION notify_alarm_candidate();

Bu örnekte trigger sadece bu kayıt alarm adayı olabilir diyor. Alarmın gerçekten açılıp açılmayacağına uygulama karar veriyor.

Yaklaşım 2: Yazılımla okumak ve alarma dönüştürmek

Uygulama tarafında bir worker veya servis çalışır.
Bu servis TimescaleDB'den yeni verileri belli bir mantıkla okur.
Okuduğu veriyi alarm modeline dönüştürür.

Bu modelde raw hypertable ayrı kalır, alarm işleme için ayrı bir alarm_candidates tablosu tutulur.

Uygulama worker'ları bu tablodan kayıt çekip işler. Çoklu worker varsa PostgreSQL'in FOR UPDATE SKIP LOCKED özelliği ile çakışmadan paralel tüketim yapılabilir. PostgreSQL dokümanı da SKIP LOCKED kullanımının queue benzeri yapılarda lock çakışmasını azaltmak için uygun olduğunu söylüyor.

Örnek:

WITH picked AS (
  SELECT id
  FROM alarm_outbox
  WHERE status = 'new'
  ORDER BY id
  FOR UPDATE SKIP LOCKED
  LIMIT 100
)
UPDATE alarm_outbox o
SET status = 'processing',
    picked_at = now()
FROM picked
WHERE o.id = picked.id
RETURNING o.*;

Sonuç

NOTIFY, iyi bir tetikleme sinyali, uygulama worker'ı ise daha iyi bir işleme motoru.

Elasticsearch vs RDBMS, Logstash vs Fluentd, Elasticsearch vs Opensearch

Tarık Anafarta — Mon, 09 Mar 2026 11:29:07 +0000

Elasticsearch vs RDBMS

Elasticsearch, büyük veri içinde özellikle metin tabanlı arama (full-text search) yapmak için kullanılan, açık kaynaklı ve dağıtık mimariye sahip bir arama motorudur. Temel amacı çok büyük veri kümeleri içinde belirli kelime veya bilgileri çok hızlı bulabilmektir.

Klasik bir veritabanında veri doğrudan satırlar üzerinden taranırken, Elasticsearch verileri index üzerinden arar. Bu yaklaşım sayesinde milyarlarca kayıt içinde arama işlemleri neredeyse gerçek zamanlı olarak gerçekleştirilebilir.

Elasticsearch indeksleri, ilişkisel veritabanlarında (RDBMS) bulunan indekslerle aynı değildir. Bir Elasticsearch cluster'ı, içinde birçok indeks barındırabilen bir veritabanı gibidir. Her indeks bir tabloya benzer, ve her indeksin içinde birçok doküman bulunur.

RDBMS => Databases => Tables => Columns/Rows
Elasticsearch => Clusters => Indices => Shards => Documents (key-value pairs)

Elasticsearch temelde Apache Lucene üzerine kuruludur. Lucene, metinlerin indekslenmesi ve aranması için kullanılan güçlü bir kütüphanedir. Elasticsearch ise bu altyapıyı kullanarak hem structured hem de unstructured verilerin indekslenmesini ve aranmasını sağlar. Elasticsearch'te tutulan her veri JSON formatında bir document olarak saklanır hepsinin bir id'si vardır.

Bir veri Elasticsearch'e eklendiğinde sistem bu veriyi doğrudan taranabilir halde saklamaz. Bunun yerine belirlenen alanlar indekslenir. İndeksleme sırasında her kelimenin hangi dokümanlarda geçtiği bir liste halinde tutulur. Buna inverted index mantığı denir. Bu yapı Elasticsearch’ün çok hızlı çalışmasının temel sebebidir.

Elasticsearch'ün dağıtık çalışmasını sağlayan önemli yapılardan biri shard ve replica kavramlarıdır. Büyük veri kümelerini tek bir sunucuda tutmak zor olabileceği için bir index birden fazla shard'a bölünür. Shard'lar farklı node'lara dağıtılarak paralel işlem yapılması sağlanır. Böylece hem performans artar hem de sistem yatay olarak ölçeklenebilir.

Logstash vs Fluentd

Logstash'ın çalışabilmesi için JVM gereklidir. Bu bağımlılık yüksek bellek tüketiminin temel nedeni haline gelmiştir. Logstash daha ağırdır ama güçlü transform yapar, Fluentd ise daha hafif ve yüksek ölçekli log toplama için tercih edilir.

Ayrıca Fluent Bit yalnızca log değil, aynı zamanda metrik verilerini de toplayabilir.

Fluentd + Elasticsearch genelde DaemonSet olarak çalışan bir log collector modeliyle kullanılır; logları pod dosyalarından okuyup Kubernetes metadata ekleyerek direkt Elasticsearch'e yollar. Logstash + Elasticsearch tarafında ise Logstash da Kubernetes'te çalıştırılabilir ama JVM tabanlı olduğu için kaynak ayarı ve operasyonu daha ağırdır.

Benchmark Sonuçları

Düşük hacimli veri akışlarında Logstash ve Fluentd sistem üzerinde benzer bir yük oluşturur. Ancak bu durum 16 thread / iş yükü düğümü (workload nodes) noktasına gelindiğinde değişir ve Logstash'ın aynı miktarda olayı işleyebilmek için daha fazla CPU kullandığı açıkça görülür. Ortalama olarak CPU kullanımı %25 daha yüksektir.

Performans elbette kullanılan senaryoya bağlı olsa da Logstash'ın Fluentd'ye kıyasla daha fazla bellek tükettiği bilinmektedir. Fluentd verimli bir log toplayıcıdır ve ölçeklenebilirliği oldukça iyidir.

Docker Desteği

Docker'ın Fluentd için yerleşik bir logging driver'ı vardır, ancak Logstash için böyle bir driver bulunmaz. Fluentd kullanıldığında container üzerinde logları Fluentd'ye göndermek için ekstra bir agent çalıştırmaya gerek yoktur. Loglar ek bir log dosyasına ihtiyaç duymadan doğrudan STDOUT üzerinden Fluentd servisine gönderilir. Logstash'ta ise uygulama loglarının okunabilmesi ve Logstash'a gönderilebilmesi için bir plugin'e (filebeat) ihtiyaç vardır.

Sonuç

Kubernetes ortamlarında da Fluentd, yerleşik Docker logging driver'ı ve parser'ı sayesinde ideal bir aday gibi görünmektedir. Bu yapı sayesinde container üzerinde logları Fluentd'ye göndermek için ek bir agent çalıştırmaya gerek kalmaz. Logstash ile karşılaştırıldığında bu durum mimarinin daha az karmaşık olmasını sağlar ve loglama hataları oluşma riskini de azaltır.

Elasticsearch vs OpenSearch

Benchmark Sonuçları

"Çeşitli testlerin sonuçları dikkate alındığında, Elasticsearch'ün OpenSearch'e kıyasla sürekli olarak daha iyi performans gösterdiği açıkça görülmektedir. Basit sorguların çalıştırılması, verilerin sıralanması, histogram oluşturulması, terim veya aralık sorgularının işlenmesi ya da kaynakların daha verimli kullanılması gibi durumların hepsinde Elasticsearch öne çıkmaktadır." (Kobar & Sangiorgi, 2023)

Elasticsearch'ün arama özellikleri Opensearch'e göre daha gelişmiştir ve AI/ML alanında da geliştirmeler yapmaya başlamıştır.

Kubernetes Objeleri

Tarık Anafarta — Fri, 06 Mar 2026 11:05:58 +0000

Pod

Çalışan en küçük birim. İçerisinde bir veya birden fazla konteyner bulunur. Buradaki konteynerlar kendi içerisinde localhost üzerinden iletişim kurabilirler.

Deployment

İstenen replica sayısını izler, eksikse yeni pod oluşturur fazlaysa siler.

ReplicaSet

İstenilen pod sayısının çalışır olmasını garantileyen objedir. Deployment tarafından arka planda yönetilir.

StatefulSet

Podlara pod-postgres-56945869d5-2kgp8, pod-postgres-75ff6f9cd-4w5xd gibi kimlik verir ve pod yeniden başlasa bile bu değişmez. Her birinin kendi kalıcı volume'ü vardır.

DaemonSet

Cluster'daki her Node üzerinde tam olarak bir pod çalıştırılmasını sağlar. Cluster'a yeni bir node eklendiğinde ilgili pod otomatik olarak o node'a da yerleştirilir. Prometheus Node Exporter gibi altyapı servislerinde de kullanılır.

Job

Tek seferlik ve sonlanması beklenen görevleri çalıştırmak için kullanılır. Pod görevini tamamlarsa durur, hata alırsa başarılı olana kadar yeniden çalıştırılır.

CronJob

İstenilen zamanda job objesi ve buna bağlı pod oluşturulur.

Service

Podların ip ve dns üzerinden erişilebilir olmasını sağlar. NodePort, ClusterIP ve LoadBalancer gibi tipleri vardır.

Ingress

Cluster dışından gelen HTTP ve HTTPS trafiğini service'lere yönlendirir.

NetworkPolicy

Podlar arasındaki ağ trafiğini kontrol eder.

PV

Kalıcı depolama kaynağıdır. Podlar silinse bile veriler durur.

PVC

Pod'ların ihtiyacı olan depolamayı talep etmek için kullandığı objedir.

StorageClass

PVC oluşturulduğunda otomatik olarak PV sağlar.

ConfigMap

Konfigürasyon verilerini saklar.

Secret

Şifre ve token gibi hassas verileri encoded şekilde saklar.

Namespace

Farklı ortamlar için alan oluşturur. Namespace üzerinde RBAC uygulanabilir.

ServiceAccount

Pod'ların Kubernetes API ile kimlik doğrulaması yapmasını sağlayan hesaptır.

Role/ClusterRole

Kaynaklar üzerinde neler yapılabileceğini tanımlayan yetki kurallarıdır. Role yalnızca tanımlandığı namespace içinde geçerliyken cluster role tüm cluster genelinde geçerlidir.

RoleBinding/ClusterRoleBinding

Tanımlanmış bir role'ü kullanıcı, grup veya service account'a bağlayan objedir. Kimin neye erişebileceği açıkça tanımlar.

ResourceQuota

Bir namespace içinde kullanılabilecek kaynakların sınırını belirler.

LimitRange

Namespace içindeki podlar için varsayılan ve maksimum kaynak değerlerini otomatik olarak uygular.

InitContainer

Ana konteyner başlamadan önce çalışan, hazırlık görevi yapan konteynerdır.

Kubernetes - Keycloak OIDC Entegrasyonu

Tarık Anafarta — Tue, 03 Mar 2026 13:11:44 +0000

Amaç: kube-apiserver'ı Keycloak'u OIDC Identity Provider olarak kullanacak şekilde yapılandırmak ve kubelogin tabanlı kubeconfig ile kubectl erişimini sağlamak.

Ortam / Topoloji

Bileşen	Değer
Kubernetes VM (control-plane)	`<ip_adresi>` (RKE2, single-node, static pod)
Keycloak	Helm ile `keycloak` namespace'inde
Rancher	Helm ile `cattle-system` namespace'inde
Ingress Controller	`kube-system` içindeki `rke2-ingress-nginx` (hostPort 80/443)
Keycloak host	`keycloak.example.com`
Rancher host	`rancher.example.com`
Kubernetes API	`<ip_adresi>:6443`

keycloak.example.com ve rancher.example.com gerçek DNS'te yoksa istemci makinede /etc/hosts'a <ip_adresi> keycloak.example.com ve <ip_adresi> rancher.example.com olarak eklenmelidir.

1. Keycloak TLS Sertifikası

Adım 1: CA oluştur

kc-ca.key ve kc-ca.crt üretildi. basicConstraints: CA:TRUE ve keyUsage: keyCertSign ile CA olarak işaretlendi.

Adım 2: SAN config

san.cnf oluşturuldu, subjectAltName olarak DNS.1 = keycloak.example.com eklendi.

Adım 3: Server sertifikası

keycloak.key ve keycloak.csr üretildi. CSR, kc-ca.crt ile imzalanarak keycloak.crt elde edildi.

Adım 4: Keycloak proxy/hostname ayarları

RKE2 ingress hostPort 443 üzerinden yayın yaptığı için issuer'ın port içermemesi gerekiyor. Bu yüzden KC_HOSTNAME şu şekilde set edildi:

KC_PROXY_HEADERS=xforwarded
KC_HOSTNAME=https://keycloak.example.com

/.well-known/openid-configuration ile issuer URL doğrulandı.

2. Keycloak Realm / Client / User / Group

Tüm işlemler Keycloak pod'u içinde kcadm.sh ile yapılır. Container FS read-only olabildiği için HOME=/tmp set edilmeli.

Realm: kubernetes adıyla oluşturuldu.

Client: kubernetes client ID'siyle oluşturuldu. Browser'sız kubeconfig için directAccessGrantsEnabled açık olmalı (password grant).

Groups claim: Token içinde groups claim'i gelmesi için oidc-group-membership-mapper eklendi (claim name: groups).

Group, User, Membership: k8s-admins grubu oluşturuldu. Kullanıcı oluşturuldu, şifresi set edildi (Temporary: Off) ve gruba eklendi.

3. kube-apiserver OIDC Yapılandırması

Yeni Kubernetes sürümlerinde --oidc-ca-file yerine AuthenticationConfiguration daha stabil bir yol. Biz de AuthenticationConfiguration kullandık.

Adım 1: Auth config dosyası

/etc/kubernetes/oidc-auth-config.yaml oluşturuldu. apiVersion: apiserver.config.k8s.io/v1beta1, kind: AuthenticationConfiguration formatında; issuer URL, audiences, CA sertifikası ve claim mapping'leri (preferred_username, groups) içeriyor.

Önemli nokta: issuer URL port içermemeli ve Keycloak'ın .well-known içindeki issuer ile birebir aynı olmalı.

Adım 2: RKE2'de apiserver'a bağlama

RKE2 kube-apiserver manifest'ini direkt editlemek yerine /etc/rancher/rke2/config.yaml kullanılır. Biz şu argümanı ekledik:

authentication-config=/etc/kubernetes/oidc-auth-config.yaml

RKE2 bunu static pod manifest'ine yansıtır.

Adım 3: Doğrulama

kube-apiserver args içinde --authentication-config=/etc/kubernetes/oidc-auth-config.yaml göründüğünde ve loglarda OIDC/TLS hatası kalmadığında entegrasyon başarılı.

4. İstemci Tarafı: kubelogin + kubeconfig

kubelogin kurulumu: GitHub releases'ten Linux amd64 zip indirildi, /usr/local/bin/kubelogin olarak kuruldu.

CA kopyalama: kc-ca.crt (Keycloak CA) istemci makinede ~/.kube/keycloak-ca.crt olarak tutulur.

kubeconfig: Her kullanıcı için ~/.kube/<kullaniciadi>-kubeconfig oluşturulur. exec plugin olarak kubelogin get-token tanımlanır.

Kubernetes cluster CA'sı için istemciye server-ca.crt kopyalanabilir ve kubeconfig'te certificate-authority: ile kullanılabilir (base64 gömmek şart değil).

5. Kullanıcı Bazlı kubeconfig Dağıtımı

Her kullanıcı için Keycloak'ta hesap açılır, o kullanıcının bilgilerini içeren bir kubeconfig üretilir ve dosya kullanıcıya verilir. Kullanıcı sadece bu dosyayla kubectl kullanır, tarayıcı açılmaz, başka bir şey bilmesine de gerek yoktur.

Kullanıcı oluşturma:

Keycloak UI'dan kubernetes realm'ı altında Users -> Add user ile oluşturulur. Credentials sekmesinden şifre set edilir (Temporary: Off). Required Actions boş olmalıdır.

kubeconfig üretme:

~/.kube/<kullaniciadi>-kubeconfig dosyası oluşturulur. exec plugin olarak kubelogin get-token tanımlandı; --grant-type=password, --username, --password, --oidc-client-secret ve --certificate-authority argümanları verilir. interactiveMode: Never ile tarayıcı açılması engellenir.

RBAC:

Her kullanıcı Kubernetes loglarında kendi adıyla görünür. Gruba göre ClusterRoleBinding veya namespace bazlı RoleBinding ile yetkilendirilir.

Test:

KUBECONFIG=~/.kube/<kullaniciadi>-kubeconfig kubectl auth whoami ile kullanıcının doğru kimlikle bağlandığı doğrulanır.

Kubernetes'te TimescaleDB Retention Testleri

Tarık Anafarta — Mon, 02 Mar 2026 12:43:34 +0000

Önceki yazımızda Kubernetes üzerinde iki ayrı kurulum (vanilla PostgreSQL ve TimescaleDB) yapıp az veriyle tablo + index boyutlarını kıyaslamıştık. Bu yazıda aynı environment üzerinde TimescaleDB'nin data retention (eski veriyi silme) yaklaşımını pratikte test ediyoruz.

Ortam

Namespace: database
TimescaleDB pod: timescaledb-single chart (master pod)
StorageClass: local-path (tek node)

Komutlarda iki değişken kullanacağız: NS ve TSPOD.

NS=database
TSPOD="$(kubectl get pod -n $NS -l release=timescaledb,role=master -o jsonpath='{.items[0].metadata.name}')"
echo "TSPOD=$TSPOD"

Bu blok sonraki komutlarda kullanacağımız değişkenleri hazırlar.

Deney 1 - Manuel chunk droplama (drop_chunks)

Bu deneyde 48 saatlik veri bastık (5 dakikada bir), sonra 24 saatten eski chunk'ları manuel olarak dropladık.

1A) Kurulum ve veri basma

kubectl exec -n $NS -i $TSPOD -- psql -U postgres -v ON_ERROR_STOP=1 <<'SQL'
CREATE EXTENSION IF NOT EXISTS timescaledb;
CREATE SCHEMA IF NOT EXISTS lab;

DROP TABLE IF EXISTS lab.sensor_ret_manual;
CREATE TABLE lab.sensor_ret_manual (
  time        TIMESTAMPTZ NOT NULL,
  device_id   INT,
  temperature DOUBLE PRECISION
);

SELECT create_hypertable(
  'lab.sensor_ret_manual',
  'time',
  chunk_time_interval => INTERVAL '1 hour',
  create_default_indexes => FALSE
);

CREATE INDEX sensor_ret_manual_time_idx ON lab.sensor_ret_manual(time);

INSERT INTO lab.sensor_ret_manual
SELECT
  generate_series(NOW() - INTERVAL '48 hours', NOW(), INTERVAL '5 minutes'),
  (random() * 10)::int,
  random() * 100;
SQL

Burada lab schema'sını ve 1 saatlik chunk'larla hypertable'ı oluşturup sonra 48 saatlik örnek veri basıyoruz.

1B) Silmeden önce ölçüm

kubectl exec -n $NS -i $TSPOD -- psql -U postgres -v ON_ERROR_STOP=1 <<'SQL'
SELECT count(*) AS rows_before
FROM lab.sensor_ret_manual;

SELECT show_chunks('lab.sensor_ret_manual') AS chunk_before;

SELECT
  pg_size_pretty(sum(pg_total_relation_size(chunk::regclass))) AS total_before
FROM show_chunks('lab.sensor_ret_manual') AS chunk;
SQL

Burada ise silmeden önce satır sayısı, hangi chunk'ların oluştuğu ve chunk'ların toplam disk boyutunu görüyoruz.

Benim makinemdeki çıktılar:

rows_before: 577
chunk_before: 49 chunk
total_before: 1176 kB

1C) 24 saatten eski chunk'ları dropla (manuel)

kubectl exec -n $NS -i $TSPOD -- psql -U postgres -v ON_ERROR_STOP=1 <<'SQL'
SELECT drop_chunks('lab.sensor_ret_manual', older_than => INTERVAL '24 hours');
SQL

İşte şimdi 'now() - 24 hours' çizgisinin tamamen solunda kalan chunk tablolarını topluca DROP ettik. Satır satır silme yok. Chunk bazında hızlıca droplar.

1D) Silmeden sonra ölçüm

kubectl exec -n $NS -i $TSPOD -- psql -U postgres -v ON_ERROR_STOP=1 <<'SQL'
SELECT count(*) AS rows_after
FROM lab.sensor_ret_manual;

SELECT show_chunks('lab.sensor_ret_manual') AS chunk_after;

SELECT
  pg_size_pretty(sum(pg_total_relation_size(chunk::regclass))) AS total_after
FROM show_chunks('lab.sensor_ret_manual') AS chunk;
SQL

Burada drop_chunks sonrasında satır/chunk/boyutun gerçekten azaldığını doğruladık.

Benim makinemdeki çıktılar:

rows_after: 299
chunk_after: 25 chunk
total_after: 600 kB

Önemli not: 'older_than => 24 hours' her zaman 'tam 24 saatin dışındaki tüm satırlar gider' demek değildir. Cutoff çizgisini kesen bir chunk içinde hem eski hem yeni veri varsa, o chunk komple droplanmaz. Bu nedenle az miktarda daha eski satır kalabilir.

Deney 2 - Otomatik veri saklama politikası (add_retention_policy + run_job)

Bu deneyde ise TimescaleDB'nin dahili job mekanizması ile otomatik retention kurduk ve job'ı manuel tetikledik.

2A) Hypertable oluştur ve veri ekle

kubectl exec -n $NS -i $TSPOD -- psql -U postgres -v ON_ERROR_STOP=1 <<'SQL'
DROP TABLE IF EXISTS lab.sensor_ret_policy;
CREATE TABLE lab.sensor_ret_policy (
  time        TIMESTAMPTZ NOT NULL,
  device_id   INT,
  temperature DOUBLE PRECISION
);

SELECT create_hypertable(
  'lab.sensor_ret_policy',
  'time',
  chunk_time_interval => INTERVAL '1 hour',
  create_default_indexes => FALSE
);

CREATE INDEX sensor_ret_policy_time_idx ON lab.sensor_ret_policy(time);

INSERT INTO lab.sensor_ret_policy
SELECT
  generate_series(NOW() - INTERVAL '48 hours', NOW(), INTERVAL '5 minutes'),
  (random() * 10)::int,
  random() * 100;
SQL

Bu blok ile otomatik retention deneyi için ikinci bir hypertable oluşturduk ve aynı şekilde 48 saatlik örnek veriyi doldurduk.

2B) Retention policy ekle (24 saat tut)

kubectl exec -n $NS -i $TSPOD -- psql -U postgres -v ON_ERROR_STOP=1 <<'SQL'
SELECT add_retention_policy('lab.sensor_ret_policy', INTERVAL '24 hours');
SQL

Burada ise TimescaleDB içinde arka planda çalışacak bir retention job'u oluşturduk. Dönüş değeri job_id olur.

2C) Job'ı bul ve çalıştır

kubectl exec -n $NS -i $TSPOD -- psql -U postgres -v ON_ERROR_STOP=1 <<'SQL'
SELECT job_id, proc_name, schedule_interval, config
FROM timescaledb_information.jobs
WHERE proc_name = 'policy_retention'
ORDER BY job_id DESC;

CALL run_job(<yukaridaki_job_id>);
SQL

Burası retention job'unun konfigürasyonunu gösterir ve beklemeden hemen çalıştırır. Normalde job schedule_interval'a göre otomatik çalışır.

2D) Sonucu doğrula

kubectl exec -n $NS -i $TSPOD -- psql -U postgres -v ON_ERROR_STOP=1 <<'SQL'
SELECT count(*) AS rows_after
FROM lab.sensor_ret_policy;

SELECT
  pg_size_pretty(sum(pg_total_relation_size(chunk::regclass))) AS total_after
FROM show_chunks('lab.sensor_ret_policy') AS chunk;
SQL

Bu blok policy çalıştıktan sonra kalan satır sayısını ve chunk toplam boyutunu ölçer. Yani job'un gerçekten eski chunk'ları dropladığını kanıtlar.

Benim makinemdeki çıktılar:

rows_after: 299
total_after: 600 kB

Bu, retention policy'nin temelde drop_chunks ile aynı chunk droplama mekanizmasını otomatik olarak çalıştırdığını gösteriyor.

Temizlik

kubectl exec -n $NS -i $TSPOD -- psql -U postgres -v ON_ERROR_STOP=1 <<'SQL'
SELECT remove_retention_policy('lab.sensor_ret_policy');
DROP SCHEMA IF EXISTS lab CASCADE;
SQL

Burası retention policy'yi kaldırır ve lab schema'sını CASCADE ile silerek tüm test tablolarını ve internal chunk tablolarını temizler.

SQL DELETE vs TimescaleDB retention

TimescaleDB'nin sunduğu yerleşik, chunk tabanlı silme yöntemlerini kullanmak çoğu zaman en verimli yoldur. Yine de hangi yöntemin doğru olduğuna senaryo karar verir.

SQL DELETE (satır bazlı)

Artıları:

İnce ayar: Sadece belirli cihazın verisi, belirli aralık, GDPR gibi seçici silmeler için uygundur.
Chunk sınırına bağlı kalmadan hedeflediğin satırları silersin.

Eksileri:

PostgreSQL MVCC nedeniyle satırlar diskten hemen silinmez; dead tuple olarak kalır.
Büyük silmeler table bloat üretir; disk alanını gerçekten geri almak için VACUUM (bazen agresif vacuum) ve kimi zaman REINDEX gerekebilir.
Çok miktarda veride satır satır silmek yavaş ve maliyetlidir (IO/CPU artışı).

TimescaleDB retention (chunk bazlı)

Artıları:

Chunk'lar komple droplandığı için genellikle çok hızlıdır (DROP TABLE benzeri).
Relation size çoğu senaryoda hemen düşer (örneğin benim makinemde 1176 kB -> 600 kB).
add_retention_policy ile cron/script yazmadan, DB içindeki job mekanizmasıyla otomatik yönetim sağlanır.
Zaman serisi kullanımında en doğal model: 'ham veriyi X süre tut, eskisini at'.

Eksileri / dikkat edilmesi gerekenler:

Granularity: Retention satır bazlı değil chunk bazlıdır. Cutoff'u kesen chunk kalabilir; bu yüzden az miktarda daha eski satır tutulabilir.
Seçici silme için uygun değildir (ör. sadece device_id=3 verisini silmek). Bu tip işlerde DELETE gerekir.
Lock ihtiyacı: Chunk drop, ilgili chunk'lar üzerinde lock alır; uzun transaction varsa drop gecikebilir veya timeout görebiliriz.

Sonuç

Hedefiniz 'X süreden eski zaman serisi ham verisini otomatik ve verimli şekilde kaldırmak' ise TimescaleDB'nin retention policy (add_retention_policy) veya manuel drop_chunks yaklaşımı genellikle en doğru ve yönetimi en kolay çözümdür. Buna rağmen seçici ve ince ayarlı silme ihtiyaçlarında SQL DELETE hala gerekli bir araçtır.

Kubernetes Üzerinde Az Veri İçeren Veritabanı İçin PostgreSQL ve TimescaleDB Storage Kıyaslaması

Tarık Anafarta — Mon, 02 Mar 2026 10:09:22 +0000

Amaç

Kubernetes üzerinde iki ayrı kurulum yapıp (vanilla PostgreSQL + TimescaleDB) küçük bir veri setiyle storage kullanımını kıyaslamak.

Not: TimescaleDB zaten PostgreSQL üzerinde çalışır. Burada "TimescaleDB kurulumu" dediğimiz şey, içinde PostgreSQL + Timescale extension bulunan ayrı bir kurulumdur. "vanilla PostgreSQL" de kuruyoruz ki sonuçlar daha net olsun.

Ön koşullar

Çalışan bir Kubernetes cluster'ı ve kubectl erişimi
Helm
Kurulum tek node'lu bir cluster'da yapılmıştır ve StorageClass local-path'tir.

1. Aşama: Kurulum

1.1 Namespace

kubectl create namespace database

1.2 Helm repo'ları

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo add timescaledb 'https://charts.timescale.com'
helm repo update

2. Aşama: Vanilla PostgreSQL (bitnami) kurulumu

postgres-values.yaml oluşturalım:

cat > postgres-values.yaml << 'EOF'
auth:
  postgresPassword: "postgres123"

primary:
  persistence:
    storageClass: "local-path"
EOF

Kurulum:

helm install postgres bitnami/postgresql   -n database   -f postgres-values.yaml

Pod'un ayağa kalkmasını bekleyelim:

kubectl get pods -n database -w

3. Aşama: TimescaleDB kurulumu (Timescale chart)

timescaledb-values.yaml oluşturalım:

cat > timescaledb-values.yaml << 'EOF'
replicaCount: 1

image:
  repository: timescale/timescaledb-ha
  tag: pg14.6-ts2.9.1-p1

secrets:
  credentials:
    PATRONI_SUPERUSER_PASSWORD: "postgres123"
    PATRONI_REPLICATION_PASSWORD: "replication123"
    PATRONI_admin_PASSWORD: "admin123"

backup:
  enabled: false
EOF

Kurulum:

helm install timescaledb timescaledb/timescaledb-single   -n database   -f timescaledb-values.yaml

Pod'un ayağa kalkmasını bekleyelim:

kubectl get pods -n database -w

4. Aşama: Bağlantı (2 ayrı terminal açabilirsiniz)

4.1 PostgreSQL’e bağlanma (Şifre: postgres123)

PGPOD="$(kubectl get pod -n database -l app.kubernetes.io/instance=postgres,app.kubernetes.io/name=postgresql -o name | head -n 1)"
kubectl exec -it -n database ${PGPOD} -- psql -U postgres

4.2 TimescaleDB’ye bağlanma (Şifre: postgres123)

MASTERPOD="$(kubectl get pod -o name --namespace database -l release=timescaledb,role=master)"
kubectl exec -it --namespace database ${MASTERPOD} -- psql -U postgres

Not: İki ayrı pod'a bağlanıyoruz. Aynı işlemleri iki farklı DB kurulumunda da çalıştırıyoruz.

5. Aşama: Küçük veri setiyle test

Aşağıdaki SQL'i iki tarafta da uygulayacağız:

PostgreSQL'de sensor_pg normal tablo olacak
TimescaleDB'de sensor_ts hypertable olacak

Veri az olsun diye 30 gün yerine 1 gün üretiyoruz.

5.1 PostgreSQL:

PostgreSQL pod'unda psql içindeyken:

CREATE TABLE sensor_pg (
  time        TIMESTAMPTZ NOT NULL,
  device_id   INT,
  temperature FLOAT
);

CREATE INDEX sensor_pg_time_idx ON sensor_pg(time);

INSERT INTO sensor_pg
SELECT
  generate_series(NOW() - INTERVAL '1 day', NOW(), INTERVAL '1 minute'),
  (random() * 10)::int,
  random() * 100;

SELECT count(*) FROM sensor_pg;

5.2 TimescaleDB:

TimescaleDB pod'unda psql içindeyken:

CREATE EXTENSION IF NOT EXISTS timescaledb;

CREATE TABLE sensor_ts (
  time        TIMESTAMPTZ NOT NULL,
  device_id   INT,
  temperature FLOAT
);

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

CREATE INDEX sensor_ts_time_idx ON sensor_ts(time);

INSERT INTO sensor_ts
SELECT
  generate_series(NOW() - INTERVAL '1 day', NOW(), INTERVAL '1 minute'),
  (random() * 10)::int,
  random() * 100;

SELECT count(*) FROM sensor_ts;

Not: TimescaleDB'de hypertable tek tablo gibi görünür ama arkada chunk'lara ayrılır. Az veri testinde bile en azından bir chunk oluşur.

6. Aşama: Storage ölçümü

Bu işi iki seviyede ölçmek daha somut sonuçlar sağlar:

1) Relation size (SQL ile): tablo+index boyutları için
2) Data directory (filesystem ile): gerçek disk kullanımı için

6.1 PostgreSQL: SQL ile tablo boyutu

PostgreSQL pod'unda:

SELECT
  pg_size_pretty(pg_table_size('sensor_pg'))        AS table_only,
  pg_size_pretty(pg_indexes_size('sensor_pg'))      AS indexes,
  pg_size_pretty(pg_total_relation_size('sensor_pg')) AS total;

6.2 TimescaleDB: SQL ile hypertable boyutu (chunk bazında)

TimescaleDB pod'unda:

SELECT
  pg_size_pretty(sum(pg_table_size(chunk.id::regclass))) AS table_only,
  pg_size_pretty(sum(pg_indexes_size(chunk.id::regclass))) AS indexes,
  pg_size_pretty(sum(pg_total_relation_size(chunk.id::regclass))) AS total
FROM show_chunks('sensor_ts') AS chunk(id);

Chunk bazında bakmamızın nedeni hypertable fiziksel olarak chunk tablolardan oluşur. Yani gerçek data+index boyutu chunk'ların toplamıdır.

7. Benim ortamımdaki çıktı

PostgreSQL

postgres=# SELECT count(*) FROM sensor_pg;
 count 
-------
  1441
(1 row)

TimescaleDB

postgres=# SELECT count(*) FROM sensor_ts;
 count 
-------
  1441
(1 row)

7.1 SQL (relation) boyutları

Tabloların ve indexlerin PostgreSQL içinde kapladığı alanlar.

PostgreSQL (sensor_pg)

 table_only | indexes | total  
------------+---------+--------
 112 kB     | 48 kB   | 160 kB
(1 row)

TimescaleDB (sensor_ts)

 table_only | indexes | total  
------------+---------+--------
 112 kB     | 72 kB   | 184 kB
(1 row)

table_only iki tarafta da aynı iken indexes kısmı Timescale tarafında daha fazla.

8. Neden Timescale küçük veride daha büyük çıkabiliyor?

TimescaleDB tarafında hypertable fiziksel olarak chunk tablolardan oluşur. Her chunk kendi tablo/index yapısını taşır.
Küçük veri setlerinde bu yapı "overhead" olarak daha görünür olur.

Sonuç olarak üzerinde çok veri olmayan bir tablo senaryosunda, Timescale hypertable'ın chunk/index overhead'i yüzünden PostgreSQL biraz daha küçük göründü.

Kubernetes'te StorageClass Nedir?

Tarık Anafarta — Thu, 26 Feb 2026 11:49:45 +0000

PV, PVC ve Veri Gerçekten Nerede Saklanıyor?

Bu yazıda şu konuları inceleyeceğim:

PV (Persistent Volume) nedir?
PVC (Persistent Volume Claim) nedir?
StorageClass ne işe yarar?
Static ve Dynamic provisioning farkı nedir?
Disk gerçekte nerede? (Local PV, NFS, Cloud Storage)
Object storage (S3) nedir? MinIO ne işe yarar?
Distributed storage örnekleri: Ceph ve Longhorn
MariaDB / PostgreSQL gibi uygulamalarda disk nerede?

Storage Akışının Mantığı

Öncelikle Kubernetes'te storage zinciri şu şekildedir:

Pod -> PVC -> StorageClass -> PV -> Physical Storage

Persistent Volume (PV)

PV, cluster içindeki gerçek disk kaynağını temsil eder.

Bu kaynak şunlardan birisidir:

Node üzerindeki local disk
NFS share
Cloud block storage (AWS EBS, GCE PD, Azure Disk)
Distributed storage

Yani aslında PV, storage'ın kendisidir.

Persistent Volume Claim (PVC)

PVC ise uygulamanın disk talebidir.

Örneğin:

10Gi storage
Access mode: ReadWriteOnce
storageClass: fast-storage

PVC diski oluşturmaz, bir disk talep eder.

StorageClass Nedir?

StorageClass, PVC oluşturulduğunda disk'in nasıl sağlanacağını belirler.

Yani, disk local mi olacak? NFS mi olacak? Cloud block storage mı olacak? Otomatik mi üretilecek? Hangi performans sınıfı kullanılacak? Gibi sorulara cevap veren bir policy katmanıdır.

Static ve Dynamic Provisioning

Static Provisioning

Static provisioning modelinde PV manuel olarak oluşturulur. Yani önce storage kaynağı tanımlanır, ardından PVC bu PV'ye bağlanır.

Bu yöntem daha fazla kontrol sağlar ancak her yeni disk ihtiyacında manuel işlem gerektirir. Genellikle test ortamlarında veya local/NFS kurulumlarında tercih edilir.

Dynamic Provisioning

Dynamic provisioning modelinde ise sadece PVC oluşturulur.
Bağlı olduğu StorageClass, arka planda otomatik olarak uygun bir PV üretir ve PVC'ye bağlar.

Bu süreç CSI (Container Storage Interface) driver'ları sayesinde çalışır.
Production ortamlarında genellikle dynamic provisioning tercih edilir çünkü daha otomatik ve ölçeklenebilirdir.

Disk Gerçekte Nerede?

Bu sorunun cevabı PV tanımındadır.

Local PV

PV şu path'i gösteriyorsa: /mnt/k8s/data, disk node üzerindedir. Node arızalanırsa veri kaybedilebilir. Pod başka node'a taşınırsa diske erişilemez.

NFS

PV şu şekilde tanımlanmışsa:

nfs:
  server: 192.168.1.10
  path: /srv/nfs/share

Disk NFS server üzerindedir. Pod hangi node'da olursa olsun aynı veriye erişebilir.

Cloud Storage

PV bir cloud volume'a bağlıysa, disk cloud provider tarafındadır.

Object Storage (S3) ve MinIO

Şimdiye kadar bahsettiğim storage türleri çoğunlukla disk mantığında (block/file) çalışıyordu. Ancak pratikte sıkça kullanılan bir model daha var: Object storage. S3/MinIO genellikle database'in primary storage'ı olarak kullanılmaz; daha çok backup, log ve dosya arşivi gibi senaryolarda tercih edilir.

S3 (Simple Storage Service) Nedir?

S3 bir object storage yaklaşımıdır. Dosyalar filesystem gibi "klasör/dosya" mantığından ziyade "object" olarak saklanır. Genellikle şu senaryolarda kullanılır:

Dosya yükleme (upload)
Log arşivleme
Backup (özellikle database backup)
Media saklama (image/video)

S3 çoğunlukla PV/PVC gibi mount edilerek kullanılmaz. Uygulama S3 API üzerinden erişir.

MinIO Nedir?

MinIO, S3 uyumlu bir object storage çözümüdür. Özellikle cloud'dan bağımsız (on-premise) ortamlarda veya Kubernetes içinde S3 benzeri bir servis ihtiyacında kullanılır.

MinIO genellikle PV üzerinde çalışır. Yani MinIO'nun kendi datası için altında yine PV/PVC bulunabilir. Uygulamalar ise MinIO’ya S3 API ile erişir.

Distributed Storage: Ceph ve Longhorn

Distributed storage, veriyi tek bir node'a bağımlı bırakmak yerine birden fazla node'a yayarak (replication) daha dayanıklı bir yapı sunmayı hedefler. Ceph/Longhorn gibi çözümler Kubernetes'e genellikle CSI driver ile entegre olur ve StorageClass üzerinden dynamic provisioning sağlar.

Ceph

Ceph yaygın bir distributed storage sistemidir. Kubernetes ortamında çoğunlukla Rook-Ceph gibi operatörlerle yönetilir. Ceph ile farklı storage tipleri sağlanabilir:

Block storage
File storage
Object storage (S3-compatible)

Ceph'in temel avantajı, verinin birden fazla node'a replike edilebilmesi ve node kayıplarında veri kaybı riskinin azalmasıdır.

Longhorn

Longhorn, Kubernetes-native bir distributed block storage çözümüdür. Longhorn tarafında öne çıkan özellikler:

Volume replication
Snapshot / backup mekanizmaları

Longhorn genellikle küçük veya orta ölçekli cluster'larda veya daha hızlı kurulup yönetilmesi gereken ortamlarda tercih edilir.

Access Modes

RWO (ReadWriteOnce) -> Sadece tek node yazabilir
RWX (ReadWriteMany) -> Birden fazla node yazabilir
ROX (ReadOnlyMany) -> Birden fazla node sadece okuyabilir

Reclaim Policy

PVC silindiğinde disk'in nasıl davranacağını reclaim policy belirler. Kubernetes'te 3 farklı reclaim policy vardır (1 tanesi eski).

Retain -> PVC silinse bile PV ve içindeki veri korunur.
Delete -> PVC silindiğinde PV ve arkasındaki storage kaynağı silinir.
Recycle (Deprecated) -> PV içindeki veriyi basitçe temizleyip tekrar kullanılabilir hale getirirdi.

Örneğin: MariaDB ve PostgreSQL Verisi Nerede?

Bir database container'ı çalıştırdığınızda veri her zaman belirli bir data directory içine yazılır. Önemli olan, bu klasör container içinde mi kalıyor, yoksa bir PVC üzerinden gerçek diske mi bağlanıyor?

MariaDB

MariaDB'nin varsayılan veri dizini: /var/lib/mysql

Eğer persistence yapılandırılmadıysa bu dizin container filesystem'i üzerindedir. Pod silindiğinde veri kaybolur.

Eğer persistence enabled ise bu path bir volumeMount ile bir PVC'ye bağlanır.

PVC -> PV -> Physical storage

Pod silinse bile veri korunur.

Pod içinden mount durumunu görmek için:

kubectl describe pvc -n <namespace> <pvc-ismi>

Mount edilen path'leri burada görebilirsiniz.

PostgreSQL

PostgreSQL’in varsayılan veri dizini: /var/lib/postgresql/data

Mantık MariaDB ile aynıdır. Persistence yoksa veri geçicidir. Pod restart edildiğinde veri kaybolabilir.

Persistence varsa bu dizin bir PVC'ye mount edilir. Gerçek disk PV tarafındadır.

Gerçek Disk Yeri Nasıl Bulunur?

kubectl get pvc -n <namespace> # PVC'yi bul
kubectl describe pvc <pvc-ismi> # Bağlı olduğu PV'yi bul
kubectl describe pv <pv-ismi> # PV detayını incele

Burada şunu görürüz: Local path mi? NFS server mı? Cloud volume mu? Distributed storage mı?

Kısaca, gerçek disk yeri PV tanımında yazar.