Was ist denn das?
Nicht alle Tabellen benutzen die Storage-Engine InnoDB nach Update auf 5.4
- Multis Fratribus
- Thread is marked as Resolved.
-
-
Klappt das auch mit anderen Plugins, die dann wieder die Suche verändern?
-
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.
-
Erweiterte Suche - Suchdropdown mit Vorschlägen - WoltLab®Endlich auch für die neuste Version der WoltLab Software verfügbar: Die erweiterte Suche mit Suchdropdown. Das modulare Plugin erlaubt es Ihren Besuchern in…www.woltlab.com -
Das beides läuft, ist schön und gut. Aber es ändert nichts an der Tatsache, dass die Erweiterung seit jeher kein elasticsearch nutzt.
-
Hilft mir das jetzt?
-
Falls es um die erweiterte Suche geht: Die kann kein elasticsearch und zwingt große Webseiten zwangsläufig in die Knie.
Kann ich so nicht bestätigen.
-
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.
-
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.
-
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.
-
Display More
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.
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.
-
Wo finde ich das denn?
In der my.ini
-
Und natürlich hat der Server HDD...
Dann darfst du dich aber auch nicht wundern, dass die SQL-Operationen langsam abgearbeitet werden....
-
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!
