Silme iki olaydır

4. Çok sürümlü eşzamanlılık denetimi

Çok sürümlü eşzamanlılık denetimi (MVCC), okuma ve yazmaların birbirini kilitlemeden ilerlemesini sağlar (Reed, 1978; Bernstein ve Goodman, 1983). Bir transaction başladığında veritabanının o anki tutarlı durumunun bir snapshot'ını alır ve bütün okumalarını o snapshot üzerinden yapar. Bir kayıt güncellendiğinde ya da silindiğinde veritabanı mevcut sürümün üzerine yazmaz; yeni bir sürüm oluşturur ve eskisini tutar. Güncellemeden önce alınmış bir snapshot, kaydı eski haliyle görmeye devam etmek zorundadır.

Dolayısıyla bir MVCC veritabanında her güncelleme ve her silme, geçersiz ilan edilmiş ama henüz geri kazanılamayan bir sürüm bırakır. PostgreSQL bunlara dead tuple, InnoDB undo record, Cassandra tombstone der. PostgreSQL'de bunları temizleyen sürecin adı vacuum'dur.

İsim, Stonebraker'ın (1987) POSTGRES depolama sistemi tasarımına dayanır. Kayıtların üzerine hiç yazılmıyordu ve eski sürümler "vacuum cleaner" adlı bir süreçle arşiv depolamasına taşınıyordu. Amaç geçmişi silmek değil, geçmiş sürümleri sorgulayabilmekti (time travel). Özellik performans ve depolama maliyeti gerekçesiyle PostgreSQL 6.2'de (1997) kaldırıldı, ve vacuum eski sürümleri arşivleyen bir süreçten onların alanını geri kazanan bir sürece dönüştü.

Aynı ayrım, Veri dillerinin anatomisi'nin özyinelemeli yorumlama yığını örneği olarak kullandığı SQLite'ta aynı anda iki düzeyde görülür. Dosya sistemi için bir SQLite veritabanı tek bir dosyadır; içeriden bakınca tablolar ve satırlar barındırır. SQLite'ta bir satır silindiğinde baytları dosyadan çıkarılmaz: alan sayfa içinde boş olarak işaretlenir, tamamen boşalan sayfalar dosyanın freelist'ine girer. Yapı, FAT32'nin bir dizin girdisini işaretleyip cluster'larını serbest bırakmasıyla aynıdır, yalnızca bir düzey yukarıda, bir dosyanın içinde. PRAGMA secure_delete açık değilse silinen içerik dosyada kalır, ve dosya ancak SQLite'ın kendi VACUUM komutu onu yeniden yazdığında küçülür.

5. Vacuum ufku

Vacuum her ölü sürümü temizleyemez, yalnızca hiçbir aktif snapshot'ın artık göremeyeceği sürümleri temizleyebilir. O çizgiye vacuum ufku denir. Terimin iki parçası vardır:

• Vacuum, ölü sürümleri bulup alanlarını geri kazanan süreçtir.
• Ufuk, o sürecin ne kadar ileri gidebileceğini belirleyen çizgidir: hiçbir aktif okuyucu bu çizgiden eski bir sürümü görmez ve hiçbir zaman görmeyecektir.

İkisini ayrı tutmak pratikte önemlidir. Vacuum'un yetişememesi bir konfigürasyon sorunudur; ne sıklıkla çalıştığı, kaç worker'ı olduğu ve maliyet limitleriyle ilgilidir. Kımıldamayan bir ufuk ise konfigürasyon sorunu değildir: vacuum ne kadar sık çalışırsa çalışsın, ufkun ötesindeki hiçbir şeyi temizleyemez.

Biçimsel olarak:

