• Wenn du hier im Forum ein neues Thema erstellst, sind schon Punkte aufgeführt die du ausfüllen musst. Das dient im Allgemeinen dazu die notwendigen Informationen direkt mit der Frage bereitzustellen.
    Da in letzter Zeit immer wieder gerne das Formular gelöscht wurde und erst nach 3 Seiten Nachfragen die benötigten Infos für eine Hilfe kommen, werde ich nun jede Fragestellung die nicht einmal annähernd das Formular benutzt, sofort in den Sondermüll schicken.
    Füllt einfach die abgefragte Daten aus und alle können euch viel schneller helfen.

XF2.2 1&1/Ionos sperrt einfach meine Datenbank

Nicht ganz ;)

Wäre interessant das mal zu testen, bisher habe ich nur Benchmarks gesehen bei denen InnoDB FT langsamer ist als MyISAM FT.
Darüber hinaus gebe ich dir Recht - InnoDB FT ist bei MariaDB zickig.

Kommt auf die Konfig an, mit MySQL5.7 und InnoDB konnte ich die gesamte Tabelle im RAM halten. Mit MyIsam und MariaDB habe ich das bisher noch nicht geschafft.
Was ist besser und schneller als Daten direkt im RAM vorliegen zu haben und auch dort gleich zu bearbeiten.. Für mich ist da ES - mit Ausnahme der erweiterten Funktionalität -"eine Krücke". Daten von SQL zu ES, abgleichen, dann noch Java (...) dazwischen.
Das muss in unserem Fall nicht sein. Kommt also immer auch auf den Bedarf an. Wenn man nur Dinge wie ~Foren, wo sich sekündlich Daten ändern, auf dem Server hat dann ist mir ES zwischen SQL-Server und Foren zu viel. Bei Shops, wo die sich Daten nicht so oft ändern, sieht das dann wieder anders aus.

Aber wie es auch sei: FT in MySQL,/MariaDB egal ob MyISAM oder InnoDB, war und ist eine Krücke.
Das mag sein, Krücke hin oder her, mit MySQL 5,7 funktionierte die "Krücke" im Rahmen meiner Erfordernisse und ersparte mir zusätzliche SW wie ES.
Kann ich nicht bestätigen, haben wir nicht.
Auch da würden mich Benchmarks interessieren :)
Benchmarks hätte ich dir früher gerne erstellt, nun allerdings ist das zu spät dafür.
Der Zugzwang, MariaDB anstelle von MySQL zu nutzen ist zu groß als dass ich mich dem entziehen könnte.

Ich wollte/will hier auch MDB nicht heruntermachen. Da ich vor der Umstellung recherchiert habe und es überall heißt MDB 10.4 sei quasi ein MySQL 7.5, nur mit mehr "Features", war ich natürlich etwas pikiert erleben zu müssen, dass das nicht ganz der Wahrheit entspricht.
 
Zuletzt bearbeitet:
Bitte mal bei den Versionsnummern aufpassen - MySQL Cluster 7.5 ist ja nicht MySQL community 5.7

So für mich liest sich das, als wenn du mit MariaDB arbeiten möchtest, als wäre es MySQL 5.7 - es ist aber MariaDB und ist "nur" kompatibel zu MySQL. Um MariaDB gescheit zu nutzen, wirst du nicht umhin kommen, alte Konfigurationszöpfe abzuschneiden und dich in MariaDB einzulernen.

Ist das gleiche wie beim Wechsel von vB zu XF - im Grunde können sie das selbe, nur der Weg dahin ist anders gelöst. ;)
 
Was ist besser und schneller als Daten direkt im RAM vorliegen zu haben und auch dort gleich zu bearbeiten.
Miete dir nen Server mit SSD für die DB und werd happy. ;)


Für mich ist da ES - mit Ausnahme der erweiterten Funktionalität -"eine Krücke".
ES soll ja auch nicht vorrangig dein DB-Turbo sein, sondern soll dir schnellere und bessere Suchergebnisse liefern. Zumindest hab ich das so aufgefasst und setze es genau so ein. Und ES läuft seit Installation praktisch ohne weiteres zutun durch bei mir.
 
