Her veri aynı sıcaklıkta değildir
Son 7 günün sipariş verisi ile 3 yıl önceki event logu aynı performans beklentisine sahip değildir. Biri uygulama akışının parçasıdır, diğeri raporlama veya uyum için gerekebilir. Aynı tabloda aynı şekilde tutulmaları maliyet ve performans borcu üretir.
Bu yüzden veri yaşam döngüsünü sıcak, ılık, soğuk ve silinebilir olarak düşünmek daha sağlıklıdır. Her sınıfın erişim hızı, saklama süresi ve yedek ihtiyacı farklıdır.
- Sıcak veri: uygulama aktif kullanır, düşük gecikme gerekir.
- Ilık veri: raporlama ve destek için gerekir, daha düşük hız kabul edilir.
- Soğuk veri: nadir erişilir, arşiv veya obje depolama uygun olabilir.
- Silinebilir veri: iş veya yasal gereklilik kalmadığında temizlenmelidir.
TTL performans ayarı değil, ürün kararıdır
TTL eklemek teknik olarak kolay görünebilir; ama yanlış TTL kullanıcı deneyimini veya uyum yükümlülüğünü bozabilir. Oturum verisi, önbellek, event logu, ödeme kaydı ve denetim kaydı aynı TTL mantığıyla silinemez.
Önce veri türünü ve saklama gerekçesini yazın. Sonra motorun TTL/partition/drop/archiving özellikleriyle bunu uygulayın.
Yaşam döngüsü karar matrisi
önbellek:* -> TTL zorunlu, yeniden üretilebilir session:* -> iş kuralına göre kısa retention orders -> sıcak OLTP, yasal saklama dikkate alınır events_raw -> belirli süre sıcak, sonra rollup/arşiv denetim_events -> silme değil, uzun retention ve bütünlük kanıtı debug_logs -> kısa retention, maliyet kontrolü
Motorlara göre yaşam döngüsü aracı değişir
Redis tarafında TTL ana araçtır. ClickHouse tarafında partition ve TTL birlikte düşünülür. PostgreSQL/MySQL tarafında arşiv tablosu, partitioning veya planlı temizlik gerekebilir. MongoDB TTL index belirli zaman alanları için kullanışlıdır ama her doküman tipine uygun değildir.
MongoDB TTL index örneği
db.sessions.createIndex(
{ expires_at: 1 },
{ expireAfterSeconds: 0, name: "idx_sessions_expires_at" }
)ClickHouse TTL fikri
CREATE TABLE events_raw ( tenant_id String, created_at DateTime, event_name LowCardinality(String), payload String ) ENGINE = MergeTree PARTITION BY toYYYYMM(created_at) ORDER BY (tenant_id, event_name, created_at) TTL created_at + INTERVAL 180 DAY;
Yedek saklama süresi ile canlı veri retention aynı şey değildir
Canlı tablodan veri silmek yedek maliyetini hemen düşürmeyebilir. Yedek saklama süresi, PITR penceresi ve arşiv politikası ayrı ayrı düşünülür. Bu ayrım yapılmazsa ekip “veriyi sildik ama fatura niye inmedi?” diye şaşırır.
TürkDB tarafında yedek listesi, PITR penceresi ve cluster kapasite bilgisi birlikte okunmalıdır. Yaşam döngüsü kararı, canlı veri ve yedek saklama politikasını aynı masaya koyduğunda gerçekten çalışır.
Yaşam döngüsü kontrolü
turkdb cluster get app-db turkdb backup list app-db turkdb cluster pitr window app-db