DuckDB 2.0 Alpha ermöglicht schnellere S3-Lesevorgänge und rekursive Abfragen

Das DuckDB-Team hat die Alpha-Version von DuckDB 2.0 veröffentlicht, was einen bedeutenden Schritt nach vorne bei der Leistung für analytische Workloads darstellt. Dieses Update konzentriert sich auf drei wesentliche architektonische Verbesserungen: asynchrones Input/Output für Cloud-Speicher, eine neu geschriebene Engine für rekursive Common Table Expressions (CTEs) und einen neuen nativen Datentyp zur Verarbeitung semi-strukturierter Daten. Diese Änderungen zielen darauf ab, Abfragezeiten und Speicherkosten für Ingenieure zu reduzieren, die Datenpipelines auf Laptops oder in der Cloud erstellen.

Was ist passiert

Der unmittelbarste Leistungsgewinn ergibt sich aus der Art und Weise, wie DuckDB 2.0 remote gespeicherte Daten verarbeitet, z. B. auf Amazon S3. In früheren Versionen mussten Worker-Threads zwischen dem Herunterladen von Datenblöcken und deren Verarbeitung wechseln, wodurch CPU-Ressourcen während der Netzwerk-Wartezeiten ungenutzt blieben. Die neue Version führt einen separaten Thread-Pool ein, der ausschließlich dem vorzeitigen Herunterladen von Daten dient. Dies ermöglicht es dem System, sowohl die Netzwerkverbindung als auch die CPU gleichzeitig auszulasten, was die Gesamtzeit zum Lesen großer Parquet- oder CSV-Dateien aus dem Objektspeicher erheblich verkürzt.

Neben der reinen Geschwindigkeit adressiert das Release komplexe Abfragemuster, die hierarchische Daten beinhalten. Rekursive Common Table Expressions (CTEs), die häufig zur Durchlaufung von Organigrammen oder Abhängigkeitsbäumen verwendet werden, wurden vollständig überarbeitet. Zuvor erforderte jede Rekursionsebene einen vollständigen Scan der Quelltabelle, was tiefe Hierarchien prohibitiv langsam machte. Die neue Engine liest die Tabelle nur einmal und erstellt eine interne Lookup-Struktur, sodass sie direkt zu den relevanten Zeilen für jede folgende Rekursionsebene springen kann. Diese Änderung verwandelt Vorgänge, die zuvor Sekunden oder Minuten dauerten, in Aufgaben mit Sub-Sekunden-Laufzeit.

Die dritte große Neuerung ist der VARIANT-Datentyp, der entwickelt wurde, um JSON und andere semi-strukturierte Formate effizienter zu handhaben. Anstatt JSON als einfachen Textstring zu speichern, analysiert DuckDB 2.0 die Daten während der Schreibvorgänge. Es identifiziert Felder, die konsistent mit demselben Datentyp in den meisten Zeilen erscheinen, und speichert sie als separate, optimierte Spalten. Nur unregelmäßige oder seltene Felder verbleiben in einem Binär-Blob. Dieser Prozess, bekannt als Shredding, reduziert den Speicherplatzbedarf und beschleunigt Abfragen, die diese konsistenten Felder filtern oder aggregieren.

Wichtige Details

• Asynchrones I/O verbessert die S3-Lese-Geschwindigkeit um das Zwei- bis Dreifache, ohne dass Änderungen an bestehenden SQL-Abfragen erforderlich sind.
• Die Einstellung read_ahead_depth steuert, wie viele Row Groups im Voraus abgerufen werden; standardmäßig erfolgt die Größenbestimmung automatisch basierend auf der Anzahl der Threads.
• Die Leistung rekursiver CTEs verbesserte sich in Tests dramatisch, von bis zu 16 Sekunden auf 0,10 Sekunden für die Durchlaufung einer Git-Historie mit 20.000 Commits.
• Der neue VARIANT-Typ reduziert die Speicheranforderungen um ungefähr das 2,7-Fache im Vergleich zur Speicherung von JSON als Textstrings.
• Abfragen, die auf geshreddete VARIANT-Felder filtern, laufen etwa sechsmal schneller als das Parsen von JSON-Text und nähern sich der Geschwindigkeit nativer typisierter Spalten.
• Listenoperationen innerhalb von VARIANT-Daten sind derzeit langsamer als der Feldzugriff, was darauf hindeutet, dass Benutzer das Casting von Listen in heißen Abfrageläufen vermeiden sollten.

Hintergrund

Um diese Verbesserungen zu verstehen, hilft es zu wissen, wie analytische Datenbanken typischerweise Daten verarbeiten. Traditionelle Engines behandeln Netzwerklatenz und CPU-Verarbeitung oft als sequentielle Schritte. Beim Lesen aus dem Cloud-Speicher muss die Datenbank warten, bis die Daten eintreffen, bevor sie mit der Berechnung beginnen kann. Asynchrones I/O entkoppelt diese Aufgaben und ermöglicht es der Datenbank, Daten vorab zu laden, während sie gleichzeitig bereits abgerufene Blöcke verarbeitet. Dies ähnelt der Funktionsweise eines Videoplayers, der kommende Szenen puffert, während Sie die aktuelle Szene ansehen.

