ZVec'te optimize() Çökmeden Kurtarılan Verileri Sessizce Siliyor
ZVec'te optimize() çağrısı, çökmeden WAL ile kurtarılan verileri sessizce silebiliyor. Testler, riskin nedenini ve güvenli kurtarma yolunu ortaya koyuyor.
Alibaba'nın geliştirdiği, Python'a gömülü çalışan vektör veritabanı ZVec (v0.5.1) üzerinde yapılan kill-9 testleri, WAL (write-ahead log) tabanlı kurtarma mekanizmasının beklendiği gibi çalıştığını gösterdi: 551 belge eklenip process os._exit(1) ile öldürüldüğünde, yeniden açılan koleksiyon tüm belgeleri eksiksiz geri getirdi. Ancak stats() çağrısının döndürdüğü index_completeness: 0.0 değeri ilk bakışta bir bozulma sinyali gibi görünse de, aslında hem çökmüş hem hiç çökmemiş koleksiyonlarda görülen normal bir varsayılan durum olduğu ve sorgu sonuçlarını hiçbir şekilde etkilemediği ortaya çıktı.
Asıl risk, bu göstergeyi 1.0'a çekmek için çağrılan optimize() fonksiyonunda gizli. Çökme sonrası WAL üzerinden kurtarılmış bir koleksiyonda optimize() çalıştırıldığında, kurtarılan belgeler hiçbir hata veya uyarı vermeden index yeniden oluşturma sürecinin dışında bırakılıyor; kayıp yalnızca koleksiyon ayrı bir process'te yeniden açılıp doğrulandığında fark ediliyor. Belirleyici faktör flush() durumu değil, koleksiyonun daha önce çökme geçirip geçirmediği — çökmemiş, flush edilmemiş veriler optimize() altında güvende kalıyor.
Orkestrasyon katmanlarında (Temporal Activity'leri gibi) durum yönetimi için gömülü vektör depoları değerlendiren mühendisler açısından bu bulgu, kurtarma akışının nasıl tasarlanması gerektiğini doğrudan etkiliyor: index_completeness: 0.0 tehlike işareti değil, optimize() ise çökme geçmişi taşıyan koleksiyonlar için güvenli bir işlem değil. Önerilen çözüm, çökmeden kurtarılan belgeleri optimize() çağrılmadan önce fetch edip temiz, çökme geçmişi olmayan yeni bir koleksiyona yeniden eklemek.