DuckDB 2.0 alpha, S3 okumalarını 3 kata kadar hızlandırıyor ve recursive CTE'leri yeniden inşa ediyor

DuckDB 2.0, bu sonbahar planlanan sürümden önce alpha test aşamasına girdi ve MotherDuck tarafından yayımlanan benchmark'lar, güncellemenin veritabanı motoru geliştirenler değil de veri tabloları ve pipeline'lar kuranlar için gerçek hız kazanımları getirdiğini gösteriyor — özellikle veri object storage üzerinde duruyorsa.

Async I/O, sorgu değişikliği olmadan S3 sorgularını hızlandırıyor

MotherDuck yazısına göre en büyük kazanım, kullanıcıdan hiçbir şey talep etmeyen asenkron I/O: aynı sorgu sadece daha hızlı çalışıyor.

Test vakası, AWS S3 üzerindeki 2.2 GB'lık bir Parquet dosyası üzerinden türüne göre gruplanmış oyları sayıyordu — Stack Overflow'un oylar veri seti, 2.268 row group'a bölünmüş 228 milyon satır — ve dört sütundan yalnızca birini, yaklaşık 230 MB okuyordu. DuckDB 1.5.5'in 18.8 saniyeye ihtiyacı vardı; 2.0 alpha 7.7 saniyede bitirdi.

Yazı, bu farkın ardındaki mekanizmayı açıklıyor. 1.5.5'te 18 worker thread'in her biri her aşamayı kendi başına hallediyordu: byte'ları çek, ağda bekle, Parquet'i decode et, tekrarla. Beklerken CPU boş duruyordu; decode ederken indirilen bir şey yoktu; ve aynı anda en fazla 18 indirme çalışıyordu. Sürüm 2.0 işi ikiye bölüyor: özel bir thread havuzu yalnızca indirme yapıyor ve bir buffer'da onlarca row group'u havada tutarken, worker'lar decode etmeye odaklanıyor ve her zaman bekleyen veri buluyor. Ağ ve CPU aynı anda meşgul kalıyor.

Tek bir ayar, read_ahead_depth, indirme havuzunun ne kadar ileriye fetch yapabileceğini kontrol ediyor. Varsayılanı -1, yani otomatik ve thread sayısından boyutlandırılıyor; dolayısıyla bu davranış etkin olarak geliyor. 0'a ayarlamak eski davranışı geri getiriyor.

Diğer ölçümler de aynı yönü gösteriyor. Toplam 13.6 GB'lık 23 büyük Parquet dosyası üzerinden tek bir sütun okuma 11.8 saniyeden 3.9 saniyeye düştü ve 1.7 GB'lık düz bir CSV 116 saniyeden 55 saniyeye indi. Yaklaşık 1 MB'lık otuz küçük Parquet dosyası ise ancak iyileşti, 3.7'den 3.3 saniyeye indi, çünkü oradaki maliyet dosya başına gidiş dönüşler — önce bir footer okuması, ardından bir veri okuması — ve prefetching bunları ortadan kaldıramıyor. MotherDuck, binlerce 1 MB'lık dosyadan oluşan bir lake'in hâlâ kötü bir yerleşim olduğunu ve 2.0'un bunu kurtarmadığını belirtiyor.

Tüm rakamlar tek bir makineden, bir M5 laptop'tan geldi ve veriyi us-east-1'e ev interneti bağlantısı üzerinden çekti; bu da her iki sürümü de kabaca eşit şekilde yavaşlattı. Yazar kendi benchmark'larınızı çalıştırmanızı öneriyor ve bulut compute'dan daha hızlı mutlak süreler bekliyor.

Recursive CTE'ler tabloyu her turda değil bir kez okuyor

DuckDB ekibi ayrıca recursive CTE motorunu yeniden inşa etti ve yazıya göre graf erişilebilirliği (graph reachability) iş yüklerinde 40 kat iyileşme iddia ediyor.

Recursive CTE fiilen bir tablo üzerindeki döngüdür, derinlik seviyesi başına bir yineleme. Organizasyon şemaları, klasör ağaçları, ürün ağaçları (bills of materials), yanıt zincirleri, veri kökeni (data lineage) ve git geçmişi hep bu ebeveyn/çocuk biçimini alır ve derinlik çok değişkendir: bir organizasyon şeması sekiz seviye çalışabilirken, bir git geçmişi on binlerce seviyeye uzanır.

1.5'te sorun bu derinlikti. Her tur geri dönüp bir sonraki seviyeyi bulmak için tablonun tamamını yeniden okuyordu; dolayısıyla sekiz seviye sekiz tam geçiş, on binlerce seviye ise aynı veri üzerinden on binlerce geçiş demekti. 2.0'da tablo bir kez okunuyor, ebeveyn sütunu üzerinde bir arama yapısı bir kez kuruluyor ve her tur yalnızca önceki turda keşfedilen satırları sorguluyor. Maliyet artık bir sorgunun gerçekten dokunduğu satırları takip ediyor, tur sayısı çarpı tablo boyutunu değil.

Neden önemli

DuckDB, yerel analiz ve S3 üzerindeki Parquet lake'lerini doğrudan sorgulayan pipeline'lar için yaygın bir motor haline geldi. Uzaktan okumalarda varsayılan olarak teslim edilen ve sıfır sorgu yeniden yazımı gerektirmeyen iki ila üç katlık iyileşme, doğrudan daha kısa pipeline çalışmaları anlamına geliyor.

Recursive CTE yeniden yazımı, graf biçimli sorunların tüm bir sınıfını — köken takibi, hiyerarşi genişletme, commit geçmişi analizi — pratik olmaktan sıradan hale getiriyor.

Alpha ayrıca sınırların nerede olduğunu gösteriyor: kazanımlar verinizin nasıl şekillendirildiğine ve modellendiğine bağlı ve ne kadar prefetching yaparsanız yapın, küçük dosyalardan oluşan bir lake'i kurtaramıyor. Nihai sürüm bu sonbahar çıkacakken, pipeline kurucuları artık kendi iş yüklerini alpha üzerinde, o piyasaya çıkmadan önce test etmek için bir pencereye sahip.