MySql-->Postgresql ==> schlechtere Performance

Datenbank Migration (z. B. von MySQL auf PostgreSQL)
Antworten
hretif
Benutzer
Beiträge: 39
Registriert: Mo 6. Nov 2006, 18:36

MySql-->Postgresql ==> schlechtere Performance

Beitrag von hretif »

Hallo,
Ich betreibe eine kleine Delphi Applikation (15 Tabelle, max 200 Rows pro Tabelle). Einzige Spezialität sind ein Paar SELECT mit etwas 10 JOINS. Es muss auf gewöhnliche PCs laufen (1 GB Ram).

Diese Applikation ist sehr schnell mit MySQL. Mit der Default Konfiguration von Postgresql ist es wesentlich langsamer geworden.

Kann jemand mir erklären ob gewisse Parameter zu einstellen sind, damit es besser wird? Oder ist Postgresql prinzipiell langsamer…

Vielen Dank,
Hubert Retif

akretschmer
Erfahrener Benutzer
Beiträge: 7714
Registriert: So 29. Okt 2006, 13:35
Wohnort: Kaufbach, Sachsen, Germany, Germany
Kontaktdaten:

Beitrag von akretschmer »

hretif hat geschrieben:Hallo,
Ich betreibe eine kleine Delphi Applikation (15 Tabelle, max 200 Rows pro Tabelle). Einzige Spezialität sind ein Paar SELECT mit etwas 10 JOINS. Es muss auf gewöhnliche PCs laufen (1 GB Ram).

Diese Applikation ist sehr schnell mit MySQL. Mit der Default Konfiguration von Postgresql ist es wesentlich langsamer geworden.

Kann jemand mir erklären ob gewisse Parameter zu einstellen sind, damit es besser wird? Oder ist Postgresql prinzipiell langsamer…

Vielen Dank,
Hubert Retif


Generische, einfache Antwort: nimm MySQL.

Sinnvolle Antwort: vergleich bitte nicht Äpfel mit Birnen. Du hast unter MySQL ganz sicher MyISAM am Start, ohne RI, ohne TX, ohne irgend ein Feature, was man einklich will.
- welches PG hast Du?
- was sagt EXPLAIN?

Ohne sinnvolle Details zu kennen, macht es keinen Sinn, hier weiter zu diskutieren. IMHO.

fristo
Erfahrener Benutzer
Beiträge: 670
Registriert: Do 8. Dez 2005, 12:30
Wohnort: Raum Frankfurt/Main

Beitrag von fristo »

Hallo Hubert,

die Angabe "wesentlich langsamer" ist dehnbarer Zeitbegriff zu dem man keine Aussage machen kann. Eine Änderung der default Konfiguration-Werte von PostgreSQL wird Dir nichts bringen. Zudem ist die Datenbank mit 15 Tabellen a 200 Datensätze nicht groß. Es muss auch nicht unbedingt an der Datenbank liegen wie Du in diesem Beitrag http://www.pg-forum.de/showthread.php?t=954 nachlesen kannst. Vielleicht helfen die angebenen Maßnahmen auch bei dir.



mfg

fristo

ads
Erfahrener Benutzer
Beiträge: 4151
Registriert: Mi 8. Feb 2006, 10:58
Wohnort: MD
Kontaktdaten:

Beitrag von ads »

Gut, zusätzlich zu all den Tipps, die hier schon kamen, wo genau und in welchem Maßstab ist die Datenbank langsamer? Welche Queries konkret werden langsamer und wie sieht der Queryplan und die Tabellendefinition der beteiligten Tabellen aus?

Dann können wir mal anfangen, konkret zu prüfen, was nicht passt. Alles andere ist, wie akretschmer geschrieben hat, Äpfel und Birnen. Mysql ist nur darum schnell, weil es sich um fast gar nichts kümmert, was eine DB braucht ... jedenfalls in der Standardkonfiguration.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören Bild

Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

PostgreSQL Service & Support

hretif
Benutzer
Beiträge: 39
Registriert: Mo 6. Nov 2006, 18:36

Beitrag von hretif »

Danke für die Antworten.

>>Generische, einfache Antwort: nimm MySQL.
Will ich aber nicht weil ich mich die Lizenz Kosten nicht leisten kann. Ich habe gleichzeitig mit Firebird und Postgresql probiert und bin bei der zweite geblieben weil mit Firebird viel weniger vorhanden ist (u.a. Date Time Funktionen), mein SQL Syntax hat Problemen gegeben (mit Postgresql lief es auf anhieb) und ich komme besser zu Recht mit pgAdmin als mit Flamerobin.

>>Du hast unter MySQL ganz sicher MyISAM
Nein, InnoDB

>>- welches PG hast Du?
PostgreSQL Database Server 8.1

>>die Angabe "wesentlich langsamer" ist dehnbarer Zeitbegriff
Klar. Tatsache ist aber dass es langsamer ist. Mit **genau** gleiche Bedingungen

>>Welche Queries konkret werden langsamer und wie sieht der Queryplan und die Tabellendefinition der beteiligten Tabellen aus?
Wenn ich mich definitiv für Postgresql entschieden habe, werde ich sicher in diese Detaillierung gehen müssen. Momentan, geht es mich darum zu spüren, ohne große Zeitaufwand, ob Postgresql meine Anforderungen abdecken kann. Vielleicht, könnte ich meine Queries anders formulieren dass diese Verlangsamung kompensiert wird.

