2025-05-19

Das verlorene Jahrzehnt der Small Data?

Hannes Mühleisen

Viel ist gesagt worden, nicht zuletzt von uns selbst, darüber, dass Daten eigentlich gar nicht so „Big“ sind und dass die Geschwindigkeit der Hardware-Innovation das Wachstum nützlicher Datensätze überholt. Wir sind so weit gegangen, eine Datensingularität in naher Zukunft vorherzusagen, bei der 99 % der nützlichen Datensätze bequem auf einem einzelnen Knoten abgefragt werden können. Wie kürzlich gezeigt, liest der Median-Scan in Amazon Redshift und Snowflake überschaubare 100 MB Daten, und das 99,9-Perzentil liest weniger als 300 GB. Die Singularität könnte also näher sein, als wir denken.

Aber wir haben uns gefragt: Wann hat diese Entwicklung wirklich begonnen? Wann sind Personal Computer wie das allgegenwärtige MacBook Pro, das sonst oft nur Chrome ausführen darf, zu den Datenverarbeitungs-Kraftwerken geworden, die sie heute wirklich sind?

Richten wir den Blick auf das 2012er Retina MacBook Pro, einen Computer, den damals viele Menschen (mich eingeschlossen) wegen seines wunderschönen „Retina“-Displays gekauft haben. Millionen wurden verkauft. Obwohl ich damals arbeitslos war, hatte ich sogar das 16-GB-RAM-Upgrade spendiert. Aber es gab noch eine oft vergessene revolutionäre Änderung in dieser Maschine: Es war das erste MacBook mit eingebauter Solid-State-Disk (SSD) und einer konkurrenzfähigen 4-Kern-2,6-GHz-„Core i7“-CPU. Es ist lustig, sich die Ankündigung nochmal anzusehen, in der sie den Performance-Aspekt der „All-Flash-Architektur“ durchaus betonen.

Nebenbemerkung: Das MacBook Air war eigentlich schon 2008 das erste MacBook mit (optionaler) eingebauter SSD. Es hatte aber leider nicht die CPU-Feuerkraft des Pro.

Zufällig habe ich dieses Laptop noch im DuckLabs-Büro, derzeit von meinen Kindern genutzt, um ihre Namen in riesiger Schriftgröße zu tippen oder Bluey auf YouTube zu schauen, wenn sie da sind. Aber kann dieses Relikt noch modernes DuckDB ausführen? Wie wird seine Performance im Vergleich zu modernen MacBooks aussehen? Und hätten wir die Datenrevolution, die wir jetzt erleben, schon 2012 haben können? Finden wir es heraus!

Software

Zuerst: Was ist mit dem Betriebssystem? Um den Vergleich für(er) die Jahrzehnte fair zu machen, haben wir das Betriebssystem auf dem Retina tatsächlich auf OS X 10.8.5 „Mountain Lion“ downgradet, die Version, die nur wenige Wochen nach dem Laptop selbst im Juli 2012 ausgeliefert wurde. Auch wenn das Retina tatsächlich 10.15 (Catalina) ausführen kann, fanden wir, dass ein echter 2012-Vergleich auch ein Betriebssystem aus der Zeit nutzen sollte. Unten ein Screenshot der Benutzeroberfläche für alle, die sich manchmal ein bisschen alt fühlen.

Weiter zu DuckDB selbst: Hier bei DuckDB sind wir mehr als ein bisschen religiös, was Portabilität und Abhängigkeiten angeht – oder vielmehr deren Fehlen. Das heißt, es musste sehr wenig passieren, damit DuckDB auf dem uralten Mountain Lion läuft: Die Standard-DuckDB-Binary wird standardmäßig mit Rückwärtskompatibilität zu OS X 11.0 (Big Sur) gebaut, aber einfach das Flag zu ändern und neu zu kompilieren reichte, um DuckDB 1.2.2 auf Mountain Lion zum Laufen zu bringen. Wir hätten DuckDB gern auch mit einem Compiler von 2012 gebaut, aber C++ 11 war 2012 wenig überraschend einfach zu neu, um von Compilern vollständig unterstützt zu werden. Die Binary läuft jedenfalls gut und hätte auch durch Umgehen der Compiler-Bugs entstehen können. Oder wir hätten einfach Assembly von Hand geschrieben, wie andere es getan haben.

Benchmarks

Aber uns interessieren keine synthetischen CPU-Scores, uns interessieren synthetische SQL-Scores! Um zu sehen, wie die alte Maschine bei ernsthaftem Datenknacken dasteht, haben wir den inzwischen ziemlich müden, aber wohlbekannten TPC-H-Benchmark bei Scale Factor 1000 genutzt. Das heißt, die beiden Haupttabellen lineitem und orders enthalten 6 bzw. 1,5 Milliarden Zeilen. Als DuckDB-Datenbank hat die Datenbank eine Größe von ca. 265 GB.

