Perf allein reicht nicht aus

Die leistungsfixierte Kultur von Datenbanken

• Die Datenbankbranche konzentriert sich stark auf Leistungssteigerungen, doch die tatsächliche User Experience wird oft von anderen Faktoren beeinflusst.
• Für Nutzer kann bei der Datenverarbeitung wichtiger sein als Query-Optimierung, in welchem Format die Daten vorliegen oder ob sie in der Lage sind, Fragen in SQL zu formulieren.
• Die Performance einer Datenbank ist wichtig, aber es kann sinnvoller sein, eine Datenbank nach anderen Kriterien auszuwählen – etwa Bedienbarkeit, Ökosystem, Update-Geschwindigkeit oder Integration in bestehende Workflows.

Das Ende der Benchmark-Kriege

• 2019 veröffentlichte GigaOm einen Benchmark zum Vergleich von Cloud Data Warehouses, doch die tatsächlichen Marktergebnisse entwickelten sich anders.
• Wenn Benchmark-Ergebnisse nicht mit der User Experience übereinstimmen, deutet das darauf hin, dass entweder der Benchmark falsch war, das Falsche getestet wurde oder Performance vielleicht nicht so wichtig ist.

Was „schnell“ bedeutet

• Im Bereich Cloud-Datenbanken richtet sich der Fokus häufig darauf, wie viel Zeit vergeht, nachdem der Nutzer auf „Ausführen“ klickt, bis das Ergebnis bereitsteht.
• Für Nutzer zählt in Wirklichkeit, wie lange es dauert, eine Aufgabe abzuschließen – und das ist nicht dasselbe wie die Laufzeit auf dem Datenbankserver.

Performance ist subjektiv

• Performance muss aus der Perspektive des Nutzers gemessen werden und ist ein UX-Problem, das sich nicht durch eine einzelne Zahl beschreiben lässt.
• Die Subjektivität von Performance bedeutet, dass sich erst aus der Art der Nutzung einer Datenbank ergibt, welche tatsächlich schneller ist.

Die Geschwindigkeit des Wandels

• DuckDB verbessert sich in hohem Tempo, wodurch aktuelle Benchmarks schnell bedeutungslos werden.
• Bei der Wahl einer Datenbank sind nicht nur die aktuelle Performance, sondern auch künftige Änderungen bei Leistung und Funktionen wichtige Variablen.

Es gibt keine Zauberbohne

• Wenn alle Datenbanken aktiv gepflegt werden, wird sich die Performance im Laufe der Zeit angleichen.
• Bedeutende Performance-Unterschiede werden mit hoher Wahrscheinlichkeit nicht dauerhaft bestehen bleiben.

Das Problem liegt zwischen Stuhl und Tastatur – und zwischen Tastatur und Datenbank

• Für Nutzer ist das entscheidende Performance-Maß, wie lange es dauert, mit einer Frage zu einer Antwort zu gelangen.
• Wichtig ist nicht die Zeit, die die Datenbank für die Ausführung einer Query braucht, sondern die Geschwindigkeit vom Gedanken zur Antwort.

Über saure Trauben

• DuckDB liegt derzeit bei den Benchmarks von ClickBench und h20.ai vorn und zeigt auch bei TPC-H und TPC-DS keine schlechte Leistung.
• Bevor man annimmt, dass eine Datenbank schnell ist, sollte man sie mit der tatsächlichen eigenen Workload testen.

Fazit

• Die erfolgreichsten Datenbankunternehmen waren nicht deshalb erfolgreich, weil sie schneller als ihre Konkurrenz waren.
• Datenbanken, die Performance zum zentralen Verkaufsargument gemacht haben, waren am Markt nicht erfolgreich.
• Bei der Wahl einer Datenbank ist es ratsamer, die Entscheidung auf andere Faktoren als rohe Geschwindigkeit zu stützen.

Die Meinung von GN⁺

• Dieser Artikel betont, dass es nicht genügt, sich nur auf die Performance von Datenbanken zu konzentrieren, sondern dass es entscheidend ist, User Experience und Arbeitsabläufe zu optimieren. Auch für Junior-Softwareingenieure ist das eine wichtige Lehre: Bei der Auswahl einer Datenbank sollte man statt bloßer Performance-Kennzahlen einen nutzerzentrierten Ansatz berücksichtigen.
• Die Performance von Datenbanken tendiert dazu, sich im Laufe der Zeit anzugleichen, weil sich technologische Fortschritte über alle Plattformen hinweg verbreiten. Das legt nahe, dass man bei Technologieentscheidungen eher langfristigen Support und Verbesserungspotenzial als kurzfristige Performance betrachten sollte.
• Open-Source-Projekte wie DuckDB können sich dank schneller Verbesserungszyklen und Community-Unterstützung rasch weiterentwickeln. Das bedeutet, dass man bei der Einführung neuer Technologien auch die Aktivität der Community und das Entwicklungstempo des Projekts berücksichtigen sollte.
• Bei der Auswahl einer Datenbank sollte man sich nicht nur auf die Ergebnisse von Performance-Benchmarks verlassen, sondern die Leistung unter der eigenen realen Workload testen. Das kann helfen, eine Datenbank zu wählen, die besser zu den tatsächlichen Anwendungsfällen passt.
• Es wird hervorgehoben, dass bei der Wahl von Datenbanktechnologien nicht nur technische Aspekte, sondern auch Geschäftsanforderungen, Wartungsfreundlichkeit und Effizienz der Datenverarbeitung berücksichtigt werden sollten.

