DuckDB 2.0 beschleunigt S3-Abfragen um das Dreifache
Why DuckDB 2.0 is faster
DuckDB 2.0 steht im Herbst an, und die Alpha ist bereits verfügbar. Der Autor testete die wichtigsten Neuerungen auf einem M5-Laptop und gegen S3. Asynchrones I/O beschleunigt S3-Abfragen um das Zwei- bis Dreifache, ohne dass sich die Abfrage ändert. Rekursive CTEs verarbeiten tiefe Parent-Child-Hierarchien deutlich schneller, und der VARIANT-Datentyp spart Speicher und beschleunigt Feldabfragen. Der Artikel liefert konkrete Messwerte und zeigt, wie sich Datenmodelle anpassen lassen.
Netzwerk und CPU sind gleichzeitig beschäftigt.
- scythmic_waves
Ich mag die Visualisierungen auch, aber der Text kommt mir stark nach LLM vor:
> Eine Einstellung steuert das,...
> Die Kosten richten sich jetzt nach den Zeilen, die man tatsächlich anfasst, nicht nach Runden mal Tabellengröße.
Usw.
Ich bekomme die Brain Scramblies [1], wenn ich versuche, diesen Schreibstil bei der Arbeit zu entziffern, deshalb hasse ich es, ihn woanders zu sehen. Entschuldigung, falls ich falsch liege. Aber wenn nicht, dann OP, benutze kein LLM, um für dich zu schreiben. Das ist gefährlich für die Gesundheit deiner Leser [2].
[1]: https://www.youtube.com/watch?v=ipUJq-odt5Q
[2]: https://discourse.haskell.org/t/how-to-keep-enjoying-program...
- stacktraceyo
Großartige Visualisierung. Nebenbemerkung: Ihre neue C++-Extension-API wird auch aus Sicht der Entwicklung / Verteilung dieser Extensions schneller sein.
- robertclaus
Ich war mit dem KI-Text einverstanden, bis ich zu der Tatsache kam, dass sie in 2.0 Trigger hinzugefügt haben und der Artikel entschied, das sei meh im Vergleich zur Optimierung von Workern für S3-Dateizugriff bei langsamen Verbindungen. Nein. Ich lese die Release Notes selbst.
- rumbledownunda
Werde es in meinem nächsten Jupyter Notebook ausprobieren.
- jiggawatts
Ich wünschte, mehr Datenbank-Engines würden ein Task-basiertes Design wie Umbra / CedarDB verwenden.
Die meisten DB-Engines da draußen scheinen immer noch eine „n-Threads“-Parallelität mit Exchange-Operationen und schlechtem Async-I/O-Management zu nutzen.
DuckDB verbessert sich in diesem Punkt, holt aber gewissermaßen F&E (und Implementierung!) auf, die mittlerweile Jahrzehnte alt ist.
Eine „rhetorische Herausforderung“, die ich Softwareentwicklern, die an solchen Systemen arbeiten, gerne stelle, ist folgende: Wenn ich Ihnen einen Computer mit 1.024 Kernen und passender Netzwerk- und Speicherbandbreite gebe – aber mit erheblicher Latenz –, könnten Sie ein solches System mit einer Abfrage zu 100 % auslasten?
Die Antwort für fast alle Software ist „nein“.
Zum Beispiel erreicht SQL Server bei einer einzelnen Abfrage maximal 64 Hardware-Threads: https://learn.microsoft.com/en-us/sql/database-engine/config...
GPU-Codes beginnen, dorthin zu gelangen, aber CPU-Codes sind an dieser Frontier der Informatik weit hinterher.
Es betrifft nicht nur Datenbanken! Kannst du eine Datei parallel (de)komprimieren? Ihren Hash parallel verifizieren? Von Speicher mit CPU- und I/O-Task-Parallelität hoch- und herunterladen? Kannst du all diese Operationen überlappen, sodass nichts jemals auf etwas anderes wartet, worauf es nicht warten muss?
Das ist wichtig! Ich habe einige Tests mit Bioinformatik-Codes durchgeführt und festgestellt, dass die meisten in Teergruben stecken blieben. Viele konnten nicht auf moderne SSDs mit Millionen von IOPS oder moderne Netzwerke mit Hunderten von Gigabit Durchsatz skalieren, egal wie viele CPU-Kerne man ihnen zuwarf.
PS: AMDs EPYC 9006 Prozessoren der Zen-6-Ära werden 51 […]