Nicht alle Tabellen benutzen die Storage-Engine InnoDB nach Update auf 5.4

  • Klappt das auch mit anderen Plugins, die dann wieder die Suche verändern?

    Definiere "die dann wieder die Suche verändern".


    Meist bauen die Plugins ja nur auf entsprechende Schnittstellen in der Forensoftware auf. Ob da dann eine Suche basierend auf MySQL oder auf Elasticsearch dahintersteckt, kriegen die gar nicht mit.

  • Falls es um die erweiterte Suche geht: Die kann kein elasticsearch und zwingt große Webseiten zwangsläufig in die Knie.

  • Falls es um die erweiterte Suche geht: Die kann kein elasticsearch und zwingt große Webseiten zwangsläufig in die Knie.

    Hatte damit bis dato noch keinerlei Probleme, auch in Verbindung mit ES nicht, habe beides laufen.

    Greetz

    Dark


    Mit dem Ende naht der Anfang mit etwas Neuen, um dann wieder zu sagen „Nach dem Update ist vor dem Update“. :S

  • Das beides läuft, ist schön und gut. Aber es ändert nichts an der Tatsache, dass die Erweiterung seit jeher kein elasticsearch nutzt.

    Dann scheint bei mir die Erweiterte Suche wohl eine Telepathische Verbindung zur ElasticSearch zu haben, da in meiner Datenbank keine der relevanten search_Index in Nutzung sind, jedoch liefert die Erweiterte Suche alle Ergebnisse nach denen gesucht wird. ;)

    Hilft mir das jetzt?

    Wirklich Helfen eher weniger, aber ich würde dir echt zur ElasticSearch raten, das ganze ist echt eine extreme Erleichterung für deine Datenbank und auch performanter als die MySQL Suche.

    Greetz

    Dark


    Mit dem Ende naht der Anfang mit etwas Neuen, um dann wieder zu sagen „Nach dem Update ist vor dem Update“. :S

  • Dann scheint bei mir die Erweiterte Suche wohl eine Telepathische Verbindung zur ElasticSearch zu haben, da in meiner Datenbank keine der relevanten search_Index in Nutzung sind, jedoch liefert die Erweiterte Suche alle Ergebnisse nach denen gesucht wird. ;)


    Das hat weniger mit Telepathie zu tun, als damit, dass dir die Funktionsweise der Erweiterung offensichtlich nicht geläufig ist. Ist aber nicht weiter schlimm. Wenn es für dich funktioniert, ist doch alles tutti.

  • Irgendwie hilft mir das nicht.

    Ich habe die Datei natürlich lokal gesichert.


    Würde es helfen, wenn ich die Datei den Download irgendwie anpasse und dann als InnoDB hochlade.

  • Alternativ die Tabelle leeren, dann auf InnoDB umstellen (lassen) und anschließend die Suchindizes neu aufbauen lassen.

    Das mache ich gerade - und es ist für mich und meine Community eine große Herausforderung.

    Es läuft für knapp 1 Mio Posts jetzt gerade schon 5 Stunden und wir sind bei knapp einem Drittel.

    Die Hochrechnung von mir sagt, wir sind nach weiteren 13 Stunden fertig.


    Das kann es doch nicht sein.

    Sorry.


    Letztlich muss ich sagen, dass WBB für große Foren mit solchen Dingen ungeeignet ist.

    • Official Post

    Das riecht verdächtig nach innodb_flush_log_at_trx_commit = 1, was bei sehr hohem I/O die Performance komplett in die Tonne tritt. Getoppt wird dies eigentlich nur noch durch den Einsatz von HDDs.


    MySQL skaliert miserabel bei solchen Operationen, weshalb man bei großen Datenbanken um eine passende Konfiguration nicht herumkommt. Oder man nutzt Elasticsearch/OpenSearch, wie wir es beispielsweise konsequent in der WoltLab Cloud anbieten, und drei Millionen Beiträge sind ruck-zuck durch.

  • Das riecht verdächtig nach innodb_flush_log_at_trx_commit = 1, was bei sehr hohem I/O die Performance komplett in die Tonne tritt.

    Wo finde ich das denn?


    Und natürlich hat der Server HDD... ;)


    BTW: es ist diese Nacht irgendwann bei 51% stehen geblieben. Darauf habe ich das heute Morgen abgebrochen und eine andere Lösung gemacht.


    Natürlich hatte ich vorher die Tabelle als SQL lokal gesichert. Dann habe ich händisch mir andere WBB-SQL-Dateien mit InnoDB angeschaut. Der einzige Unterschied war, das beim Create-Befehl statt MyIsam dort nun InnoDB steht.

    Also habe ich das händisch geändert im Editor, auf den Server hochgeladen und per mysql-Befehl in der Konsole die Tabelle wieder in die DB gepackt. Das ging in keinen 10 Minuten.

    • Official Post

    Und natürlich hat der Server HDD... ;)

    Mit SSD und einer passenden Konfiguration dürfte der gesamte Prozess irgendwo bei ~1h liegen. MySQL ist generell sehr stark von der Latenz des Datenträgers abhängig und mit HDDs versaut man sich dies ordentlich. Bei Schreiboperationen ist das noch viel schlimmer, weil diese nicht aus einem Cache bedient werden können.


    Auch der normale Betrieb profitiert signifikant von SSD-Speicher. Falls hier ein alter Server mit entsprechend alter Hardware zum Einsatz kommt: Zum selben Preis bekommt man i.d.R. schnellere Hardware mit SSD, der Geschwindigkeitsunterschied ist enorm.

  • Dann darfst du dich aber auch nicht wundern, dass die SQL-Operationen langsam abgearbeitet werden....

    Muss ich denn alle 2-3 Jahre den Server wechseln? Meiner ist von 2020 und der hatte noch HDD.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!