Ölçeklenebilir Yumuşak Silme: İndis Şişmesini Önleme

Yumuşak silme uygulamak, veri kurtarma ve denetim izleri sağlayan modern uygulama geliştirmede standart bir uygulamadır. Ancak, yüksek iş hacimli PostgreSQL sistemlerinde bu yaklaşım önemli bir performans maliyeti getirir. Silinen kayıtlar biriktiğinde, disk alanı tüketir, indeksleri şişirir ve sorgu gecikmesini artırır. Bu yazı, yumuşak silmenin güvenlik ağını korurken performansı sürdürmek için gereken mimari desenleri incelemektedir.

Birikimin Maliyeti

is_deleted boolean bayrağını güncellediğinizde, satır kaybolmaz. Tabloda kalır ve kritik olarak, birincil sorgularınızda kullanılan sütunları kapsayan her indekste de kalır. Zamanla bu, indeks şişmesine yol açar. Şişme, indeks yapısının boyutunu artırarak sayfa okumaları başına daha fazla G/Ç (I/O) işlemine neden olur. Ayrıca, sorgu planlayıcısı, "silinmiş" ile "aktif" satırlar arasındaki oranın heavily (aşırı) bir şekilde sapması durumunda istatistiksel anormalliklerle mücadele edebilir ve bu da alt-optimal yürütme planlarına yol açabilir.

(status, created_at) üzerinde bileşik bir indekse sahip standart bir users tablosunu düşünün. Kullanıcılarınızın %40'ı yumuşak silinmişse, indeks büyük ölçüde alakasız veriyi tarar. Bu, arabellek havuzunda bellek israfına ve is_deleted = false filtresine göre sıralı taramaları veya indeks taramalarını yavaşlatır.

Stratejik Bölütleme

Şişmeyi azaltmanın en etkili yollarından biri tablo bölütleme kullanmaktır. Veriyi zaman tabanlı bir sütuna (created_at veya updated_at gibi) göre böldüğünüzde, eski ve potansiyel olarak yumuşak silinmiş kayıtları izole edebilirsiniz. Bu, şişmeyi otomatik olarak kaldırmaz, ancak daha verimli bakım yapılmasına olanak tanır. Çoğunlukla eski veriler içeren eski bölümleri agresif bir şekilde vakumlayabilir veya hatta ayırıp silebilirsiniz; bu, depolamayı anında geri kazanır ve aktif sorgu düzlemindeki şişmeyi ortadan kaldırır.

Arşiv Tablosu Deseni

Aşırı yüksek yazma hacmine sahip sistemler için, yumuşak silinmiş kayıtları ana çalışma tablosundan taşımak idealdir. Bu, belirli bir yaşın ötesinde silindiği işaretlenen satırları periyodik olarak bir archive tablosuna aktaran bir arka plan işlemi içerir. Bu, birincil tabloyu ince tutar ve aktif verilere odaklanır.

Arşivleme tetikleyicinizin nasıl yapılandırılacağına dair basitleştirilmiş bir örnek:

CREATE OR REPLACE FUNCTION archive_soft_deleted()
RETURNS TRIGGER AS $$
BEGIN
    IF NEW.is_deleted AND OLD.is_deleted = false THEN
        INSERT INTO user_archived (id, name, created_at, deleted_at)
        VALUES (NEW.id, NEW.name, NEW.created_at, NOW());
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER handle_archive
AFTER UPDATE ON users
FOR EACH ROW
WHEN (NEW.is_deleted)
EXECUTE FUNCTION archive_soft_deleted();

Bunun, güncelleme işlemine gecikme eklediğini unutmayın. Yüksek iş hacimli sistemler için, yazma yolunun hızlı kalmasını sağlamak adına, yakın zamanda silinen kayıtları sorgulayan asenkron bir işçinin kullanıldığı gevşek bağlı (decoupled) bir yaklaşım düşünün.

İndis Optimizasyon Teknikleri

Veriyi bir arşive taşıyamıyorsanız, indekslerinizi optimize etmeniz gerekir. Kısmi indeks burada en verimli araçtır. Tüm sütunu indekslemek yerine, yalnızca aktif kayıtları içeren bir indeks oluşturun. Bu, indeks boyutunu büyük ölçüde azaltır ve en yaygın sorgular için tarama performansını iyileştirir.

-- Standart İndis (Verimsiz)
CREATE INDEX idx_users_status ON users(status);

-- Kısmi İndis (Aktif sorgular için verimli)
CREATE INDEX idx_users_active ON users(created_at)
WHERE is_deleted = false;

WHERE is_deleted = false ekleyerek, indeks yalnızca canlı kayıtlara işaretçileri saklar. Bu, disk alanından tasarruf etmenin yanı sıra, PostgreSQL'in bu indeksi özellikle aktif kullanıcı aramaları için kullanmasını sağlar ve tarama yürütülmesi sırasında silinmiş bayrağını kontrol etme yükünden kaçınır.

Sonuç

Yumuşak silmeler güçlüdür ancak PostgreSQL'de gizli maliyetlerle gelir. Kontrol edilmezler, indeks şişmesine ve sorgu bozulmasına yol açar. Kısmi indeksler, stratejik bölütleme ve arşivleme stratejilerini birleştirerek yüksek performanslı bir sistem sürdürebilirsiniz. Anahtar, yumuşak bir silmenin sadece bir bayrak olmadığını; mimari düşünce gerektiren bir veri yaşam döngüsü olayı olduğunu tanımaktır. Uzun vadeli sistem sağlığını sağlamak için tablo şişmesi ve indeks boyutlarının düzenli olarak izlenmesi, standart operasyonel rutininizin bir parçası olmalıdır.