Ich erwarte aber von MySQL/MariaDB mehr als du, nämlich dass sich die DB so konfigurieren lässt, dass Boliden wie ES, von der Performance her, obsolet werden.
Das kannst Du vergessen, das wir mit hoher Wahrscheinlichkeit niemals passieren denn es sind völlig unterschiedliche Systeme.
MySQL/MariaDB ist ein (transaktionssicheres) RDBMS, Elasticsearch (startk vereinfach ausgedrückt) ein auf Volltextsuche optimierter Object-Store.

Mit MySQL 7.5.x gelang das, mit MariaDB aufgrund der geschilderten Fehler (Searchindex MyISAM/InnoDB)) nicht.
Das heißt nun für mich 20 Jahre Erfahrung mit der Konfiguration von MySQL in die Tonne treten und (dahingehend) mit MariaDB neu starten :(
Was für ein Unfug :)
Ja, MariaDB ist ein MySQL-Fork und damit natürlich nicht absolut identisch sondern in einigen Punkten abweichend (mitunter andere Syntax, andere Optionen, etc.) - die Basics (ausreichend großer Buffer-Pool, etc.) und die Mathematik zur Berechnung der Einstellungen sind aber die gleichen im großen und ganzen die gleichen.

Für mich ist da ES - mit Ausnahme der erweiterten Funktionalität -"eine Krücke"
Des Menschen Wille ist sein Himmelreich.

Die Datenbank fulltext_test beinhaltet lediglich die Tablle xf_search_index, manuell schnell befüllt mit Forenbeiträgen aus spieleforum.de; der entsprechende ES-Index enthält gut 100K Einträge mehr (Profilnchrichten, etc.) - fairerweise müssten also die MySQL-Daten eigentlich noch ein wenig größer sein aber für die Demonstration denke ich reicht das völlig.

Code:
Elasticsearch
du -s -b /var/lib/elasticsearch/nodes/0/indices/SE7JnjWJQ_6sWKPH477scA | numfmt --to=iec --suffix=B --padding=5
631MB /var/lib/elasticsearch/nodes/0/indices/SE7JnjWJQ_6sWKPH477scA

MariaDB 10.4 MyISAM
du -b --max-depth=1 /var/lib/mysql/fulltext_test | numfmt --to=iec --suffix=B --padding=5
2.1GB /var/lib/mysql/fulltext_test

MariaDB 10.4 InnoDB
du -b --max-depth=1 /var/lib/mysql/fulltext_test | numfmt --to=iec --suffix=B --padding=5
5.9GB /var/lib/mysql/fulltext_test

Dazu dann noch Stemming, indexierbare Attribute, usw.

Ich kann meinen Rasen natürlich mit einer Nagelschere schneiden, funktioniert zweifelsohne - ich bevorzuge dann aber doch eher den Rasenmäher :)
Will heißen: Man sollte nach Möglichkeit halt schon das passende Werkzeug einsetzen, und für Volltextsuche ist das nun einmal ein Volltext-Suchserver und damit eine Aufgabe für Elasticsearch, OpenSearch, Manticore, etc.

Wer ES laufen hat und obiges einmal selbst testen möchte:
Code:
CREATE DATABASE fulltext_test;
CREATE TABLE fulltext_test.xf_search_index LIKE db.xf_search_index;
INSERT INTIO fulltext_test.xf_search_index (content_type, content_id, message, user_id, item_date) (SELECT 'post', post_id, message, user_id, post_date from db.xf_post);

Dann schauen wie groß die DB im Dateisystem ist, danach
Code:
ALTER TABLE fulltext_test.xf_search_index Engine=InnoDB;

Das Ansinnen bei MySQL alles incl. des Suchindex im RAM halten zu wollen halte ich für unsinnig, umsonst ist RAM auch nicht und im Normallfall finden Suchen eher in homöopathischen Dosen statt (im Vergleich zum restlichen Traffic).

Und ES läuft seit Installation praktisch ohne weiteres zutun durch bei mir.
Jup. Das Ding ist ziemlich Install & Forget, läuft einfach.
 
So für mich liest sich das, als wenn du mit MariaDB arbeiten möchtest,
Muss, ich muss, weil Ubuntu20.4 LTS in Verbindung mit Plesk offensichtlich kein MySQL mehr unterstützt.

