Leistung allein reicht nicht

• Bei der Auswahl einer Datenbank übersieht man leicht die gesamte Zeit vom Stellen einer Frage bis zur Antwort, wenn man nur auf die rohe Abfragegeschwindigkeit und allgemeine Benchmarks schaut
• Ein GigaOm-Benchmark von 2019 setzte Azure Data Warehouse und Redshift an die Spitze, doch im realen Markt verkauften sich Snowflake und BigQuery besser und zeigten damit die Bedeutung von Faktoren jenseits der Leistung
• Selbst wenn sich die Laufzeit auf dem Server verkürzt, können JDBC-Treiber, der Download von Ergebnissen, CSV-Parsing oder die Schwierigkeit beim Schreiben von SQL auf den Nebenschauplätzen größere Engpässe verursachen
• ClickBench, TPC-H und TPC-DS sind nützlich, aber je nach JOIN-Vorkommen, Single-Table-Scan, Schema-Tuning sowie Anforderungen an Korrektheit und ACID-Garantien fallen die Schlussfolgerungen unterschiedlich aus
• Die Leistung von Datenbank-Engines nähert sich mit der Zeit an, daher sollten langfristige Auswahlkriterien eher die Geschwindigkeit von der Idee zur Antwort und die Integration in den Workflow sein als das aktuelle Ranking

---

Die reale Wartezeit, die Benchmarks übersehen

• Auf einer Reise vom Zuhause in Seattle zum Büro in San Francisco, die 4,5 Stunden dauert, würde selbst eine Verzehnfachung der Reisegeschwindigkeit des Flugzeugs die Gesamtzeit wegen Anfahrt zum Flughafen, Sicherheitskontrolle, Boarding, Warten auf der Startbahn, Gepäck und Weiterfahrt am Ziel nur um etwa 20 % verkürzen
• Bei Datenbanken ist es ähnlich
  • Selbst wenn die Engine schneller wird, haben Nutzer weiterhin mit seltsamen CSV-Dateien, schwer in SQL formulierbaren Fragen und Problemen bei der Tool-Anbindung zu kämpfen
  • Produkte, die den Benchmark-Krieg gewinnen, lassen sich leicht vermarkten, aber das heißt nicht automatisch, dass sie die Zeit zur Problemlösung für Nutzer direkt verkürzen
• Bei der Wahl einer Datenbank können Benutzerfreundlichkeit, Ökosystem, Update-Geschwindigkeit und Workflow-Integration bessere Maßstäbe sein
• Leistung zeigt nur die Dauer einer bestimmten Aufgabe zu einem bestimmten Zeitpunkt und kann dazu verleiten, den falschen Engpass mit großem Aufwand zu optimieren

Die GigaOm-Ergebnisse von 2019 und ihr Widerspruch zum Markt

• 2019 führte GigaOm für Cloud Data Warehouses TPC-H- und TPC-DS-Benchmarks durch
  • Getestet wurden die drei großen Cloud-Anbieter sowie Snowflake
  • Das Ergebnis: Azure Data Warehouse war am schnellsten, gefolgt von Redshift; Snowflake und BigQuery lagen deutlich zurück
• In Nutzerbewertungen zu BigQuery entschieden sich damals Kunden, die direkt mit Azure verglichen hatten, häufig für BigQuery
• Das Marktergebnis war beinahe das Gegenteil des Benchmark-Rankings
  • Snowflake und BigQuery verkauften sich besser als Redshift
  • Redshift verkaufte sich besser als Azure
• TPC-H und TPC-DS sind Industriestandards und wurden auch intern zur Leistungsbewertung genutzt. Wenn Kunden dennoch häufiger Systeme kauften, die in guten Leistungsbenchmarks schlechter abschnitten, spricht das dafür, dass es wichtigere Faktoren als Leistung gab

Das vom Nutzer empfundene Tempo ist nicht die Serverzeit

