DuckDB ortak yaratıcısı: “Yeni bir mimariye ihtiyaç olduğu açıktı”

Hannes Mühleisen, DuckDB'nin ortak yaratıcısı ve DuckDB Labs'ın CEO'sudur. Mark Raasveldt ile birlikte DuckDB'yi ilk olarak Amsterdam'daki Centrum Wiskunde & Informatica'da (CWI) bir araştırma projesi olarak başlattı.

Golo: Hannes, DuckDB'nin ortak yaratıcılarından biri ve DuckDB Labs'ın kurucu ortağısınız. DuckDB 1.0 sürümü 2024 yazında yayınlandığında, Haberler için bunun hakkında rapor verdim ve o zamandan bu yana çok şey oldu. Ayrıntılara girmeden önce, baştan başlayayım: DuckDB'nin kökleri, sizin ve Mark Raasveldt'in yıllarca dahili veritabanları üzerinde çalıştığınız Amsterdam'daki CWI'deki araştırmanıza dayanmaktadır. Her ikinizin de dünyanın gerçekten başka bir veritabanına ihtiyaç duyduğuna karar verdiği an (veya aralık) neydi ve başlangıçta bunun ne olmasını istiyordunuz?

– Hannes: O zamanlar büyük anket verilerini analiz etmek zorunda olan istatistikçilerle yakın işbirliği içinde çalışıyorduk. Veritabanı teknolojisine ihtiyaç duydukları bizim için açıktı! Ama biz bunu önerdiğimizde aslında klasik anlamda bir veri tabanı istemediklerini söylediler. Örneğin Docker'dan önce uzman olmadan yerel olarak bir veritabanı kurmak kolay değildi. Ayrıca veritabanının durumunu başka biriyle kolayca paylaşamazsınız.

Yeni bir mimariye, yerleşik bir analitik veri tabanı sistemine ihtiyaç olduğu açıktı. O zaman yoktu bile. Tamamen yeni bir geliştirmeye ihtiyacımız olduğu kısa sürede anlaşıldı: modern sistem mimarisiyle entegre dağıtım modeline uyarlanmış temiz bir tasarım.

2018 yazında bunu gerçeğe dönüştürmeye karar verdik ve DuckDB'yi uygulamaya başladık.

“SQLite for Analytics” terimi yıllardır DuckDB ile ilişkilendirilmektedir. Sadece üç kelimeyle pek çok şeyin özüne iniyor ama aynı zamanda indirgeyici de görünebilir. Şu anki bakış açınızdan bu çekimin ne kadar doğru olduğunu düşünüyorsunuz ve nerede yetersiz kalıyor?

– Hannes: “SQLite for Analytics” projenin ilk beş yılı için uygun bir tanımdı. Zamanla Parquet, JSON veya Iceberg gibi neredeyse tüm dosya formatlarıyla ve S3 API gibi birçok popüler depolama seçeneğiyle çalışmanıza olanak tanıyan güçlü bir uzantı mekanizması ekledik. Bu nedenle DuckDB'yi genel amaçlı bir veri aracı olarak adlandırmaya başladık.

Bu, orijinal açıklamaya göre daha az akılda kalıcı olabilir ancak sistemin artık çok daha çok yönlü olduğunu gösteriyor. Analiz için SQLite'a ihtiyacınız varsa bunun için DuckDB'yi kullanmaya devam edebilirsiniz.

Büyük Verinin Ötesinde

Uzun zamandır dağıtılmış sistemlerin analitik iş yüklerinin büyük çoğunluğu için fazlasıyla güçlü olduğunu ve tek bir modern makinenin endüstrinin genel olarak varsaydığından çok daha fazlasını yapabileceğini savundunuz. Bu, DuckDB'yi Apache Spark'a modern bir alternatif olarak konumlandırdığım ayrıntılı bir iX testinde de ele aldığım bir konu. Bu tezi kendi sözlerinizle yazmak ister misiniz? Peki, sorunlarını hafife aldığınız için sizi hemen eleştiren insanlara nasıl tepki verirsiniz?

– Hannes: Benim iddiam üç temele dayanıyor. Birincisi, donanım geliştirmede büyük ilerlemeler kaydedilmiştir ve modern bilgisayarlar şaşırtıcı derecede güçlüdür. Günümüzde güçlü bir dizüstü bilgisayar, bir düzine hızlı CPU çekirdeği, onlarca gigabayt bellek ve terabaytlarca depolama alanına sahip hızlı bir SSD ile birlikte gelir. Bir sunucu kolaylıkla bu miktarın on katını veya daha fazlasını sunabilir.

İkincisi, veritabanı mimarisi alanı, büyük verilerin ortaya çıktığı 2010 yılından bu yana önemli ölçüde gelişti. Sütun tabanlı depolama, vektör sorgu işleme, eşzamanlılık ve eşzamanlılık kontrolündeki bulgulardan yararlanabildik. RAM'i aşan veri hacimleri için sıkıştırma ve operatörler gibi konularda da kendi araştırmalarımızı yaptık.