Warning: The dist-upgrade process from Ubuntu 18.04 to Ubuntu 20.04 is supported with MariaDB scenario only.

Ginge es nach mir wäre MySQL(Orakle) weiterhin mein Favorit, schon um mir das Aneignen der "Neuigkeiten" von MariaDB und den Überraschungen dabei zu ersparen. So sollte z.B. der Bug mit InnoDB FT bei MariaDB seit Version 10 gefixt sein, was er aber offensichtlich nicht ist.
Ebenso nutzt mariadb den Speicher nicht, wie es zuvor mit den selben Einstellungen, Mysql tat, da muss ich auch erst wieder herausfinden warum das so ist.
 
Zuletzt bearbeitet:
(mitunter andere Syntax, andere Optionen, etc.)

Genau das ist das Problem. Auch wenn das große Ganze noch dasselbe ist, der Teufel steckt im Detail, darauf war mein "in die Tonne treten" bezogen.
 
Ich denke niemand zwingt dich Plesk zu nutzen - ergo "musst" du nicht ;)
 
Ich denke niemand zwingt dich Plesk zu nutzen - ergo "musst" du nicht ;)
Boah, solche Krücken von dir?
Es zwingt dich auch niemand zu Essen, ergo "musst" du nicht?

Ich arbeite mit/auf dem System nicht alleine, weitere, nicht so erfahrene Nutzer sind auf die Nutzung von Plesk angewiesen. Ergo muss ich mich bei der Nutzung/Konfiguration von Plesk an deren Voraussetzungen halten. Benötigt ein anderer Nutzer Support heiße es sonst "Hätten Sie mal MariaDB anstatt Oracle-Mysql...".

Bedenke, du machst das beruflich/Vollzeit. Wir müssen derlei nebenher erledigen... ;)
 
Das Ansinnen bei MySQL alles incl. des Suchindex im RAM halten zu wollen halte ich für unsinnig, umsonst ist RAM auch nicht und im Normallfall finden Suchen eher in homöopathischen Dosen statt (im Vergleich zum restlichen Traffic).

Ja, Ram kostet - einmalig. Der Nutzen macht sich jedoch mehr als bezahlt. Ob oder ob Suchen "in homöopathischen Dosen"
stattfindet ist bei meiner Problemstellung unerheblich. wenn ich ein ES installiere, kommt auch hier das "Argument" "in homöopathischen Dosen" zum Tragen, denn warum dafür den ganzen Overhead von Java etc. wenn dafür nur einmalig RAM aufgerüstet werden muss, anstatt immer mehr Software zwischen Datenbank und Suchergebnis zu schalten. Das erscheint mir wie die, die immer mehr Caches quasi in Reihe schalten und sich damit den Geschwindigkeitsvorteil den sie zu erzeugen hoffen ad absurdum führen.

Nicht falsch verstehen, ES hat durchaus seine Berechtigung wo es nötig ist, hier bei uns ist jedoch einfache Wartbarkeit und möglichst wenige Fehlerquellen oberste Prämisse. ES würde ich also erst betreiben, wenn wir ~Shops auf dem Server hätten, wo das Suchen einen ganz anderen Stellenwert hat. Hier ist aber mehr RAM und das im Speicher halten wichtiger, weil weniger Suchen stattfindet. Wie gesagt geht das (nach bisherigen Erkenntnissen) mit MySQL weit besser, denn MariaDB nutzt - mit identischen Einstellungen - den RAM nicht so, wie es zuvor Oracle-MySQL machte. Dafür aber ist nun die CPU-Last höher. Das will und werde ich soweit möglich wieder umkehren müssen.
 
Mach doch mal nen MySQL Suchindex, wo du auch nach Begriffen mit nur 2 Ziffern/Buchstaben suchen kannst - da gehst du bei entsprechend großen Suchindexen ein, so lahm wird das. Nicht umsonst wird doch aber auch immer wieder gesagt, das ES sich erst ab einer gewissen Suchindex-Größe lohnt, oder eben wenn man die Vorteile des Suchservers auch nutzen kann und möchte.