• Menschen, die Datenbanken bauen, konzentrieren sich oft auf die Serverausführungszeit zwischen dem Klick auf den „run“-Button und dem Zeitpunkt, an dem das Ergebnis bereitsteht
• Für Nutzer zählt jedoch die Gesamtzeit bis zum Abschluss ihrer Aufgabe, und die ist nicht dasselbe wie die Zeit, die der Datenbankserver für die Abfrageausführung braucht
• Das Beispiel des JDBC-Treibers von BigQuery zeigt diesen Unterschied gut
  • Ein JDBC-Treiber war eine generische Schnittstelle, mit der Programmierer und BI-Tools eine Verbindung zur Datenbank herstellten
  • BigQuery-Abfragen liefen in 1–2 Sekunden, doch durch das Polling auf Fertigstellung und die Art des Ergebnisdownloads im Treiber wirkte es für Nutzer um Sekunden oder Minuten langsamer
  • Bei großen Ergebnismengen holte der Treiber seitenweise auch Daten ab, die der Nutzer gar nicht brauchte; das erhöhte die Latenz und führte teils zu Abstürzen wegen Speichermangels
• Ingenieure investierten viel Zeit darin, die Abfragezeit um Bruchteile von Sekunden zu verkürzen, während in der Praxis ein häufig verwendeter Connector weit größere Verzögerungen verursachte
• Interne Benchmarks liefen täglich, doch End-to-End-Performance und die tatsächlich empfundene Wartezeit der Nutzer waren darin nicht sichtbar

Leistung lässt sich nicht auf eine einzelne Zahl festnageln

• Leistung sollte nicht aus Sicht der Datenbank, sondern aus Sicht des Nutzers gemessen werden und lässt sich ähnlich wie UX nur schwer vollständig mit einer einzigen Zahl beschreiben
• Welche Datenbank schneller ist, hängt von der realen Workload ab
  • Auch wenn ein Lamborghini schneller ist als ein Prius, ändert sich die Pendelzeit im Stau womöglich nicht
  • Der Leistungsunterschied zwischen ClickHouse und Redshift hängt ebenfalls davon ab, wie sie genutzt werden
• ClickBench von ClickHouse zeigte Ergebnisse, in denen ClickHouse schneller war als viele andere Datenbanken
  • Der Benchmark arbeitete ohne JOINs auf einer einzelnen Tabelle und stützte sich stark auf Distinct-Counts
  • Für Log-Analysen oder die Berechnung eindeutiger Website-Nutzer kann das ein guter Proxy sein
  • Für Workloads mit Star-Schema in klassischen Data Warehouses kann das in die Irre führen
• Vendor-Benchmarks konzentrieren sich typischerweise auf die Bereiche, in denen der jeweilige Anbieter stark ist
• BigQuery kann in Benchmarks schwächer aussehen, sich in der realen Nutzung aber gut anfühlen, weil es kaum Stellschrauben hat und sich weitgehend selbst optimiert
• Eine stark getunte SingleStore-Instanz kann BigQuery in vielen Aufgaben deutlich schlagen, verlangt aber Zeit für Schema-Tuning und zusätzlichen Aufwand, wenn neue Workloads hinzukommen
• Für mehr Leistung lassen sich auch Sicherheitsmechanismen oder Genauigkeit reduzieren
  • Entfernen von Overflow-Checks
  • Auslassen von Write-Flushes
  • Näherungswerte für bestimmte Operationen
  • keine ACID-Garantien
• Solche Abkürzungen sind außerhalb kontrollierter Umgebungen oft keine Optionen, die man wirklich einsetzen möchte

Wichtiger als das aktuelle Ranking ist die Verbesserungsgeschwindigkeit

• Beim Aufbau eines auf DuckDB basierenden Unternehmens wurde darauf hingewiesen, dass DuckDB im h2o.ai-Benchmark deutlich zurücklag
• Dass das kein Grund zur Sorge war, hatte zwei Gründe
  • Leistung war ein nachrangiger Faktor
  • DuckDB verbesserte sich in sehr hohem Tempo
• Zu DuckDBs schneller Verbesserung trugen einige Architekturentscheidungen, eine relativ neue und saubere Codebasis sowie hervorragende Ingenieure bei
• In den veröffentlichten Ergebnissen für neuere DuckDB-Releases desselben Benchmarks rückte DuckDB mit großem Abstand aus dem Mittelfeld an die Spitze
• Die Auswahl einer Datenbank ist eine Entscheidung für mehrere Jahre, deshalb zählen nicht nur aktuelle Leistung und Funktionen, sondern auch die Fähigkeiten in einem Jahr
• Wenn sich zwei Datenbanken mit unterschiedlicher Geschwindigkeit verbessern, ist es wahrscheinlich klüger, die schneller voranschreitende zu wählen