Üçüncüsü, çoğu insanın dikkate almadığı şey, bir kuruluş petabaytlarca veriye sahip olsa bile, tüm verileri tek bir sorguda işlemenin asla gerekli olmadığıdır. Artık bunun kesin bir kanıtı var: Son yıllarda hem Snowflake hem de Redshift, gerçek dünyadaki iş yüklerini anlamak için hazine hazineleri olan kullanıcı sorgu örnekleri ve istatistikleri yayınladı. Fivetran'dan George Fraser bunun mükemmel bir analizini yaptı ve Snowflake ve Redshift sorguları arasında bile 99,9'uncu yüzdelik dilimin 300 GB civarında tarama yaptığını, dolayısıyla tek bir düğümde kolayca çalışabileceğini gösterdi.

Performans DuckDB'nin en şaşırtıcı yönlerinden biridir: İlk benimseyenlerin çoğu ilk deneyimlerini “bu doğru olamaz, sonucu tekrar kontrol edeyim” sözleriyle anlatıyor. Sizce hangi mimari kararlar en önemli ve hangileri dışarıdan bakanlar için açık değil?

– Hannes: Uygulama, operasyon ve performansta çeşitli ek yük türlerini ortadan kaldıran tek düğümlü bir mimarinin seçilmesinden zaten bahsetmiştik. Ancak önemsiz olmayan bazı mimari kararlar da var.

JIT derlemesi yerine vektör yürütmeyi seçtik çünkü analitik iş yükleri için mükemmel ve uzun vadede bakımı çok daha kolay. GPU'lar veya AI hızlandırıcılar gibi egzotik donanımlar kullanmadık, ancak tüm enerjimizi CPU açısından en verimli algoritmaları yazmaya harcadık. Son olarak, bu algoritmaları uygularken içsel SIMD'yi (manuel olarak formüle edilmiş vektör komutları) kullanmaktan kasıtlı olarak kaçındık. Bunun yerine skaler kod yazdık ve derleyicinin otomatik vektörleştirmeyi yapmasına izin verdik. Sonuç, son derece taşınabilir ancak güçlü bir koddur.

Ayrıca, önceki soruda da tartışıldığı gibi, DuckDB'ye pek çok güncel araştırma dahil edilmiştir. RAM'i aşan veri hacimlerinin diske aktarılarak işlenmesi DuckDB performansında önemli bir faktördür. Çoğu modern veritabanı sistemi diske geçebilir, ancak bunu yaptıklarında performansta bir çökme meydana gelir. DuckDB, tüm bunları çok daha zarif bir şekilde ele almak için modern flash tabanlı depolamayı kullanıyor; kullanıcılar genellikle sorgularının diske atıldığını neredeyse hiç fark etmiyor.

Ekosistem

DuckDB'nin Python ve R topluluklarına, Node.js'ye, her türlü araç ve not defterine erişimi dikkat çekicidir. Bu ekosistem stratejisi başından beri bilinçli bir seçim miydi, yoksa insanların DuckDB'yi iş akışlarına dahil etmeleri nedeniyle mi ortaya çıktı?

– Hannes: Elbette kullanıcılarla bulundukları yerde tanışmalısınız. Başlangıçta DuckDB'nin veri bilimi iş yükleri için kullanılacağını tahmin etmiştik ve bu, ilk müşteri seçimimizi yönlendirdi. Açıkçası bir komut satırı istemcisine ihtiyacımız vardı. Dil açısından Python zaten çok güçlüydü ve R topluluğuyla güçlü bağlarımız vardı, bu yüzden önce bu istemcileri uygulamaya karar verdik.

Kısa süre sonra Node.js onu takip etti. DuckDB büyüdükçe topluluk müşterileri bağımsız olarak geliştirmeye başladı. Bu, çekirdek ekibin çalışmasını on beş farklı faktöre yatırmadan önce benimsenmeyi izlememize olanak sağladı. Örneğin DuckDB Go sürücüsü ilk olarak daha sonra DuckDB Vakfı'na kodla katkıda bulunacak olan Marc Boeker tarafından uygulandı.

Uzatma mekanizması oldukça sessiz fakat son derece önemli bir tasarım kararı gibi görünüyor. DuckDB'nin oluşturulmadığı formatları okumasına, nesne depolarıyla çalışmasına ve hatta diğer veritabanlarıyla iletişim kurmasına olanak tanır. Çekirdeğe ait olan ile uzantıda en iyi olan arasındaki çizgi hakkında ne düşünüyorsunuz?

– Hannes: DuckDB'nin kaynak kısıtlı ortamlarda kullanıldığını görüyoruz: tek kartlı bilgisayarlar, tarayıcı sekmeleri, sınırlı belleğe sahip konteynerler. Bu kullanımı mümkün kılmak için DuckDB'nin çekirdeğini küçük tutmak ve yalnızca temel öğeleri dahil etmek istiyoruz: SQL ayrıştırıcı, veritabanı motoru, depolama motoru, CSV okuyucu ve uzantı mekanizması. Parke oynatıcı ve hatta HTTPS desteği gibi diğer özelliklerin çoğu uzantı olarak mevcuttur.

Bu güçlü uzantı mekanizmasının güzel bir yan etkisi de topluluğumuzun kendi uzantılarını oluşturabilmesidir. DuckDB için şu anda her biri sisteme yeni işlevler getiren ve tek hatla kurulabilen 180'den fazla topluluk uzantısı bulunmaktadır.