Hallo Martin und Thomas, Am 11.03.2010 um 19:59 schrieb Thomas Halinka:
Hi Martin,
Am Donnerstag, den 11.03.2010, 11:52 +0100 schrieb Martin Gruner:
Hi Daniel,
ich kann dazu zwar keine verbindlichen Aussagen machen, aber nach meinen Informationen ist InnoDB langsamer. Auch ich möchte hier nochmal der Aussage von Martin widersprechen! Ich habe selbst vielfach gegenteilige Erfahrungen gemacht.
Die Aussage stimmt so nicht. Generell ist InnoDB immer schneller, als myISAM, was durch die Storage-Engine bedingt ist. InnoDB unterstützt im gegenteil zu ISAM zB "clustered Indizes", was dazu führt, dass nicht jedesmal die Tabellen (und Inhalte) ausgelesen werden müssen, da diese im Buffer-Pool von InnoDb liegen, was jedoch auch zu höherem RAM-Verbrauch führt... myISAM wiederum hält nur den Index im Key-Buffer, was dazu führt, dass immer über die komplette Tabelle gerödelt wird und somit langsamer, aber ressourcen-schonender ist....
Wenn es nur kleine Statements (inset blub etc) sind, _kann_ ISAM_ schneller sein, jedoch ist InnoDB generell schneller, vorallem bei großen DBs - vergleich doch mal die Select-Performance. Adaptive Hash Indizes tun ihr übriges dazu..
Generell skaliert InnoDB standard-mässig nicht so gut mit mehreren Threads (parallele Connex + requests), jedoch gibt es hierzu einige Patche von Percona... IMHO sind diese auch in 5.1 direkt drin. Dies ist einer der Gründe warum wir die Datenbank auf einen auf InnoDB optimierten Datenbankserver umziehen möchten. (Info: Gerade die InnoDB- (xtraDB) oder die Google-Patches sind nicht alle Teil vom offiziellen 5.1-Release so dass es sich durchaus lohnen kann die Percona-Version zu benutzen.)
Transaktionen, echte Foreign Keys, row level locking, stored procedures etc bietet myISAM im Gegenteil zu InnoDB nicht - je nachdem was du also noch mit deiner DB anstellen magst , kann das dein Kriterium sein...
Ihr solltet unbedingt ein Testsystem dafür aufsetzen und die Performance messen.
Full ACK
Läuft die Datenbank auf demselben Rechner? Hier würde es sich evtl. anbieten, das auszulagern auf einen hochperformanten DB-Server und mit Replikationen und Slave-Rechnern die Last zu verteilen.
Netzwerk-Latenz mitbedenken....
Einige Lesezugriffe können auch auf der Slave-DB laufen. Evtl. kann auch ein Tuning der mysql-Einstellungen noch Verbesserungen bringen.
schau mal in die my.cnf - da kann man viel mehr rausholen, als die Distris einem mitgeben im default...
Leider muss ich feststellen, dass die Diskussion am Thema vorbei gegangen ist. Dass wir unsere Gründe haben, warum wir gerne die Datenbankengine auf InnoDB umstellen möchten sollte hier nicht gar nicht diskutiert werden. Meine Frage bezog sich eher auf die OTRS-Internals. Vielleicht kann mir aber auch Jemand damit helfen? Muss ich irgendetwas speziell in der OTRS Konfiguration verändern, wenn ich statt MyISAM InnoDB verwenden möchte? Wie sieht es mit der Verwendung von Transaktionen aus? Werden diese dann von OTRS automatisch unterstützt, kann ich dies aktivieren? Foreign-Keys? Oder benutzt OTRS gar MyISAM spezifische Funktionen in bestimmten Tabellen (z.B. Fulltext-Index) so dass für diese eine Umstellung nicht möglich wäre? Mein Problem ist wirklich nicht die Umstellung der db-engine selbst oder gar die Konfiguration des MySQL-Servers sondern ich würde gerne mehr über die Eigenheiten von OTRS erfahren und wie es sich mit einer solchen Umstellung bzw. mit InnoDB verhält. Vielleicht könnt ihr mir auch dazu was sagen?
Herzliche Grüße, Martin Gruner
hth,
thomas
Vielen Dank für eure Mühen Daniel Wagner
Am Mittwoch, 10. März 2010 16:20:53 schrieb Daniel Wagner:
Hallo Zusammen,
wir setzen OTRS (2.2.7) nun schon seit einiger Zeit erfolgreich ein und sind damit auch sehr zufrieden. Wie es nun mal so ist werden die Datenmengen immer größer so dass unsere OTRS-Datenbank mittlerweile eine Größe von ca. 50GB erreicht hat. Dies hat Skalierungs- und Performanceprobleme zur Folge. Um diese Probleme ein wenig einzudämmen würden wir gerne die Datenbankengine von MyISAM auf InnoDB umstellen.
Meine Frage ist nun: Muss ich OTRS irgendwie mitteilen, dass es sich dann auf einer InnoDB-Datenbank befindet? Ist für diese Umstellung irgendeine Konfigurationsänderung auf Seiten von OTRS nötig/ zu empfehlen? Gibt es irgendwelche Best-Practices für eine solche Umstellung im Zusammenhang mit OTRS?
Hinzukommt, dass wir unsere OTRS-Installation demnächst auf OTRS 2.4 aktualisieren möchten da ist meine Frage: Sollte man die Aktualisierung lieber nach oder vor der Umstellung der Datenbankengine vornehmen? Oder ist dies OTRS ziemlich egal?
Viele Grüße und vielen Dank! Daniel Wagner