Leistungslücken schließen sich mit der Zeit

• Wenn mehrere aktiv gepflegte Datenbanken über Jahre hinweg wiederholt verbessert werden, nähern sich ihre Leistungen tendenziell an
• Leistungsmechaniken eines Produkts können mit der Zeit auch in anderen Produkten umgesetzt werden
  • Wenn ClickHouse bei der Scan-Geschwindigkeit von einer Technik profitiert, kann Snowflake innerhalb von 1–2 Jahren ähnliche Funktionen erhalten
  • Wenn Snowflake inkrementelle materialized views hinzufügt, kann BigQuery bald nachziehen
• Die Techniken, mit denen Datenbanken Leistung erzielen, unterscheiden sich
  • Kompilieren von Abfragen in Maschinencode
  • Caching von Daten auf lokaler SSD
  • Verarbeitung von Shuffles mit spezieller Netzwerk-Hardware
• Wirksame Techniken kann grundsätzlich jeder mit genug Zeit implementieren, und wenn sie gut funktionieren, verbreiten sie sich wahrscheinlich über viele Systeme
• Im Vergleich der Data-Warehouse-Leistung von Fivetran-CEO George Fraser lag die schnellste Zeit 2020 bei 8 Sekunden und die langsamste bei 18 Sekunden; 2022 lagen drei Anbieter bei rund 7 Sekunden und selbst der langsamste bei 9 Sekunden
• Architekturunterschiede sind allerdings schwerer zu überwinden
  • Shared-Nothing-Datenbanken können gegenüber Shared-Disk im Nachteil sein
  • Redshift brauchte mehrere Jahre, um im Wesentlichen auf eine Shared-Disk-Architektur umzuschwenken
  • Lakehouses, die Metadaten im Object Store speichern, können Schwierigkeiten mit schnellen Updates haben
• Solche Unterschiede zeigen sich meist an den Randbedingungen; langfristig gibt es keinen grundlegenden Grund, warum Redshift von Natur aus schneller oder langsamer als Snowflake sein müsste

Funktionen, die die Zeit von der Frage zur Antwort verkürzen

• Für Nutzer ist die relevante Leistung die Zeit vom Entstehen einer Frage bis zum Erhalt der Antwort
• Diese Zeit zu verkürzen bedeutet nicht nur, Query-Pläne zu verbessern
  • Man kann es einfacher machen, Fragen auszudrücken
  • Man kann Ergebnisse leichter verständlich machen
  • Man kann Feedback geben, wenn falsche Fragen gestellt werden
  • Man kann beim Verständnis von Datenproblemen helfen
  • Man kann dafür sorgen, dass benötigte Daten am richtigen Ort und im richtigen Format bereitstehen
• Snowflake war stark darin, dass SQL-Eingaben von Nutzern „einfach funktionieren“
  • Zur Berechnung von Datumsdifferenzen lassen sich sowohl DATEDIFF als auch TIMEDIFF verwenden
  • Bei sinnvollen Typen funktionieren beide
  • Die Granularität kann angegeben oder weggelassen werden
  • Für die Granularität können Anführungszeichen verwendet werden oder nicht
• DuckDB ergänzte mit Friendlier SQL Funktionen, die das Schreiben und Pflegen von Abfragen erleichtern
  • GROUP BY ALL reduziert in Aggregatabfragen fehlende Felder in der GROUP-BY-Klausel
  • Da nur die SELECT-Liste geändert werden muss, sinkt beim Weiterentwickeln einer Abfrage der Bedarf, mehrere Stellen anzupassen
  • Nachdem sich diese Funktion als nützlich erwiesen hatte, fügten mehrere Datenbankanbieter ähnliche Features hinzu
• CSV-Dateien enthalten einen großen Teil der Daten der Welt, doch viele davon sind fehlerhaft aufgebaut und das Parsen ist in der Praxis schwierig
  • Der frühe CSV-Splitter von BigQuery konnte keine Inferenz durchführen und kam durcheinander, wenn sich Schemata zwischen Dateien leicht unterschieden
  • CSV-Parsing ist ein kniffligeres Problem, als es scheint
