Am 28. January, 2020 schrieb Mr. Benzi Galili von ScaleMP.com (mehrere AMD EPYC Server kombiniert zu einem grossen Software-Defined Server via Infiniband):
“Indeed PostgreSQL does not use MPI, but it also is not scalable, meaning that giving it a machine with 10x the number of cores (be it an HPE Superdome Flex, a ScaleMP-based system, or other) - will not yield a 10x performance improvement, and from a certain (low) number of cores, in the 40-100 range (depending on the specific workload), it will not yield any performance gains at all.”
Inzwischen gibt es den AMD EPYC 9965 Prozessor mit 192 Cores/384 Threads.
Mr. Benzi Galili favorisiert eXtremeDB von McObject.
Wir verwenden immer noch MariaDB. Never change a running system!
Längerfristig wollen wir zum PostgreSQL kompatiblen eXtremeDB von McObject wechseln. Übergangsweise setzen wir vielleicht PostgreSQL ein? Das incrementelle Backup von PostgreSQL 17 hat mich positiv beeindruckt.
Ich hatte ein paar MariaDB.com Aktien. Die sind heuer aus meinem Depot spurlos verschwunden. Inzwischen notieren sie wieder an der Boerse mit circa 50 US-Cent. Mein Geld ist weg.
Offensichtlich hat MariaDB.com Insolvenz angemeldet.
Zu meiner Erleuchtung:
Welches (Datenbank-)system skaliert denn bei 10 x Cores mit Performance 10 x? Zumal mit einer beliebigen Anzahl an bereits vorhandenen Cores als Ausgangspunkt.
Andere Frage:
War es jemals gut, bei Performanceproblemen mit Hardware danach zu werfen?
Das stimmt aber für alle relationalen und ACID konformen Datenbanken.
Dazu kommt noch die Frage: was genau bedeutet “skalieren”?
Die gleichen Abfragen für mehr gleichzeitig Verbindungen auszuführen ohne das die einzelne Abfrage langsamer wird? ann werden mehr CPUs im Regelfall sehr wohl helfen. Meistens wird dann aber I/O (Festplatte) der limitierende Faktor werden.
Oder bedeutet “skalieren”, dass eine bestimmte Abfrage wesentlich schneller wird? Dann helfen mehr CPUs nur sehr selten (auch hier gilt: das ist bei anderen Datenbank nicht anders)
Bis zu einem bestimmte Punkt auf jeden Fall. Z.B. der Wechsel von Festplatten zu SSDs. Und dann zu NVMe - da hat man vor allem bei I/O lastigen Systemen eine extreme Verbesserung gesehen.
Wenn viele gleichzeitige Abfragen unterstützt werden müssen, dann hilft mehr Hardware (mehr CPUs, mehr Speicher) auch bis zu einem gewissen Punkt. Postgres ist bei der einzelnen Ausführung nicht wesentlich schneller geworden in den letzten Jahren, aber wenn viele konkurrierende Anfragen durchgeführt werden, gab es schon eine spürbare Verbesserung des Gesamtdurchsatzes
Kommt mir auch so vor, hab aber keine Zahlen dazu.
Der Klassiker ist eigentlich “die langsame Abfrage”, die unabhängig von der Anzahl der Aufrufe einfach langsam ist (oder immer langsamer wird mit wachsender Datenmenge).
Und speziell bei DB ist der Erfahrungswert, dass die IO Leistung Storage der Flaschenhals ist, nicht die Cores, besonders Gruppierung oder Sortierung (Das kann man in Grenzen mit RAM erschlagen)
Ich hätte es präziser formulieren sollen.
Ich habe eine Hardware X mit Performancewert Y. Wenn ich nun die identische(!) Hardware mit Faktor 10 betreibe, erhalte ich niemals den Performance Faktor 10.
In der Praxis wird mehr von “dem gleichen” eingesetzt. Z.B. ein Chip, den man eh schon wegen eines guten Preis/Leistungsverhältnis benutzt.
Ein Technologiewechsel in der Hardware ist eine etwas andere Sache. Natürlich macht sich gerade bei DB der Wechsel von HDD aud SSD bezahlt. Zum einen weil Storage sowieso der Flaschenhals ist (allermeistens), also das Regulativ, zum anderen weil ich eben genau im Regulativ einen signifikanten Leistungsschub mit diesem Wechsel auf SSD erhalte
Was ich aber eigentlich denke: Vor jeder Hardwareaufrüstung mit der oben genannten, theoretischen (und nicht wirklichen) Verbesserung von Faktor X, kommt zuerst die kostengünstige Softwareoptimierung (Ausführungsplan, …).
In einem nicht optimierten (beliebig schlechten) System kann ich durch Abfrageoptimierung die Ausführungsgeschwindigkeit um Faktoren der Größenordnung 10, 100, 1000 oder noch besser optimieren.
Erst wenn das ausgereizt ist, kann ich effiziente Zuwächse mit Hardwareaustausch / -Erweiterung erreichen.
Oder anders:
Wenn das Softwaresystem (App und DB) jenseits meiner Kontrolle ist, bleibt mir nur die Hardware zur Optimierung. Andernfalls kann ich meist um Größenordnungen besser optimieren, wenn ich die Software / die Abfrage optimiere.