ufuk = min { s : s, aktif bir okuyucunun snapshot'ı }

Tanımın belirleyici öğesi min'dir. Ufuk okuyucuların ortalaması değil, minimumudur. Bu yüzden uzun süren tek bir okuyucu, diğerlerinin ne kadar sürdüğünden bağımsız olarak ufku belirler. Sistemdeki okuyucuların ezici çoğunluğunun milisaniyeler içinde bitmesi hiçbir şeyi değiştirmez.

6. Bir örnek: boşta bırakılmış bir transaction

Cuma günü saat 18:40'ta bir analist rapor için veritabanına bağlanır, bir transaction başlatır, tek bir SELECT çalıştırır ve istemciyi kapatmadan işi bırakır. PostgreSQL'de oturum idle in transaction durumunda kalır. Transaction kilit tutmaz, hiçbir şey yazmaz ve kaynak tüketmez; ama snapshot'ı aktif olduğu için ufku 18:40'a çiviler.

Hafta sonu boyunca orders tablosundaki her güncelleme yeni bir sürüm oluşturur ve eskisini geride bırakır. Autovacuum takvimine uygun çalışır ama hiçbirini temizleyemez, çünkü 18:40'ta alınmış bir snapshot ilke olarak onları hâlâ görebilir. Pazartesi sabahı tablo 30 GB'tan 210 GB'a çıkmıştır; satır sayısı ise neredeyse değişmemiştir.

VACUUM (VERBOSE) çıktısı (PostgreSQL 15 ve sonrası) bunu doğrudan gösterir:

tuples: 0 removed, 1204117 remain, 1198320 are dead but not yet removable
removable cutoff: 88213410, which was 4120331 XIDs old when operation ended

"Dead but not yet removable", temizlenecek sürümlerin bulunduğunu ama ufkun onların silinmesini engellediğini söyler.

7. Başka sistemlerde aynı çizgi

Aynı yapı, bir kaydın birden fazla sürümünü aynı anda tutan ya da okuyucular hâlâ kullanıyor olabilirken paylaşılan veriyi serbest bırakmak zorunda olan her sistemde vardır. Farklı sistemlerde ve makalelerde farklı adlarla geçer: PostgreSQL'de xmin horizon, TiDB'de GC safe point, Hekaton'da en eski aktif transaction'ın yönettiği garbage collection (Diaconu vd., 2013), bellek içi MVCC sistemleri üzerine çalışmalarda ise en sık low watermark (Böttcher vd., 2019).

Tablodaki sistemler, Veri dillerinin anatomisi'nin dosya sistemi, veritabanı ve mesaj kuyruğu adlı ayrı kategorilere ayırdığı sistemlerdir; oysa hepsi aynı baytlar üzerinde çalışan isimlendirme programlarıdır. Dolayısıyla silme kuralları birbirinden bağımsız icat edilmiş mekanizmalar değil, aynı soruna farklı derinliklerde verilmiş cevaplardır. Hepsi aynı soruyu sorar: en eski aktif okuyucu hangisi? Farklı olan, neyin okuyucu sayıldığıdır. Pratikteki ufuk sorunlarının önemli bir kısmı, operatörün okuyucu olarak düşünmediği bileşenlerden gelir: tüketicisi ortadan kalkmış bir replication slot, iki fazlı commit'in ortasında yarım bırakılmış bir PREPARE TRANSACTION, uzun süren bir yedek. Hiçbiri pg_stat_activity'de uzun süren bir sorgu olarak görünmez.

Cassandra'da yapı başka bir biçim alır. Bir tombstone'un geri kazanımını geciktiren şey bir okuyucu değil, silmeyi henüz almamış bir replikadır. Tombstone, her replika repair ile hizaya getirilmeden kaldırılırsa, silmeyi kaçırmış replika eski veriyi hâlâ tutar ve bir sonraki senkronizasyonda silinmiş kayıt yeniden ortaya çıkar. Buna data resurrection denir. Yapı yine aynıdır: geçersiz ilan edilmiş bir kayıt, bundan haberi olmayan son taraf da haberdar olana kadar geri kazanılamaz.

11. Geçici neden, kalıcı etki

Ufku geride tutan transaction kapandığında ufuk ilerler ve bir sonraki vacuum geçişi birikmiş ölü sürümleri temizler. Ama bu, tablonun diskte kapladığı alanı azaltmaz.

PostgreSQL'de vacuum geri kazandığı alanı işletim sistemine iade etmez; yalnızca tablonun sayfaları içinde yeniden kullanılabilir olarak işaretler. Dosya ancak tablonun sonundaki tamamen boş sayfalar kadar küçülebilir. Örnekteki tablo ölü sürümler temizlendikten sonra da yaklaşık 210 GB yer kaplar, ve sequential scan'ler o sayfaları okumaya devam eder. Alanı gerçekten geri almak için VACUUM FULL (tabloyu yeniden yazar ve baştan sona bir ACCESS EXCLUSIVE kilit tutar) ya da pg_repack gibi bir araç gerekir. pg_repack tabloyu online olarak yeniden yazar ve exclusive kilidi yalnızca başta ve sonda kısa süreliğine alır; karşılığında tablo ve indekslerinin boyutunun yaklaşık iki katı boş disk alanı ister.

Etki tabloyla da sınırlı kalmaz:

• İndeksler ölü sürümlere işaret eden girdilerle büyür, ve aynı sorgu daha çok sayfa okur.
• HOT (heap-only tuple) güncellemeleri seyrekleşir. Sayfalarda boş alan kalmadığında güncellemeler indeksleri de yeniden yazmak zorunda kalır, ve büyüme hızlanır.
• Freezing aynı ufka bağlıdır. Ufuk yeterince uzun süre yerinde kalırsa transaction ID wraparound koruması devreye girer. Önce agresif freezing geçişleri ve uyarılar gelir; en kötü durumda veritabanı yeni bir transaction ID gerektiren komutları reddeder. Salt okunur sorgular çalışmaya devam eder, ama yazmalar durur.

Dolayısıyla ufku izlemek, uzun süren sorguları izlemekle aynı şey değildir. Uzun okuma bittiğinde neden ortadan kalkar, ama etki kalır.

12. Teşhis ve önleme

PostgreSQL'de ufku neyin geride tuttuğunu bulmak için okuyucu sayılan her kaynağın ayrı ayrı kontrol edilmesi gerekir:

-- Açık transaction'lar
SELECT pid, usename, state, xact_start, age(backend_xmin) AS xmin_age
FROM pg_stat_activity
WHERE backend_xmin IS NOT NULL
ORDER BY age(backend_xmin) DESC;

-- Replication slot'lar (aktif olmayanlar dahil)
SELECT slot_name, active, xmin, catalog_xmin
FROM pg_replication_slots;

-- Prepared transaction'lar
SELECT gid, prepared, owner FROM pg_prepared_xacts;

-- Feedback gönderen standby'lar
SELECT application_name, backend_xmin FROM pg_stat_replication;

InnoDB'de karşılık gelen gösterge, SHOW ENGINE INNODB STATUS çıktısındaki History list length değeridir. Sürekli artan bir değer, purge'ün bir read view tarafından geride tutulduğu anlamına gelir.

Gözlenen ufku olan bir sistemde temel çare, okuyucuların ne kadar sürebileceğini sınırlamaktır; yani ilan edilen ufuk yaklaşımını okuyucu tarafında uygulamak. PostgreSQL'de ilgili ayarlar şunlardır:

• idle_in_transaction_session_timeout: boşta bekleyen açık transaction'ları belli bir süre sonra sonlandırır. Boşta bir transaction'ın ufku saatlerce çivilemesini doğrudan önler.
• transaction_timeout (PostgreSQL 17 ve sonrası): bir transaction'ın toplam süresini sınırlar.
• statement_timeout: tek bir ifadenin süresini sınırlar; boşta bekleyen transaction'ları kapsamaz.

Tüketicisi ortadan kalkmış replication slot'lar da izlenmeli ve silinmelidir; slot'lar tüketicileriyle birlikte kaldırılmaz.

Bu önlemlerin hepsi bedelin bir kısmını depolamadan okuyucuya aktarır. Burada da bedel ortadan kaldırılamaz; yalnızca kimin üstleneceğine önceden karar verilebilir.