• Wenn zwei Ingenieure CSV-Daten einlesen und dasselbe Ergebnis berechnen sollen, kann derjenige zuerst zur Antwort kommen, dessen System CSV leichter korrekt ingestiert — unabhängig von der Geschwindigkeit der Query-Engine
• Auch die Verarbeitung von Ergebnissen hat großen Einfluss auf die Nutzererfahrung
  • Wenn SELECT * wie bei MySQL sofort die erste Seite und einen Cursor zurückgibt, kann das Ergebnis unmittelbar sichtbar sein
  • Wenn wie bei BigQuery serverseitig erst eine Kopie der Tabelle erstellt werden muss, kann das bei großen Tabellen Stunden dauern
  • Wenn der Client alle Daten herunterladen will, kann es zu Speichermangel kommen
  • Lange Verbindungen sind anfällig für Netzwerkprobleme, und Polling kann Abfragen langsamer erscheinen lassen, wenn sie zwischen zwei Polling-Intervallen enden

Hinweise beim Blick auf DuckDB-Benchmarks

• DuckDB ist schnell und liegt bei ClickBench für einige machine sizes an der Spitze
  • Als Beispiel wird das Ergebnis für c6a.4xlarge genannt
• DuckDB zeigt auch in den meisten h2o.ai-Benchmarks gute Leistung und schneidet auch bei TPC-H und TPC-DS ordentlich ab
• Bevor man annimmt, welche Datenbank schnell ist, sollte man sie auf der eigenen Workload direkt testen

Schnellere Problemlösung ist wichtiger als schnellere Abfragen

• Die erfolgreichsten Datenbankunternehmen wurden nicht allein deshalb erfolgreich, weil sie schneller als ihre Konkurrenz waren
• Redshift war eine Zeit lang stark, aber Snowflake konnte nicht wegen Benchmark-Leistung eindringen, sondern wegen Wartbarkeit
• Datenbanken, die Leistung als zentrales Verkaufsargument positionierten, waren am Markt weniger erfolgreich; besser hielten sich jene, mit denen sich Arbeit leichter erledigen ließ
• Bei der Datenbankauswahl sollte man auf breitere Achsen schauen
  • Es gibt keine magischen Geheimtechniken; abgesehen von Architekturunterschieden nähert sich die Leistung mit der Zeit an
  • Die Verbesserungsgeschwindigkeit von Datenbank-Engines unterscheidet sich stark, und wer sich schneller bewegt, ist langfristig im Vorteil
  • Datenbankanbieter, die am stärksten auf Leistung fixiert sind, können langfristig langsamer werden
  • Es gibt keine einzelne Kennzahl für Datenbankleistung, und selbst eine schnelle Datenbank kann bei bestimmten Workloads schlecht sein
  • Die wichtige Fähigkeit ist nicht, wie schnell man von der Abfrage zum Ergebnis kommt, sondern wie schnell man von der Idee zur Antwort gelangt
• Schnellere Abfragen sind besser als langsamere, aber bei der Wahl einer Datenbank sollten andere Faktoren als rohe Geschwindigkeit den Ausschlag geben

[GN⁺]

Hacker-News-Kommentare

• Frustrierend ist die Stelle, an der es heißt, man habe „überhaupt nicht gewusst“, dass ein Problem mit dem JDBC-Treiber die Performance ruinierte, obwohl es über Jahre viele Kundenbeschwerden gab.
  Intern bei Google hat man das eigene Produkt offenbar nicht so genutzt wie echte Kunden, und die Query-Zeiten, die Nutzer sahen, waren intern nicht sichtbar, also wurde es als Problem anderer Leute behandelt.

  • Auch die daraus gezogene Lehre wirkt etwas verfehlt. Es geht nicht darum, dass „Performance allein nicht reicht“, sondern darum, dass die Performance auf den Pfaden, die Kunden tatsächlich nutzen, wichtiger ist als Benchmarks einzelner Komponenten.
    Das Problem war nicht, dass zu viel Aufwand in Optimierung floss, sondern dass man nicht vom Schmerz der Kunden ausging und ihn bis zur eigentlichen Ursache zurückverfolgte. Die tatsächliche Ursache war am Ende ebenfalls ein Performance-Problem.

