Elde testi: DuckDB 2.0 alfasında trigger'ların çoğu henüz uygulanmamış ve satır başına maliyet 3 kat yüksek

Trigger matrisinin büyük bölümü henüz devrede değil

DuckDB hiçbir zaman trigger çıkarmadı ve Cyanoptera kod adlı 2.0 sürümü — şu an v2.0.0-alpha46057 — bunu değiştirecek. Yayın önizlemesi hem BEFORE hem AFTER trigger'larının FOR EACH ROW ve FOR EACH STATEMENT biçiminde sözünü veriyor. Genel alfa CLI'sini indirip her kombinasyonu INSERT, UPDATE ve DELETE karşılayan dev.to'da alexgeorgiov17 tarafından yayımlanan bir elde testi, sekizden beşinin henüz çalışmadığını bildiriyor.

Yazara göre sonuçlar şöyle:

• Her BEFORE ... FOR EACH ROW trigger'ı, olaydan bağımsız olarak aynı "not implemented" hatasıyla başarısız oluyor; bu, tümü olaya özgü bir eksiklikten ziyade BEFORE/ROW kombinasyonunun henüz inşa edilmediği izlenimini veriyor.
• AFTER ... FOR EACH ROW, INSERT ve DELETE için gerçek NEW ve OLD değerleriyle çalışıyor, ancak UPDATE kendi "not yet supported" mesajını döndürüyor.
• İfade seviyesindeki trigger'lar her iki zamanlamada ve üç olayın tamamında çalışıyor.

BEFORE satır seviyesi eksiği en göze çarpan olanı, çünkü insanların ilk başvurduğu kullanım bir satır yerleşmeden önce onu doğrulamak veya reddetmek.

Önizleme yazısında bahsedilmeyen kısıtlamalar

Test sırasında, önizleme yazısında hiç yer almayan iki ek sınırlama ortaya çıktı. Aynı tabloda bir FOR EACH STATEMENT trigger'ı ile bir FOR EACH ROW trigger'ı karıştırmak "not yet supported" hatası fırlatıyor. Ve DuckDB'nin kendi blog yazısında yazılan tam biçimdeki DROP TRIGGER trg_audit; bu sürümde bir sözdizimi hatası; bunun yerine DROP TRIGGER trg_audit ON t; gerekiyor. Yazarın da belirttiği gibi, bu bir okuyucunun dokümantasyondan kopyalayacağı ve çalıştığını göreceği ilk komut.

Satır seviyesi trigger'lar üç kat pahalı

Maliyeti ölçmek için yazar üç özdeş tablo kurdu ve her birine tek bir INSERT ... SELECT ile 500.000 satır ekledi; aynı makinede üç koşunun en hızlısını aldı ve yanına kararlı v1.5.7-dev2 sürümünü koydu. Trigger olmayan temel ekleme 0,073 saniye sürdü. NEW.id kaydeden bir AFTER INSERT FOR EACH ROW trigger'ı 0,217 saniye — 3,0 kat — aldı; koşular 0,22 ile 0,36 saniye arasında değişti. Bir transition table üzerinden tüm toplu işlemi kaydeden bir AFTER INSERT FOR EACH STATEMENT trigger'ı ise 0,095 saniye, yani 1,3 kat aldı.

İki trigger aynı mantıksal işi yapıyor — eklenen her satır için bir günlük satırı — ama satır seviyesindeki sürüm, tek bir küme işlemi yerine 500.000 kez trigger mekanizmasından geçiyor. Zamanlamaları ayrıca ölçülen her şey arasında en geniş aralığı gösterdi; hiç trigger yokken 0,073–0,080 saniyelik dar bir aralıkla karşılaştırıldığında, yazar bunu yarım milyon ayrı çağrının tek bir küme tabanlı ifadeden daha fazla makine gürültüsüne duyarlı olması olarak yorumluyor.

İfade seviyesindeki durum, transition table'ların belgelendiği gibi davranmasına bağlı; bu yüzden yazar doğruladı: 10.000 satırlık bir toplu ekleme, ifade trigger'ına 10.000 satırlık tek bir transition table veriyor ve 3 satırlık bir ekleme 3 satırlık bir tane. İfade başına tek çağrı, ifade seviyesindeki maliyeti toplu işlem boyutundan bağımsız olarak neredeyse düz tutuyor; pratik çıkarım, gerçekten satır başına mantık gerekmedikçe ifade seviyesi trigger'larına varsayılan olarak yönelmek — yoğun bir tablodaki denetim günlüğü trigger'ının hemen çarpacağı türden bir fark bu.

Özyineleme yakalanıyor, çökmüyor

Bir trigger'ın kendini tetiklemeye çalışmak — bir tabloya geri o tabloya ekleyen bir AFTER INSERT satır trigger'ı — bir kilitlenme veya stack overflow yerine düzgün bir döngü algılama hatası üretiyor. Yazar, bu sürümde "not yet supported" olarak işaretlenen her şey arasında, teslim edilmemiş olmasına rağmen gönderilmeye değer olanın bu olduğunu savunuyor; çünkü alternatif başarısızlık modu bir hata mesajından çok daha kötü.

Özyinelemeli CTE iddiası doğru çıkıyor

Sürüm ayrıca yeniden yazılmış bir özyinelemeli CTE motorunu duyuruyor ve v1.5.4 ile v2.0 önizlemesi arasında 4,90 saniyeden 0,12 saniyeye düşen bir erişilebilirlik kıyaslamasına atıfta bulunuyor. Yazarın ilk tekrar denemesi — 1.000.000 rastgele kenarlı 100.000 düğüm — ölçülebilir bir fark göstermedi; 1.5 sürümünde bile yaklaşık 0,09 saniyede çalıştı. Bu kusurlu bir test çıktı: yoğun bir rastgele grafik her motorda birkaç sıçramada yakınsıyor. Yeniden inşa edilen en kötü durum, 40.000 ardışık özyineleme adımı zorlayan 40.000 düğümlük bir zincir, v1.5.7-dev2'de 18,57 saniyede, alfa sürümünde ise 0,41 saniyede koştu — kabaca 45 kat daha hızlı. Kesin manşet sayısı doğrulanamadı, ama yön ve büyüklük düzeni bağımsız olarak tutuyor.

Ayrıca alfanın varsayılan depolama biçimi sürüm 68'den 69'a geçiyor; yazar bunu bu sürümde tek yönlü bir yol olarak tanımlıyor.

Neden önemli

Trigger'lar, denetim ağırlıklı iş yüklerini Postgres tarzı motorlardan taşıyan ekipler için sık görülen bir taşıma engelidir ve DuckDB'nin ilk denemesi açıkça eksik: BEFORE satır trigger'ı yok, satır seviyesi UPDATE trigger'ı yok, bir tabloda granülerlik karıştırma yok ve belgelenmiş DROP TRIGGER sözdizimi başarısız oluyor. Bunları benimsemeyi planlayan herkes, transition table'lı ifade seviyesi trigger'larını varsayılan olarak görmeli — satır seviyesine kıyasla neredeyse bedavalar — ve satır başına doğrulama mantığını BEFORE desteği gelene kadar ertelemeli. Eksikler en azından sessizce yanlış davranmak yerine açık hatalarla gürültülü biçimde başarısız oluyor ve özyinelemeli CTE yeniden yazımı derin özyinelemeli sorgular için gerçekten büyük bir kazanç gibi görünüyor. Ama bu bir alfa: planı önizleme yazısının vaadi değil, test edilen matrise göre yapın.