Thomas Neumann entlarvt, wie GenDB-V den TPC-H-Benchmark mit dbgen-Wissen austrickst
Next-Level Benchmarking Overfitting – Thomas Neumann
Thomas Neumann zerlegt die spektakulären 22- bis 61-fachen Speedups von GenDB-V gegenüber Umbra und DuckDB. Die Gewinne stammen nicht aus besserer Query-Verarbeitung, sondern aus handgebauten Hilfsstrukturen pro Query und aus fest einprogrammiertem Wissen über den TPC-H-Datengenerator: Jeder Kunde k liegt angeblich in Zeile k-1, was den Join in Q18 fast kostenlos macht. Ein einziger gelöschter Tupel würde den Ansatz abstürzen lassen.
Lässt man KI-Agenten für einen bestimmten Datenbank-Benchmark optimieren, macht das den Benchmark wertlos.
- lmeyerov
Wir haben GFQL für Open-Source-vektorisiertes CPU/GPU-Cypher auf Dataframes gebaut (denk an DuckDB für Graphen, keine DB nötig) und dabei agentische Unterstützung genutzt... und unser Gedanke ist, dass dies ein Sprungbrett zu etwas noch Aggressiverem ist.
Heute setzen wir auf die Optimierung von Hotpath-Spezialisierungen für einige Muster, die früher zu teuer im Unterhalt gewesen wären. LLMs halten diese Kosten tragbar, und das für wichtige Nutzer tun zu können (wie die Nutzer unseres Analystenprodukts Graphistry) ist eine Superkraft. Unsere Ergebnisse in Graph-Community-Benchmarks schlagen die Großen – und, was wichtig ist, bei allem, was uns am Herzen liegt.
Wohin wir damit wirklich wollen, ist Runtime-/Loadtime-Spezialisierung. Unsere Kunden würden ihre Top-Queries absolut gerne automatisch tunen lassen. Die DB-Forschung neigt sich bereits stark in diese Richtung, ähnlich wie die Compiler-Forschung vor einem Jahrzehnt. Ich bin ziemlich optimistisch, was heute möglich ist.
- augment_me
In der GPU-Kernel-Entwickler-Community gab es ein ähnliches Problem.
Gelöst wurde es durch die Einsicht, dass der Wert, den Benchmarks liefern, von deinem Anwendungsfall abhängt. Es klingt, als schimpfe der Autor im Artikel auf den Benchmark aus seiner eigenen Vorstellung davon, was eine DB-Suche sein sollte (zuverlässig, allgemein), und nicht aus dem, was der Benchmark tatsächlich misst.
Wenn du nur den schnellsten Kernel für eine Handvoll Shapes willst, lass die Leute brüchigen, aber schnellen Code schreiben.
Wenn du an allgemeinen, breiten Lösungen interessiert bist, benchmarke 50 verschiedene Einträge, begrenze die Codegröße, um Assembly-Branches für jeden möglichen Eintrag zu verbieten.
Pack Anforderungen wie Bit-Gleichheit oder andere Endaufgaben-Grenzen rein.
Hab öffentliche und private Datensätze.
Ich denke, es ist eher ein Beweis dafür, dass wir mehr Zeit darauf verwenden sollten, darüber nachzudenken, was und warum wir diese Dinge wollen, und Benchmarks entwerfen sollten, die das widerspiegeln, statt nach der alten Art vorzugehen.
- qsort
Der Autor hat recht, wenn er darauf hinweist, dass dies eine Fortsetzung und Verstärkung eines bestehenden Trends ist.
Ich bin im Datenbereich und kämpfe den guten Kampf, verbreite das Evangelium von „Benutz einfach Postgres“, und ich sehe immer mehr Benchmarks, die extrem dubios aussehen. Query-Performance ist wie die Wahl einer Datenstruktur in der normalen Programmierung: Sie hängt fast vollständig davon ab, welches Zugriffsmuster du zur Laufzeit erwartest; es ist völlig sinnlos, nach der weltweit schnellsten Linked List zu suchen, wenn du eine Hash Table gebraucht hättest. Vergleiche das mit der Situation in der modernen Data-Engineering-Landschaft. Bist du sicher, dass die vom Benchmark gemessene Lösung tatsächlich eine Lösung für dein Problem ist, geschweige denn eine signifikante Verbesserung gegenüber „Benutz einfach Postgres“? Hast du gemessen, oder gehst du nach Marketing und Bauchgefühl?
Nochmal: Ich bin sicher, dass solche Lösungen ihren Platz haben, aber zumindest im Moment ist es nicht derselbe Platz wie bei traditionellen Engines.