• Die JDBC-Geschichte war wirklich gut. Google baute intern eine gut funktionierende Datenbank, lagerte aber die Adapter-Schicht für die Außenwelt aus; weil diese nicht richtig funktionierte, bekamen externe Nutzer eine miserable Datenbank.
  Im Grunde wurde über den ausgefeilten Kern, den Google nutzt, eine kaputte Verpackung gestülpt, wodurch das gesamte Produkt unnötig chaotisch wurde. Intern bemerkte es niemand, und auch externe Nutzer konnten die Ursache nur schwer erkennen. Das wirkt wie ein sehr treffendes Beispiel für Googles Open-Source-Strategie.

  • Aus Managementsicht ist es verständlich. Nach dem Motto: „Wir stellen die besten Informatiktalente ein, also sollen sie die Kernprobleme der Informatik lösen; der JDBC-Treiber gehört nicht zu unseren Kernkompetenzen, also vergeben wir ihn nach außen.“
    Das Problem ist: Wenn man die Nicht-Kernbereiche gründlich genug vermasselt, nützt auch eine hervorragende Kernkompetenz nichts mehr. Outsourcing ist kein kostenloses Mittagessen.
  • Bei den Python-Wrappern für Google-APIs war es genau dieselbe Geschichte.
  • Das liegt an mangelnder vertikaler Integration. Apple gewinnt in vielerlei Hinsicht, weil sie vertikale Integration sehr gut beherrschen.
  • Bei Geschäftsverträgen wie Workspace ist es exakt dieselbe Struktur. Über ein hervorragendes Kernprodukt wird ein „Support“-Vertrag gelegt, der nicht nur nutzlos, sondern schädlich ist, während einige der weltweit schlechtesten Beratungsfirmen ungefähr 15 % abgreifen.

• Der Artikel sagt, „Performance ist subjektiv“ und einfache Messungen reichten nicht aus, aber die Beispiele zeigen eigentlich Fälle, in denen Performance tatsächlich wichtig und objektiv war. Es wurde nur das falsche Ziel gemessen.

  • Schon der erste Absatz beginnt mit einem Beispiel, das exakt zu Amdahls Gesetz passt; überraschend, dass es im Artikel kein einziges Mal erwähnt wird.

• Das klingt nach einem Organisationsproblem im Unternehmen. Wenn das Endziel darin besteht, Menschen dazu zu bringen, die Cloud zu nutzen und ihnen Wert zu liefern, warum hat man dann Metriken, die an dem vorbeigehen, was Kunden wichtig finden?
  Innerhalb von Google sollte es jemanden geben, der direkt mit Kunden spricht, herausfindet, wo das Problem liegt, und es an die Engineers weitergibt, damit sie wissen, was verbessert werden muss. Die Organisation sollte so gestaltet sein, dass Engineers die nötigen Metriken bekommen oder dass das Erstellen dieser Metriken selbst Teil ihrer Aufgabe ist.

  • „Wenn Anekdoten und Metriken auseinandergehen, stellt sich meist heraus, dass die Anekdoten stimmen“ — Jeff Bezos. Leider hat er gelegentlich gute Dinge gesagt.
  • Google scheint eine gewisse Allergie dagegen zu haben, direkt mit Kunden zu sprechen.
  • https://en.wikipedia.org/wiki/Seeing_Like_a_State
  • Wenn unsere Lösung das Problem des Kunden nicht löst, braucht der Kunde ein anderes Problem oder wir brauchen andere Kunden.
  • Stimme völlig zu. Es wirkt wie ein Problem falsch gewählter Zielmetriken. Allerdings geht es über den Umstand hinaus, dass ein Engineering-Team nur einen zu engen Ausschnitt der Latenz gemessen hat.
    Mich würde eher interessieren, welche Metriken Produkt- und Organisationsleitung betrachtet haben, dass sie solches Kundenfeedback übersehen konnten.