schon um mir das Aneignen der "Neuigkeiten" von MariaDB und den Überraschungen dabei zu ersparen.
Willkommen in der Welt der IT. IT = lebenslanges lernen. Wer das nicht möchte, hat das falsche Hobby.
Versteh mich nicht falsch, ich tu mich mit zunehmendem Alter auch schwerer mit Umstellungen wie bei XF1 auf XF2 oder eben MySQL zu MariaDB (wobei ich hierbei noch keine Probleme zu vermelden hatte, trotz verschiedener Anwendungen auf dem Server (Shopware, Xenforo, Wordpress, Addgini,...), aber das gehört halt nunmal dazu - da müssen wir alle durch. ;)
 
ämlich dass sich die DB so konfigurieren lässt, dass Boliden wie ES, von der Performance her, obsolet werden.
Never! Und nur performance zu vergleichen ist wie Äpfel mit Kartoffeln zu vergleichen.

Wer - egal welches System - die Standardkonfig laufen lässt, macht direkt den ersten Faux Pas. Keine Umgebung sollte im Standard laufen.
 
Schönes Beispiel warum InnoDB FT eher so ... määh ist:
XF 2.2 - Search forums not in the node list

MyISAM FT ignoriert Stopwords einfach, InnoDB FT liefert kein Ergebnis (zumindest bei MariaDB 10.4, habe es nicht mit MySQL getestet da ich da schon seit Jahren eigentlich nix mehr mit mache).
 
Schönes Beispiel warum InnoDB FT eher so ... määh ist:
XF 2.2 - Search forums not in the node list

MyISAM FT ignoriert Stopwords einfach, InnoDB FT liefert kein Ergebnis (zumindest bei MariaDB 10.4, habe es nicht mit MySQL getestet da ich da schon seit Jahren eigentlich nix mehr mit mache).

Ich habe das ganze jetzt mit MariaDB 10.5 und MyIsam am laufen. Funktioniert gut. Stopwords nutze ich nicht, zumindest nicht bewusst.
MariaDB scheint zwar etwas "zickiger", wenn von MySQL her kommt, wenn man sich aber mit den Eigenheiten vertraut gemacht hat finde ich MariaDB inzwischen sogar besser als MySQL (Standard/Community). "Fühlt" sich performanter an, bietet mehr Möglichkeiten, verbraucht aber weniger RAM und hält sich - im Gegensatz zu MySQL, auch unter Ubuntu 18.x an gesetzte Grenzen.
 
Ich habe das ganze jetzt mit MariaDB 10.5 und MyIsam am laufen.
Genau das wurde empfohlen wenn XFES nicht eingesetzt wird ... aber Du fandest ja den Mix blöd ;)

Ich habe das ganze jetzt mit MariaDB 10.5 und MyIsam am laufen. Funktioniert gut. Stopwords nutze ich nicht, zumindest nicht bewusst.
Letzteres.

Full-Text Index Stopwords