>>Mysql ist nur darum schnell, weil es sich um fast gar nichts kümmert, was eine DB braucht ... jedenfalls in der Standardkonfiguration.
Gibt es auch für Postgresql eine „Standardkonfiguration“? Wenn ja, es wäre genau was ich suche.

ads
Erfahrener Benutzer
Beiträge: 4151
Registriert: Mi 8. Feb 2006, 10:58
Wohnort: MD
Kontaktdaten:

Beitrag von ads »

Die Präferenz von Mysql ist: schnell sein, Datensicherheit ist sekundär.

PostgreSQL geht genau den anderen Weg: deine Daten sind das, was deine Firma, dein Projekt oder deine Idee am Leben erhält. Also dürfen die nicht verloren gehen. Man kann auch in PostgreSQL fast soweit gehen wie in Mysql, dann hat man ohne Ende Performance ... kann aber auch gleich wechseln.

Ansonsten kann ich die Erfahrung weitergeben, das etwas Beschäftigen mit SQL, Normalisierung und das Betrachten eines EXPLAIN ANALYZE Outputs mehr bringen als viele Configänderungen. Aber das ist immer von Fall zu Fall unterschiedlich.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören Bild

Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

PostgreSQL Service & Support

hretif
Benutzer
Beiträge: 39
Registriert: Mo 6. Nov 2006, 18:36

Beitrag von hretif »

Danke ads. Jetzt kann ich etwas mehr nachvollziehen und entsprechend meine Entscheidungen treffen.

Ich werde deinen Rat nachgehen und wenn ich was entdecke, werde ich es hier melden

hretif
Benutzer
Beiträge: 39
Registriert: Mo 6. Nov 2006, 18:36

Beitrag von hretif »

Hallo,
Ich bin jetzt mit PG ganz zufrieden...
Die Situation war wie folgt:

Ich habe eine Art von Master Tabelle gehabt. Wenn die Applikation von ein Rekord zu andere gegangen ist, wurde sehr viele SELECT generiert um Daten von Detail Tabelle zu holen.

Diese Situation hat zwar MySql schneller als PG gehandelt aber diese Entdeckung hat ein unsauberes Teil vom Code hervorgehebt.

Ich habe alle SELECTs in eine zusammengefasst mit Hilfe von derived table:

select * from
(select opt.id_constructor,opt.id_options,opt.option_name,co.id_car_data
from options opt
left outer join car_options co on
co.id_options=opt.id_options and co.id_car_data=205
) as tmp
where id_constructor=5 or id_constructor=0

und jetzt ist die Applikation mit PG gleich schnell wie früher, wenn nicht schneller.

Ausserdem, je mehr ich PG entdecke desto besser fühle ich mich…

ads
Erfahrener Benutzer
Beiträge: 4151
Registriert: Mi 8. Feb 2006, 10:58
Wohnort: MD
Kontaktdaten:

Beitrag von ads »

hretif hat geschrieben:Ausserdem, je mehr ich PG entdecke desto besser fühle ich mich…

Und wieder einer ;-)
Da müssen wir gar nicht belehren, bekehren oder beknien, die Leute entdecken das einfach und sind zufrieden.

Allerdings kannst du bei PG auch ein falsches Datenbank Design teuer bezahlen, das hast du ja gesehen. Von daher sollte man etwas Ahnung haben von dem, was man da tut, programmiert oder administriert.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören Bild

Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

PostgreSQL Service & Support

akretschmer
Erfahrener Benutzer
Beiträge: 7714
Registriert: So 29. Okt 2006, 13:35
Wohnort: Kaufbach, Sachsen, Germany, Germany
Kontaktdaten:

Beitrag von akretschmer »

hretif hat geschrieben:Hallo,
Ich bin jetzt mit PG ganz zufrieden...
Die Situation war wie folgt:

Ich habe eine Art von Master Tabelle gehabt. Wenn die Applikation von ein Rekord zu andere gegangen ist, wurde sehr viele SELECT generiert um Daten von Detail Tabelle zu holen.

Diese Situation hat zwar MySql schneller als PG gehandelt aber diese Entdeckung hat ein unsauberes Teil vom Code hervorgehebt.

Ich habe alle SELECTs in eine zusammengefasst mit Hilfe von derived table:

select * from
(select opt.id_constructor,opt.id_options,opt.option_name,co.id_car_data
from options opt
left outer join car_options co on
co.id_options=opt.id_options and co.id_car_data=205
) as tmp
where id_constructor=5 or id_constructor=0

und jetzt ist die Applikation mit PG gleich schnell wie früher, wenn nicht schneller.

Ausserdem, je mehr ich PG entdecke desto besser fühle ich mich…



Das ist doch mal fein.

Was mir noch so einfällt beim querlesen:
- select * ist böse. Okay, in diesem Fall ist das nur von einer Zwischentable, aber man sollte
sich das ned erst angewöhnen (okay, ich mach es auch...)
- Indexe und EXPLAIN. Bei Performance-Problemen ist EXPLAIN die erste Anlaufstelle.
Merken!
- wilde Vermutung: wenn Du die äußere WHERE-Condition gleich mit im inneren anbringst
könnte es noch schneller werden. Deine Innere Abfrage liefert wahrscheinlich deutlich mehr,
als die äußere letztendlich als Result ergibt.
(das 'id_constructor=5 or id_constructor=0' meine ich)
- welche Version hast Du? PG kann in einem SELECT mehrere Indexe nutzen, und seit 8.1
kombiniert es diese zu 'In Memory Bitmap Index Scan'. Bei vielen WHERE-Bedingungen
wirkt das wie ein Nachbrenner...

EXPLAIN!!!


Andreas

Antworten