Sekiz yıllık veri biriktiren bir orders tablosu gördüm. Sorguların %95’i son 90 güne bakıyordu — ama her sorgu, kalan sekiz yılın bedelini indeks boyutunda ve vacuum süresinde ödüyordu. Sıcak veri, soğuk verinin ağırlığını taşıyordu.

Hiçbir tablo sonsuza dek büyüyemez. Arşivleme, bunu kabul edip baştan planlamaktır.

Tablo sonsuza dek büyüyemez

Çoğu tablonun doğal bir sıcak/soğuk ayrımı vardır. Aktif veri — bu haftanın siparişleri, açık biletler — sürekli okunur ve yazılır. Tarihsel veri — üç yıl önce kapanmış kayıtlar — neredeyse hiç değişmez, nadiren okunur. Ama ikisi aynı tabloda yaşadığında, soğuk veri sıcak verinin her sorgusunu yavaşlatır: indeksler şişer, autovacuum yetişemez, working set yapay olarak büyür.

Arşivleme bir yaşam döngüsüdür

Arşivleme, tablo paniğe yol açacak kadar büyüdüğünde akla gelen bir temizlik işi değildir. Verinin bir yaşam döngüsüdür ve ilk gün tasarlanmalıdır: veri sıcak doğar, zamanla ılınır, sonra soğur. Soru “arşivleyecek miyiz” değil, “soğuyan veri nereye gidecek”.

Partition tabanlı arşivleme

En temiz yöntem, tabloyu zamana göre partition’lamaktır — veri yoğunluklu sistemlerin üçüncü kırılma noktasında anlatılan yapı. Append ağırlıklı veride doğal anahtar zamandır ve partition’lar arşivlemeyi neredeyse bedava kılar.

Eski bir partition’ı silmek yerine ayırırsınız:

ALTER TABLE orders DETACH PARTITION orders_2023_01;

DETACH ile partition, ana tablodan kopar ama veritabanında ayrı bir tablo olarak durmaya devam eder. Artık onu istediğiniz gibi taşıyabilirsiniz — silmeden, dondurmadan.

Soğuk depolama seçenekleri

Ayrılan partition’lar, maliyet ve erişim ihtiyacına göre farklı yerlere gidebilir:

  • Ayrı bir arşiv şeması — aynı veritabanında ama archive şemasında; sorgulanabilir, sadece sıcak yoldan uzakta.
  • Daha ucuz disk — partition’ın dosyalarını farklı bir tablespace’e taşımak.
  • Nesne depolama — partition’ı sıkıştırılmış bir dökümle ya da Parquet olarak S3 benzeri bir depoya almak; en ucuzu, en yavaş erişileni.
  • Ayrı bir arşiv veritabanı — canlı sistemin kapasitesinden tamamen bağımsız.

Arşivlerken erişimi korumak

İşin zor kısmı budur: arşivlenen veri çoğu zaman tamamen ölü değildir. Bir denetim, bir destek talebi, yasal bir zorunluluk onu yeniden gerektirebilir. Arşivlemeyi “erişilemez yapmak” ile karıştırmayın.

Pratik dengeler: arşiv tablolarını sorgulanabilir tutmak (sadece ucuz depoda); nesne depolamadaki veriye foreign data wrapper ile erişmek; ya da açıkça “arşiv sorgusu” diye bilinen, yavaş ama çalışan ayrı bir yol bırakmak. Hangisini seçerseniz seçin, soğuk veriye bir kapı bırakın — yeter ki o kapı sıcak yoldan ayrı olsun.

Silmek de bir arşiv kararı

Bazen doğru arşiv, silmektir. Her verinin saklanması gerekmez; bir saklama (retention) politikası, “bu veri ne kadar süre yaşar” sorusuna baştan cevap verir. KVKK/GDPR gibi düzenlemeler bazı veriler için silmeyi zaten zorunlu kılar. Silmeyi de yaşam döngüsünün bir adımı olarak tasarlayın — sonradan akla gelen bir iş olarak değil.

Arşivleme stratejisi, tablonun büyüyeceğini ilk gün kabul etmekle başlar. Sıcak veriyi hızlı tutmanın yolu, soğuk veriyi ona yük olmaktan çıkarmaktır.

Tablonuz büyüyecek; tek soru, bunu sizin mi planladığınız, yoksa production’ın mı size hatırlattığı.