• Bei der Stelle „4,5 Stunden von Tür zu Tür vom Haus in Seattle bis zum Büro in San Francisco“ scheint es, als bewegten sich Gründer heute nicht mehr mit 179 Meilen pro Stunde. So sieht es wohl aus, wenn die Fed die Zinsen erhöht.

  • Beim ersten Lesen dachte ich, es gehe ums Autofahren, aber vermutlich ist die Zeit für Flugzeug + Transfer zum Flughafen + Sicherheitskontrolle gemeint.
  • Ich bin gerade tatsächlich auf dem Weg von meinem Haus in Seattle ins Büro in SF. Vor 48 Minuten bin ich losgegangen; wenn ich ankomme, aktualisiere ich das hier und füge selbst einen Datenpunkt hinzu.

• Es gibt definitiv gute Punkte, aber die Schlussfolgerung wirkt etwas daneben. Performance ist hier weniger nebensächlich, als es dargestellt wird, sondern eher eine Frage von ausreichend oder nicht.
  Erst wenn etwas schnell genug ist, kann man danach andere Faktoren bewerten. Vorher sitzt man nicht einmal mit am Tisch der Konkurrenz. Der Autor sagt selbst: „DuckDB ist schnell“; wäre es nicht schnell gewesen, hätte es zumindest so lange über Performance konkurrieren müssen, bis dieses Kästchen abgehakt ist.
  Außerdem mag die Aussage, dass „die Datenbank-Engine gewinnt, die sich am schnellsten bewegt“, bis zu einem gewissen Grad stimmen, ist aber nicht besonders praxisnah. Als neuer Player ist Fortschritt schnell, aber wenn man eine Position wie Snowflake erreicht, muss das Tempo zwangsläufig sinken. Wer heute ein System auswählt, kann die aktuelle Beschleunigung nicht einfach unverändert in die Zukunft extrapolieren.
  Trotzdem scheint die Perspektive, wie schnell man nicht „von der Query zum Ergebnis“, sondern von der Idee zur Antwort kommt, eine eigene vertiefte Betrachtung wert zu sein.

• Performance ist weniger „subjektiv“ als vielmehr relativ. Ihre Bedeutung hängt mit der anstehenden Aufgabe zusammen.
  Wenn es allerdings um Benutzeroberflächen geht, die Nutzer glauben lassen, etwas sei schneller — etwa ein schneller wirkender Fortschrittsbalken —, ist das eine andere Geschichte. Das ist ein Interface-Problem, kein Datenbankproblem.

  • „Subjektiv“ ist der richtige Ausdruck. Welche Aufgabe relevant ist, hängt vom Subjekt ab.
    Um „relativ“ sagen zu können, dürfte es außer dem Vergleich zwischen Systemen keine Möglichkeit geben, Performance mit Zahlen zu versehen; das stimmt aber nicht.

• Die erste Web-App, die ich populär machte, hielt ihren gesamten Zustand in einem Python dict und dumpte ihn alle paar Minuten auf die Festplatte. Das war die schnellste API, die ich je gesehen habe.
  Nach dem Umzug zu Mongo erholte sich die Performance nie wieder. Trotzdem greife ich heute beim Bau einer Website nicht zu „pickledb“.

  • Als Ersatz für fopen ist SQLite der Mittelweg.
  • Ich finde, mehr Leute sollten von Anfang an Strukturen mit im Speicher gehaltenem Zustand + Snapshots in Betracht ziehen statt transaktionaler Datenbankstrukturen.
    Für Request/Response-artige Nutzerinteraktionen passt das weniger gut, aber bei großen statischen Daten oder reproduzierbaren Streaming-Daten, die inkrementell oder batchweise verarbeitet werden, sollte es verbreiteter sein als heute.

• Ich suche gute Materialien zu dem Thema, dass Shared-Nothing-Datenbanken gegenüber Shared-Disk im Nachteil sind, Redshift Jahre brauchte, um überwiegend auf eine Shared-Disk-Architektur umzusteigen, und Lakehouses, die Metadaten in Object Storage speichern, schnelle Updates erschweren.

• Guter Artikel. Ich denke, das ist auch einer der Gründe, warum pandas in den letzten 10 Jahren so stark war.
  Die Single-Machine-Performance war gut genug, und es konnte 99 % aller der Menschheit bekannten CSV-Dateien einlesen.