\XF\Search\Source\MySqlFt::getStopWords()
PHP:
return [
    'a\'s', 'able', 'about', 'above', 'according', 'accordingly', 'across', 'actually',
    'after', 'afterwards', 'again', 'against', 'ain\'t', 'all', 'allow', 'allows',
    'almost', 'alone', 'along', 'already', 'also', 'although', 'always', 'am',
    'among', 'amongst', 'an', 'and', 'another', 'any', 'anybody', 'anyhow',
    'anyone', 'anything', 'anyway', 'anyways', 'anywhere', 'apart', 'appear', 'appreciate',
    'appropriate', 'are', 'aren\'t', 'around', 'as', 'aside', 'ask', 'asking',
    'associated', 'at', 'available', 'away', 'awfully', 'be', 'became', 'because',
    'become', 'becomes', 'becoming', 'been', 'before', 'beforehand', 'behind', 'being',
    'believe', 'below', 'beside', 'besides', 'best', 'better', 'between', 'beyond',
    'both', 'brief', 'but', 'by', 'c\'mon', 'c\'s', 'came', 'can',
    'can\'t', 'cannot', 'cant', 'cause', 'causes', 'certain', 'certainly', 'changes',
    'clearly', 'co', 'com', 'come', 'comes', 'concerning', 'consequently', 'consider',
    'considering', 'contain', 'containing', 'contains', 'corresponding', 'could', 'couldn\'t', 'course',
    'currently', 'definitely', 'described', 'despite', 'did', 'didn\'t', 'different', 'do',
    'does', 'doesn\'t', 'doing', 'don\'t', 'done', 'down', 'downwards', 'during',
    'each', 'edu', 'eg', 'eight', 'either', 'else', 'elsewhere', 'enough',
    'entirely', 'especially', 'et', 'etc', 'even', 'ever', 'every', 'everybody',
    'everyone', 'everything', 'everywhere', 'ex', 'exactly', 'example', 'except', 'far',
    'few', 'fifth', 'first', 'five', 'followed', 'following', 'follows', 'for',
    'former', 'formerly', 'forth', 'four', 'from', 'further', 'furthermore', 'get',
    'gets', 'getting', 'given', 'gives', 'go', 'goes', 'going', 'gone',
    'got', 'gotten', 'greetings', 'had', 'hadn\'t', 'happens', 'hardly', 'has',
    'hasn\'t', 'have', 'haven\'t', 'having', 'he', 'he\'s', 'hello', 'help',
    'hence', 'her', 'here', 'here\'s', 'hereafter', 'hereby', 'herein', 'hereupon',
    'hers', 'herself', 'hi', 'him', 'himself', 'his', 'hither', 'hopefully',
    'how', 'howbeit', 'however', 'i\'d', 'i\'ll', 'i\'m', 'i\'ve', 'ie',
    'if', 'ignored', 'immediate', 'in', 'inasmuch', 'inc', 'indeed', 'indicate',
    'indicated', 'indicates', 'inner', 'insofar', 'instead', 'into', 'inward', 'is',
    'isn\'t', 'it', 'it\'d', 'it\'ll', 'it\'s', 'its', 'itself', 'just',
    'keep', 'keeps', 'kept', 'know', 'known', 'knows', 'last', 'lately',
    'later', 'latter', 'latterly', 'least', 'less', 'lest', 'let', 'let\'s',
    'like', 'liked', 'likely', 'little', 'look', 'looking', 'looks', 'ltd',
    'mainly', 'many', 'may', 'maybe', 'me', 'mean', 'meanwhile', 'merely',
    'might', 'more', 'moreover', 'most', 'mostly', 'much', 'must', 'my',
    'myself', 'name', 'namely', 'nd', 'near', 'nearly', 'necessary', 'need',
    'needs', 'neither', 'never', 'nevertheless', 'new', 'next', 'nine', 'no',
    'nobody', 'non', 'none', 'noone', 'nor', 'normally', 'not', 'nothing',
    'novel', 'now', 'nowhere', 'obviously', 'of', 'off', 'often', 'oh',
    'ok', 'okay', 'old', 'on', 'once', 'one', 'ones', 'only',
    'onto', 'or', 'other', 'others', 'otherwise', 'ought', 'our', 'ours',
    'ourselves', 'out', 'outside', 'over', 'overall', 'own', 'particular', 'particularly',
    'per', 'perhaps', 'placed', 'please', 'plus', 'possible', 'presumably', 'probably',
    'provides', 'que', 'quite', 'qv', 'rather', 'rd', 're', 'really',
    'reasonably', 'regarding', 'regardless', 'regards', 'relatively', 'respectively', 'right', 'said',
    'same', 'saw', 'say', 'saying', 'says', 'second', 'secondly', 'see',
    'seeing', 'seem', 'seemed', 'seeming', 'seems', 'seen', 'self', 'selves',
    'sensible', 'sent', 'serious', 'seriously', 'seven', 'several', 'shall', 'she',
    'should', 'shouldn\'t', 'since', 'six', 'so', 'some', 'somebody', 'somehow',
    'someone', 'something', 'sometime', 'sometimes', 'somewhat', 'somewhere', 'soon', 'sorry',
    'specified', 'specify', 'specifying', 'still', 'sub', 'such', 'sup', 'sure',
    't\'s', 'take', 'taken', 'tell', 'tends', 'th', 'than', 'thank',
    'thanks', 'thanx', 'that', 'that\'s', 'thats', 'the', 'their', 'theirs',
    'them', 'themselves', 'then', 'thence', 'there', 'there\'s', 'thereafter', 'thereby',
    'therefore', 'therein', 'theres', 'thereupon', 'these', 'they', 'they\'d', 'they\'ll',
    'they\'re', 'they\'ve', 'think', 'third', 'this', 'thorough', 'thoroughly', 'those',
    'though', 'three', 'through', 'throughout', 'thru', 'thus', 'to', 'together',
    'too', 'took', 'toward', 'towards', 'tried', 'tries', 'truly', 'try',
    'trying', 'twice', 'two', 'un', 'under', 'unfortunately', 'unless', 'unlikely',
    'until', 'unto', 'up', 'upon', 'us', 'use', 'used', 'useful',
    'uses', 'using', 'usually', 'value', 'various', 'very', 'via', 'viz',
    'vs', 'want', 'wants', 'was', 'wasn\'t', 'way', 'we', 'we\'d',
    'we\'ll', 'we\'re', 'we\'ve', 'welcome', 'well', 'went', 'were', 'weren\'t',
    'what', 'what\'s', 'whatever', 'when', 'whence', 'whenever', 'where', 'where\'s',
    'whereafter', 'whereas', 'whereby', 'wherein', 'whereupon', 'wherever', 'whether', 'which',
    'while', 'whither', 'who', 'who\'s', 'whoever', 'whole', 'whom', 'whose',
    'why', 'will', 'willing', 'wish', 'with', 'within', 'without', 'won\'t',
    'wonder', 'would', 'wouldn\'t', 'yes', 'yet', 'you', 'you\'d', 'you\'ll',
    'you\'re', 'you\'ve', 'your', 'yours', 'yourself', 'yourselves', 'zero'
];
 