Aus den auditierten Ergebnissen auf der TPC-Website sehen wir, dass das Ausführen des Benchmarks auf diesem Scale Factor auf einem einzelnen Knoten Hardware zu kosten scheint, die Hunderttausende Dollar kostet.

Wir haben jede der 22 Benchmark-Abfragen fünfmal ausgeführt und die mediane Laufzeit genommen, um Rauschen zu entfernen. Weil die RAM-Menge (16 GB) aber sehr viel kleiner ist als die Datenbankgröße (265 GB), kann kein nennenswerter Teil der Eingabedaten im Buffer Manager gecacht werden – das sind also nicht wirklich das, was manchmal „Hot Runs“ genannt wird.

Unten die Ergebnisse pro Abfrage in Sekunden:

Aber was bedeuten diese kalten Zahlen eigentlich? Die versteckte Sensation ist, dass wir überhaupt Zahlen haben: Dieser alte Computer konnte alle Benchmark-Abfragen mit DuckDB abschließen! Schaut man etwas genauer hin, dauern die Abfragen irgendwo zwischen einer Minute und einer halben Stunde. Das sind keineswegs unvernünftige Wartezeiten für analytische Abfragen auf solchen Daten. Man hätte 2012 viel länger gewartet, bis Hadoop YARN den Job überhaupt aufnimmt – nur um irgendwann Stacktraces ins Gesicht zu bekommen.

Verbesserungen 2023

Aber wie stehen diese Ergebnisse im Vergleich zu einem modernen MacBook? Als Vergleichspunkt haben wir ein modernes ARM-basiertes M3 Max MacBook Pro genutzt, das zufällig auf demselben Schreibtisch stand. Zwischen ihnen stehen die beiden MacBooks für mehr als ein Jahrzehnt Hardware-Entwicklung.

Allein bei den GeekBench-5-Benchmark-Scores sehen wir ca. 7× Unterschied in der rohen CPU-Geschwindigkeit bei Nutzung aller Kerne und ca. Faktor 3 in der Single-Core-Geschwindigkeit. Natürlich gibt es auch große Unterschiede bei RAM- und SSD-Geschwindigkeiten. Lustigerweise sind Displaygröße und Auflösung fast unverändert.

Hier die Ergebnisse nebeneinander:

Wir sehen deutliche Speedups, von 7 bis zu 53. Das geometrische Mittel der Zeiten verbesserte sich von 218 auf 12, ca. 20× Verbesserung.

Reproduzierbarkeit

Binary, Skripte, Abfragen und Ergebnisse sind auf GitHub zur Einsicht verfügbar. Wir haben auch die TPC-H-SF1000-Datenbankdatei zum Download bereitgestellt, damit Sie sie nicht selbst erzeugen müssen. Aber Vorsicht, es ist eine große Datei.

Diskussion

Wir haben gesehen, wie das zehn Jahre alte MacBook Pro Retina einen komplexen analytischen Benchmark abschließen konnte. Ein neueres Laptop konnte diese Zeiten deutlich verbessern. Aber absolute Speedup-Zahlen sind hier etwas sinnlos. Der Unterschied ist rein quantitativ, nicht qualitativ.

Aus Nutzersicht zählt viel mehr, dass diese Abfragen in einigermaßen vernünftiger Zeit fertig werden, nicht ob das 10 oder 100 Sekunden gedauert hat. Wir können mit beiden Laptops fast dieselbe Art von Datenproblemen angehen, wir müssen nur etwas länger warten. Das gilt besonders dank DuckDBs Out-of-Core-Fähigkeit, die es erlaubt, Query-Zwischenstände bei Bedarf auf die Platte auszulagern.

Interessanter ist vielleicht, dass es 2012 völlig machbar gewesen wäre, eine Single-Node-SQL-Engine wie DuckDB zu haben, die komplexe analytische SQL-Abfragen gegen eine Datenbank mit 6 Milliarden Zeilen in handhabbarer Zeit ausführt – und wir mussten sie diesmal nicht einmal in Trockeneis tauchen.

Die Geschichte ist voller „Was wäre wenn“: Was wäre, wenn so etwas wie DuckDB 2012 existiert hätte? Die Hauptzutaten waren da, vektorisierte Query-Verarbeitung war schon 2005 erfunden. Wäre der inzwischen etwas albern wirkende Umzug zu verteilten Systemen für Datenanalyse jemals passiert? Die Datensatzgröße unserer Benchmark-Datenbank lag erschreckend nah an jenem 99,9-Perzentil des Eingabedatenvolumens für analytische Abfragen 2024. Und während das Retina MacBook Pro 2012 eine High-End-Maschine war, stellten bis 2014 viele andere Hersteller auf Laptops mit eingebauter SSD um, und größere Speichermengen wurden verbreiteter.

Also ja: Wir haben wirklich ein ganzes Jahrzehnt verloren.