[GN⁺]

Hacker-News-Kommentare

• Erst nach mehreren Jahren mit vielen Kundenbeschwerden wurde klar, dass ein Bug im JDBC-Treiber die Performance verschlechterte. Viele Ingenieursstunden wurden darauf verwendet, Abfragen zu beschleunigen, aber der Connector, den die meisten Nutzer verwendeten, fügte weit mehr Latenz hinzu, als dadurch eingespart wurde. Außerdem war man sich dieser Tatsache überhaupt nicht bewusst. Intern bei Google nutzte niemand den JDBC-Treiber, daher konnte man die Abfragezeiten der Nutzer nicht sehen und betrachtete es als Problem anderer.

  • Dieser Kommentar drückt Enttäuschung darüber aus, dass Google gegenüber Kundenbeschwerden „völlig blind“ gewesen sei und seine eigenen Produkte nicht selbst nutze. Die Geschichte mit dem JDBC-Teil ist besonders eindrücklich.
• Google hat intern eine gut funktionierende Datenbank gebaut, aber die Adapter-Schicht für die Außenwelt als Auftragsarbeit erstellen lassen, und diese funktionierte nicht richtig, sodass die Außenwelt eine mangelhafte Datenbank nutzen musste. Der ausgefeilte Kern, den Google selbst verwendet, ist von unvollständigen Adaptern umgeben, wodurch das Gesamtergebnis unnötig chaotisch wird. Intern nimmt man das nicht wahr, und für Externe ist es schwer zu erkennen.
  • Dieser Kommentar hält das für sehr treffend in Bezug auf Googles Open-Source-Strategie.
• Ich finde es seltsam, dass der Blog behauptet, „Performance sei subjektiv“. Es reicht zwar nicht, Performance nur zu messen, aber im einzigen angeführten Beispiel ist Performance wichtig und objektiv. Es wurde nur das Falsche gemessen.
  • Dieser Kommentar stellt die Behauptung des Blogs zur Performance-Messung infrage.
• Das klingt nach einem Problem der Unternehmensorganisation. Wenn das Endziel darin besteht, Kunden zur Nutzung der Cloud zu bringen und Mehrwert zu liefern, dann darf man keine Metriken haben, die von dem abweichen, was den Kunden wichtig ist. Innerhalb von Google sollte es Menschen geben, die aktiv auf die Probleme der Kunden hören und diese an die Ingenieure weitergeben, damit klar ist, was verbessert werden muss.
  • Dieser Kommentar betont die Notwendigkeit einer Organisationsstruktur, die Kundenanforderungen versteht und in Verbesserungen umsetzt.
• Von meinem Haus in Seattle bis zum Büro in San Francisco dauert es von Tür zu Tür etwa 4,5 Stunden.
  • Dieser Kommentar weist darauf hin, dass Gründer sich nicht mehr mit hoher Geschwindigkeit bewegen, und erwähnt scherzhaft, dass das an den Zinserhöhungen der US-Notenbank liegen könnte.
• Ich sehe Performance nicht so, wie hier gesagt wird, als zweitrangig an. Zuerst sollte man sicherstellen, dass die Performance gut genug ist, und erst danach alles andere bewerten. Der Autor selbst erwähnt, dass „DuckDB schnell ist“. Wäre das nicht so, müsste man in einen Performance-Wettbewerb eintreten.
  • Dieser Kommentar stimmt der Aussage nicht zu, Performance sei zweitrangig, und argumentiert, dass zuerst sichergestellt werden müsse, dass die Performance ausreichend gut ist.
• Performance ist nicht „subjektiv“, sondern „relativ“. Ihre Bedeutung hängt mit der jeweiligen Aufgabe zusammen.
  • Dieser Kommentar erklärt die Relativität von Performance und grenzt sie von der empfundenen Performance im Zusammenhang mit User-Interface-Design ab.
• Meine erste populäre Web-App speicherte den gesamten Zustand in einem Python-dict und schrieb ihn alle paar Minuten auf die Festplatte. Das war eine sehr schnelle API, aber nach dem Umstieg auf MongoDB kehrte die Performance nicht zurück. Trotzdem würde man heute beim Bau einer Website nicht „pickledb“ wählen.
  • Dieser Kommentar teilt die Erfahrung mit der Performance einer frühen Web-App und dem Leistungsabfall nach dem Datenbankwechsel.
• Ich wollte mein eigenes Datenbanksystem bauen und die Performance mit anderen populären Datenbanken (Postgres, Sqlite, MySQL, SQL Server) benchmarken.
  • Dieser Kommentar erklärt, dass man erst dann zufrieden war, wenn die Zeit vom Klick auf den „Run“-Button bis zur Anzeige des Ergebnisses auf dem Bildschirm gemessen wurde und die eigene Datenbank über verschiedene Abfragen hinweg schneller war.
• „Natürlich gibt es Ausnahmen von dieser Regel, nämlich dann, wenn Architekturunterschiede schwer zu überwinden sind. Eine Shared-Nothing-Datenbank ist gegenüber Shared Disk im Nachteil, und Redshift brauchte viele Jahre, um im Wesentlichen zu einer Shared-Disk-Architektur überzugehen. Lakehouses, die Metadaten in Object Storage persistent speichern, werden Schwierigkeiten mit schnellen Updates haben; das ist dem Modell inhärent.“
  • Dieser Kommentar weist auf Probleme im Zusammenhang mit Datenbankarchitektur-Unterschieden hin und erwähnt, dass nach guter Literatur zu diesem Thema gesucht wird.