2024-12-06

DuckDB: TPC-H SF100 auf Mobiltelefonen

Gábor Szárnyas, Laurens Kuiper, Hannes Mühleisen

Vor ein paar Wochen haben wir eine Reihe von Experimenten gestartet, um zwei einfache Fragen zu beantworten:

1. Kann DuckDB die TPC-H-Queries auf dem SF100-Datensatz auf einem neuen Smartphone abschließen?
2. Und wenn ja: Schafft DuckDB einen Lauf in unter 400 Sekunden, also schneller als das System in dem Forschungspaper, das vektorisierte Query-Verarbeitung ursprünglich eingeführt hat?

Diese Fragen führten uns auf eine interessante Quest. Unterwegs hatten wir viel Spaß und lernten den Unterschied zwischen einem Cold Run und einem wirklich kalten Run. Lesen Sie weiter.

Ein Lied von Trockeneis und Feuer

Unser erster Versuch galt einem iPhone, genauer einem iPhone 16 Pro. Dieses Telefon hat 8 GB Speicher und eine 6-Kern-CPU mit 2 Performance-Kernen (4,05 GHz) und 4 Efficiency-Kernen (2,42 GHz).

Wir haben die Anwendung mit dem DuckDB-Swift-Client umgesetzt und den Benchmark auf das Telefon geladen – alle 30 GB. Schnell zeigte sich: Das iPhone kann die Last problemlos fahren – außer dass es sich während der Last aufheizte. Daraufhin drosselte das Telefon thermisch und senkte die CPU-Taktung. DuckDB brauchte deshalb 615,1 Sekunden. Nicht schlecht, aber nicht genug für unser Ziel.

Die Ergebnisse brachten uns auf die Idee: Was, wenn wir die Kühlung des Telefons verbessern? Wir kauften eine Kiste Trockeneis, das unter −50 °C hat, und legten das Telefon für die Dauer der Experimente hinein.

Das half viel: DuckDB war in 478,2 Sekunden fertig. Über 20 % Verbesserung – aber unter 400 Sekunden kamen wir immer noch nicht.

Träumen Androiden von elektrischen Enten?

Als Nächstes griffen wir zum Samsung Galaxy S24 Ultra mit Android 14. Das Gerät steckt voller interessanter Hardware. Erstens: eine 8-Kern-CPU mit 4 Kerntypen (1×3,39 GHz, 3×3,10 GHz, 2×2,90 GHz und 2×2,20 GHz). Zweitens: viel RAM – genau 12 GB. Und drittens: ein Kühlsystem mit Vapor Chamber für bessere Wärmeableitung.

Wir haben DuckDB im Termux-Terminalemulator ausgeführt. Den DuckDB-CLI-Client haben wir nach den Android-Build-Anweisungen aus dem Quellcode gebaut und die Experimente auf der Kommandozeile gefahren.

Am Ende war es nicht mal knapp. Das Android-Telefon schloss den Benchmark in 235,0 Sekunden ab und übertraf unsere Baseline um rund 40 %.

Nie ein bewölkter Tag

Die Ergebnisse brachten uns auf die nächste Frage: Wie schlagen sie sich gegen Cloud-Server? Wir haben zwei x86-basierte Cloud-Instanzen in AWS EC2 mit instanzgebundenem NVMe-Speicher genommen.

Die Details dieser Benchmarks sind weit weniger spannend als die vorherigen. Wir haben die Instanzen mit Ubuntu 24.04 gestartet und DuckDB auf der Kommandozeile ausgeführt. Eine r6id.large-Instanz (2 vCPUs, 16 GB RAM) schloss die Queries in 570,8 Sekunden ab – grob auf dem Niveau eines luftgekühlten iPhones. Eine r6id.xlarge (4 vCPUs, 32 GB RAM) schaffte den Benchmark in 166,2 Sekunden, schneller als jedes Ergebnis auf den Telefonen.

Zusammenfassung der DuckDB-Ergebnisse

Die Tabelle fasst die DuckDB-Benchmark-Ergebnisse zusammen.

Historischer Kontext

Warum haben wir diese Experimente überhaupt gemacht?

Vor wenigen Wochen verlieh das CWI, die Geburtsstätte von DuckDB, die Dijkstra Fellowship. Die Fellowship ging an Marcin Żukowski für seine Pionierrolle bei Datenbankmanagementsystemen und seine erfolgreiche unternehmerische Laufbahn, aus der Systeme wie VectorWise und Snowflake hervorgingen.

Viele Ideen aus Marcins Forschung stecken in DuckDB. Vor allem ermöglicht vektorisierte Query-Verarbeitung, dass DuckDB gleichzeitig schnell und portabel ist. Zusammen mit Peter Boncz und Niels Nes beschrieb er dieses Paradigma zuerst im CIDR-2005-Paper „MonetDB/X100: Hyper-Pipelining Query Execution“.

Die Begriffe Vektorisierung, Hyper-Pipelining und Superskalar meinen dieselbe Idee: Daten in Scheiben zu verarbeiten – ein guter Kompromiss zwischen zeilen- und spaltenweiser Verarbeitung. DuckDBs Query Engine folgt demselben Prinzip.

Das Paper erschien im Januar 2005, wurde also vermutlich Ende 2004 fertiggestellt – vor fast genau 20 Jahren!

Im Paper steht, dass die Experimente auf einer HP-Workstation mit 12 GB Speicher liefen (dieselbe Menge wie das Samsung-Telefon heute!). Sie hatte eine Itanium-CPU und sah so aus:

Bei der Veröffentlichung 2001 zielte der Itanium auf das High-End-Segment und sollte die damals dominante x86-Architektur durch einen neuen Befehlssatz ersetzen, der stark auf SIMD (Single Instruction, Multiple Data) setzte. Dieser Ehrgeiz ging nicht auf, aber der Itanium war die State-of-the-Art-Architektur seiner Zeit. Wegen des Fokus auf den Servermarkt hatten die Itanium-CPUs viel Cache: Das im Experiment verwendete 1,3-GHz-Itanium2-Modell hatte 3 MB L2-Cache, während damalige Pentium-4-CPUs nur 0,5–1 MB hatten.

Das Paper liefert eine detaillierte Aufschlüsselung der Laufzeiten:

Die Gesamtlaufzeit der TPC-H-SF100-Queries lag bei 407,9 Sekunden – daher unsere Baseline. Hier ein Video von Hannes, der die Ergebnisse auf der Veranstaltung vorstellt:

Und hier alle Ergebnisse in einem Plot:

Fazit

Es war ein weiter Weg vom Originalpaper zur vektorisierten Ausführung bis zu einer analytischen Datenbank auf dem Telefon. Viele Schlüsselinnovationen haben diese Ergebnisse ermöglicht; die große Hardware-Verbesserung ist nur eine davon. Eine weitere entscheidende Komponente: Compiler-Optimierungen sind viel ausgefeilter geworden. Deshalb konnte DuckDB – anders als MonetDB/X100, das explizites SIMD brauchte – auf die Auto-Vektorisierung unserer (sorgfältig konstruierten) Schleifen setzen.

Bleibt, die Fragen vom Anfang zu beantworten. Ja, DuckDB kann TPC-H SF100 auf einem Mobiltelefon ausführen. Und ja, in manchen Fällen übertrifft es sogar einen Forschungsprototyp auf einer High-End-Maschine von 2004 – auf einem modernen Smartphone, das in die Tasche passt.

Mit neuerer Hardware, klügeren Compilern und noch zu entdeckenden Datenbankoptimierungen werden künftige Versionen nur noch schneller.