Cheatah: stopword-list zum SELFForum

Beitrag lesen

Hi,

Ich denke nicht das ich das besser hinbekomme, da mysql das eigenlich schon recht performant macht.

das stimmt schon; dennoch lässt sich ein Layout zumeist optimieren.

Das Problem bereiten mir seltenere Suchanfragen,

Das lässt auf einen schlecht durchdachten Index bzw. die fehlende Nutzung desselben schließen.

Order By über eine Tabelle mit 700.000 Datensätzen ist eine denkbar schlechte Idee!

Nur, wenn man es nicht richtig macht :-)

Erst muß man die Datensätze filtern und danach in einer temporären Tabelle sortieren.

Mich würde interessieren, wie diese Filterung stattfindet. Ich dachte "nur" an ein GROUP BY, und eine temporäre Tabelle wird da höchstens implizit erzeugt.

Es ist einfach absolute Zeitverschwendung wenn die Tabelle größer ist als sie sein muß.

Das ist wohl richtig; eine Tabelle sollte _genau_ die Daten enthalten, die drin sein sollten - nicht mehr und auch nicht weniger. Wenn der Wunsch-Datenbestand da ist, kommt es aber auf das DB-Layout an, wie performant die Abfragen sind, nicht auf die Datenmenge. Sprich: Wenn von den 700.000 Datensätzen nur 500.000 gewollt sind, dann lässt sich die Abfrage trotzdem optimieren, weil ja auch alle 700.000 hätten gewollt sein können.

Mir kommt es _ausschleißlich_ auf Performance an, daher mache ich das überhaupt, und nicht um mir noch eine Bremse oder ein Ranking einzubauen.

Natürlich :-)

Du solltest Dir in erster Linie überliegen, wie Du "sinnlos" definieren möchtest, und was andere - besonders die Suchenden - wohl von dieser Definition halten werden.
Das habe ich,

Nicht wirklich, würde ich sagen. Du willst dreibuchstabige Wörter löschen, welche aber einen sicher nicht unerheblichen Teil der Suche ausmachen.

An dessen Optimierung arbeite ich ja gerade, also an der Tabellenstruktur kann ich nicht viel falsch machen, da es nur eine Tabelle ist,

Darauf will ich hinaus: _Das_ kann bereits das Problem sein.

und einen vernünftigen Fulltext-Index habe ich ebenfalls.

Auch dies muss nicht unbedingt ein Vorteil sein.

Und wie gesagt, mit gecachter Anfrage, alles prima,

Leider irrelevant. Der DB-seitige Cache ist eine _zusätzliche_ Optimierung, die für die eigentliche Performancefrage ohne Belang ist.

Ist die Reihenfolge wirklich so von Bedeutung? Krass.
hätte ich auch nicht gedacht, das hat Michael Schröpl mir kürzlich erklärt, und es stimmt wirklich ;-)

MySQL ist lustig[tm] :-)

Was ich bräuchte sind ein paar Reguläre Ausdrücke die mal so richtig in der Tabelle aufräumen,

Richtig wäre, bereits nur die gewollten Daten in die DB zu schreiben. Da dies ein regelmäßiger Prozess ist (unterstelle ich einfach mal), solltest Du diesen optimieren, den Tabelleninhalt löschen und neu befüllen. Das kann die ganze Nacht dauern oder auch noch länger, völlig egal. Denk nur an Abbruchsicherheit ;-)

Ich habe immer Angst wichtige Dinge zu löschen.

Da Du schwerlich definieren kannst, welche _Begriffe_ wichtig sind, solltest Du Begriffe nicht löschen (eine Stopwordlist kann schon falsch sein - in der Regel ist sie es aber nicht). Was Du mit verhältnismäßig hoher Sicherheit sagen kannst ist, dass alles _außer_ Begriffen, insbesondere Satz- und Sonderzeichen, nicht wichtig sind.

Übrigens ist mein Fulltext-Index größer als die Daten selbst, mit 110:105 MB ;-)

Bei dieser niedlichen Datenmenge ;-) hat das Statement hochgradig performant zu sein, unabhängig von der Zahl der Einträge. Denk noch mal über das DB-Layout nach.

PS: Habe de ganze Zeit schon Probleme mit dem Abschicken "serverseitieg Schwierigkeiten..."

Ja, das passiert mir auch häufiger...

Cheatah

--
X-Will-Answer-Email: No