Genau das wurde empfohlen wenn XFES nicht eingesetzt wird ... aber Du fandest ja den Mix blöd

Yup, mit MySQL auch richtig. MariaDB scheint sich (in Version 10.5) derlei Problemen angenommen zu haben und zumindest besseres Caching implementiert zu haben, sodass das nun auch performant laufen kann.
Leider wird nun ein anderes Problem ersichtlich. Ich hab die Suchwortlänge auf 3 Zeichen heruntergesetzt damit man auch nach "SGB", "AOK" etc. suchen kann, leider scheint die Einstellung in XF, bei neueren Versionen, herausgenommen worden zu sein. :(
 
Ich hab die Suchwortlänge auf 3 Zeichen heruntergesetzt damit man auch nach "SGB", "AOK" etc. suchen kann, leider scheint die Einstellung in XF, bei neueren Versionen, herausgenommen worden zu sein. :(
Hmm, kA was Du damit meinst - bei mir gibt es die Einstellung in 2.2.7 genau so wie schon immer.
Screenshot_20211103-064241_Chrome.jpg
 
Stand Gestern: Speicher Datenbank Forum: 9013 von 5368 MB verwendet
Stand Heute: Speicher Datenbank Forum: 9412 von 10737 MB verwendet
(vom 23.09.21)

Stand Heute: 9562 von 10737 MB verwendet

Irgendetwas hat da damals nicht gepasst! Mir kommen aber selbst die 150 MB Plus in den letzten sechs Wochen zu hoch vor.

Bis dato habe ich noch (immer) NICHTS verändert.
 
Guten Abend, Männers. :)

Ich finde diese Daten...

141M FTS_00000000006b9591_000000000086fcd6_INDEX_6.ibd
156M import_log_vbulletin_1.ibd
217M FTS_00000000006b9591_000000000086fccf_INDEX_1.ibd
525M FTS_00000000006b9591_000000000086fccf_INDEX_4.ibd
557M FTS_00000000006b9591_000000000086fccf_INDEX_3.ibd
573M FTS_00000000006b9591_000000000086fccf_INDEX_6.ibd
637M FTS_00000000006b9591_000000000086fccf_INDEX_5.ibd
801M FTS_00000000006b9591_000000000086fccf_INDEX_2.ibd
2.2G xf_search_index.ibd
2.4G xf_post.ibd

..über phpMyAdmin einfach nicht. Hat einer eine Idee wo die sich verstecken, damit ich sie löschen kann? Und kann ich sie auch wirklich bedenkenlos löschen?

WICHTIG: woher rühren diese Daten? Was hat es damit auf sich?

Gruß.
Chris
 
Zurück
Oben