Rekursive CTEs sind ein SQL-Feature zur Abfrage hierarchischer Strukturen, wie z. B. Mitarbeiterberichtslinien oder Verzeichnisbaumstrukturen. In älteren Implementierungen scannte die Datenbank wiederholt die gesamte Tabelle, um die nächste Ebene der Hierarchie zu finden. War ein Baum zehn Ebenen tief, wurde die Tabelle zehnmal gescannt. Der neue Ansatz erstellt nach dem ersten Scan eine indexähnliche Struktur im Speicher, sodass die Datenbank Kind-Datensätze sofort lokalisieren kann, ohne die Quelldaten erneut lesen zu müssen. Dies verschiebt die Kosten davon, proportional zur Tiefe des Baums multipliziert mit der Tabellengröße zu sein, hin zu Kosten, die nur proportional zur Anzahl der tatsächlich besuchten Zeilen sind.

Warum es wichtig ist

Für Teams, die ihre eigene Dateninfrastruktur betreiben, reduzieren diese Änderungen die Notwendigkeit spezialisierter Tools. Zuvor könnten tiefgreifende hierarchische Abfragen erfordert haben, Daten in eine Graphdatenbank zu exportieren oder benutzerdefinierten Anwendungscode zur Verwaltung der Traversierung zu schreiben. Mit DuckDB 2.0 werden diese Operationen innerhalb von Standard-SQL durchführbar, was den Technologie-Stack vereinfacht. Ebenso bedeutet die verbesserte S3-Leistung, dass die Aufbewahrung von Daten im kostengünstigen Objektspeicher für interaktive Analysen viabler wird, was den Druck verringert, alles in teuren Hochleistungs-Blockspeicher zu migrieren.

Der VARIANT-Typ bietet einen praktischen Mittelweg für die Handhabung chaotischer Realwelt-Daten. Ingenieure kämpfen oft mit der Wahl zwischen starren Schemas, die brechen, wenn sich Datenformate ändern, und flexiblen JSON-Strings, die langsam abzufragen sind. Indem DuckDB 2.0 die konsistenten Teile von JSON-Daten automatisch optimiert, während es Flexibilität für den Rest bewahrt, können Teams semi-strukturierte Logs oder Event-Daten aufnehmen, ohne die Abfrageleistung zu opfern. Dies reduziert den Engineering-Aufwand, der erforderlich ist, um Daten vor der Analyse zu bereinigen und zu modellieren.

Allerdings bringen diese Vorteile Modellierungsverantwortlichkeiten mit sich. Die Leistung von VARIANT hängt stark von der Datenkonsistenz ab. Wenn ein Feld manchmal eine Zahl und manchmal einen String enthält, kann es nicht effektiv geshreddet werden und verbleibt im langsameren Binärspeicher. Teams müssen sicherstellen, dass ihre Datenpipelines konsistente Typen für Schlüssel-Felder erzeugen, um die Leistungsgewinne zu realisieren. Darüber hinaus hilft asynchrones I/O zwar bei großen Dateien, löst aber nicht die inhärente Latenz beim Zugriff auf Tausende kleiner Dateien, was die Best Practice unterstreicht, kleine Datensätze in größeren Partitionen zusammenzufassen.

Was Sie tun können

• Testen Sie die Alpha-Version auf Ihrem lokalen Rechner mithilfe des bereitgestellten Installationsskripts, um Ihre spezifischen Workloads zu benchmarken.
• Überprüfen Sie Ihre S3-basierten Abfragen, um sicherzustellen, dass Sie große Parquet-Dateien lesen, anstelle vieler kleiner Dateien, um die Vorteile von asynchronem I/O zu maximieren.
• Identifizieren Sie rekursive Abfragen in Ihrer Codebasis, wie z. B. Organigramm-Traversierungen oder Stücklisten-Erweiterungen, und führen Sie sie erneut aus, um die neue Leistungsbaseline zu messen.
• Prüfen Sie Ihre JSON-lastigen Tabellen auf Felder mit konsistenten Datentypen und erwägen Sie, diese in den VARIANT-Typ zu konvertieren, um Speicherplatz zu sparen und die Filtergeschwindigkeit zu verbessern.
• Vermeiden Sie das Casting von VARIANT-Listen in Arrays in leistungs-kritischen Abfragen, bis zukünftige Updates diese Operation optimieren.
• Überwachen Sie die Einstellung read_ahead_depth, wenn Sie Speicherdruck erfahren, obwohl die automatische Standardkonfiguration für die meisten Umgebungen geeignet sein sollte.