DuckDB v2.0 beschleunigt S3-Queries um das 3,7-fache

Asynchronous I/O in DuckDB: Work, Thread, Work

DuckDB v2.0 beschleunigt S3-Queries um das 3,7-fache

Mit der für Herbst 2026 geplanten Version 2.0 führt DuckDB asynchrone Lesevorgänge für Parquet- und CSV-Dateien ein. In Benchmarks auf TPC-H SF100 mit Daten in S3 und einer EC2-Instanz (r7i.16xlarge) verkürzte sich die Laufzeit von Query 6 von 8,23 Sekunden (v1.5.5) auf 2,84 Sekunden (v2.0.0-dev) – eine fast dreifache Beschleunigung. Durch zusätzliche Tuning-Optionen wie eine begrenzte Read-Ahead-Tiefe und optimierte HTTP-Einstellungen ließ sich die Ausführungszeit weiter auf 2,23 Sekunden senken, was einer 3,7-fachen Beschleunigung gegenüber der stabilen Version entspricht. Die asynchrone I/O-Architektur nutzt zwei Thread-Pools und eine Read-Ahead-Queue, um die Netzwerkbandbreite besser auszulasten und Latenzzeiten zu verbergen.

Die asynchrone E/A sollte den größten Effekt haben, wenn die Latenz synchroner Anfragen uns daran hindert, die verfügbare Remote-Bandbreite zu nutzen.
  1. diarrhea

    Funktioniert es gut, wenn der Worker-Pool so viele Threads wie Kerne hat, zusammen mit dem Async-Pool? Das ist im Grunde von Natur aus überbucht.

    Ich habe einmal ein System gebaut, das (in Rust) einen Rayon-Worker-Threadpool mit 4 Threads und einen Tokio-Async-Pool mit 2 (Multithreaded-Runtime) hatte. Auf einem System mit 6 vCPUs. Das funktionierte am Ende einwandfrei. Tokio wurde nicht ausgehungert und verarbeitete Netzwerkanfragen mit geringer Latenz.

    Ein Unterschied ist, dass DuckDB ein reiner Netzwerk-Client ist. Wenn einer seiner Async-Threads ausgehungert wird, ist das nicht das Ende der Welt (z.B. tötet k8s deinen Pod nicht, weil er nicht auf Health Checks antwortet).

  2. NorthSouthNorth

    Erlauben die CSV-Dateien in Anführungszeichen gesetzte Zeilenumbrüche? Wenn ja, was ist der Trick, um nicht die ganze Datei prüfen zu müssen, um herauszufinden, ob ein Zeilenumbruch in Anführungszeichen steht oder ein Datensatztrenner ist, wenn man sie mitten in einem Async-Thread liest?

  3. bburnett44

    512 GB RAM für eine 22 GB große Remote-Datei zu verwenden, fühlt sich für einen Benchmark schon etwas seltsam an, aber vielleicht konnten sie ohne viel Speicher keine große Anzahl an Kernen bekommen?

Mehr von diesem Tag

2026-08-16