Zu groß für Strato. Wachstum gefährlich.

Beitrag von **Synonym** » 28.01.2010, 16:55

Na dann mach Dein Beispiel doch mal genauer.

In der Spalte "key" nennst Du jetzt z.b. "Schuhe". Oben in der SQL-Abfrage steht "heimarbeit kugelschreiber".

Daher nun eher die Frage. Gibt es nur "heimarbeit kugelschreiber" in der DB oder auch andere Kombinationen mit anderen Begriffen davor bzw. danach z.b. "xxx heimarbeit kugelschreiber yyy"? Und wenn letzteres, sollen die dann auch als Treffer geliefert werden oder nicht, wenn man nach "heimarbeit kugelschreiber" sucht?

Was ist mit der Spalte "alter"? Wird die auch durchsucht oder ist die nur für die Datenausgabe?

von **Anzeige von ABAKUS** »

Beitrag von **euroexchange.de** » 28.01.2010, 17:03

Die Datenbank umfaßt derzeit etwa 130.000 Begriffe. Dies sind teilweise einzelne Wörter aber auch Begriffskombinationen.

Z.B.

"Schuhe" kommt genauso vor wie:
"heimarbeit kugelschreiber" oder auch
"lukrative heimarbeit kugelschreiber" oder
"italienische Schuhmode vom Designer" oder
"Ferienhaus mit Hund und Familie in den Alpen" etc.

Wenn ich jetzt nach allem Suche was ein "a" beinhaltet, und zwar egal was vor und nach dem a steht, dann zeigt er mir natürlich so ziemlich alles an.

Nach Strato-Kriterien könnte ich dann nur noch das abfragen was auch mit "a" anfängt und das wäre nahezu sinnlos.

Zu 2.
Teilweise frage ich die Spalte KEY und teilweise die Spalte ALTER ab.

Beitrag von **Anonymous** » 28.01.2010, 17:07

euroexchange.de hat geschrieben:Nach Strato-Kriterien könnte ich dann nur noch das abfragen was auch mit "a" anfängt und das nahezu Sinnlos.

nö... du kannst auch einfach eine gescheite Volltextsuche verwenden... oder die zusätzlichen Begriffe in einer extra Tabelle schreiben und diese dann per 1:n oder n:m relation mit den ursprünglichen Begriffen verknüpfen und dann einen index setzen auf das Feld mit den begriffen...

Beitrag von **Synonym** » 28.01.2010, 17:08

Hm, dann bleibt Dir da wohl nicht viel mehr übrig, als dir wirklich einen vernünftigen Suchindex zu bilden und dabei dann auch abzuwägen was sinnvoll ist und was nicht. Ein suchen nach "a" finde ich da weniger sinnvoll (Meine Meinung). Ich gehe bei mir da immer min auf 3 Buchstaben raus.

Diesbezüglich hatte auch Mork vom Ork vor ein paar Tagen was geschrieben. Wenn das richtig umgesetzt wird, dann brauchst Du gar keine "LIKE %%". Der Suchindex wird dann zwar riesig, aber dafür auch schnell.

Beitrag von **Synonym** » 28.01.2010, 17:10

Mit der Spalte "alter" ist das dann ja noch schlimmer, da noch mehr Inhalt. Auch die auslagern und entsprechende mit den eigentlichen Werten zu verknüpfen wäre sinnvoller.

Beitrag von **Mork vom Ork** » 28.01.2010, 17:27

net(t)worker hat geschrieben:Es macht nicht viel Sinn ein Index auf ein Feld vom Typ Text zu legen... […] hier bietet sich im Grunde nur eine gescheite Volltextsuche an

Eine Volltextsuche mit all ihren Möglichkeiten verschlingt also deiner Meinung nach weniger Resourcen als ein simpler Textindex? Na, denn mal los …

gescheite Volltextsuche verwenden oder die zusätzlichen Begriffe in einer Extra-Tabelle schreiben […] und dann einen index setzen auf das Feld mit den begriffen

Eben hast du noch geschrieben, ein Index auf die Begriffe macht nicht viel Sinn.

Beitrag von **euroexchange.de** » 28.01.2010, 17:30

Mein Gott. Ich bin ein kleiner Furz im Universum ...

Ich habe pro Tag gerade mal die 10.000-Besuchermarke geknackt und glaube auch nicht das die Besucher die Ursache für die Datenlast sind.

Vielmehr fressen sich die Suchmaschinen durch die Datenbank mit teilweise über hundert Zugriffen pro Minute. Keine Ahnung ob das jetzt viel ist oder nicht ...

Wenn das viel ist, könnte ein Managed Server diese Last problemlos verkraften oder wäre auch das nur eine Frage der Zeit?

Beitrag von **Lord Lommel** » 28.01.2010, 17:36

Dann geht der halt in die Knie, wenn du 100.000 Besucher hast. Wenn es echt bloß an einem Query liegt, dann bist du besser dran, da was zu machen. Genug Ideen gab es hier ja schon. Ich würde es mit den zusätzlichen Tabelle der net(t)workerschen Methode etwas weiter oben machen.

Beitrag von **Pompom** » 28.01.2010, 17:37

Vielmehr fressen sich die Suchmaschinen durch die Datenbank mit teilweise über hundert Zugriffen pro Minute. Keine Ahnung ob das jetzt viel ist oder nicht ...

...nur, wenn du sie fressen lässt. Da gibt es solche Zauberworte wie z.B. Cache oder auch Proxy.

Beitrag von **Mork vom Ork** » 28.01.2010, 17:40

euroexchange.de hat geschrieben:glaube auch nicht das die Besucher die Ursache für die Datenlast sind.

Wer nutzt denn die Suchfunktion?

Vielmehr fressen sich die Suchmaschinen durch die Datenbank mit teilweise über hundert Zugriffen pro Minute.

Nutzen die diese Suchfunktion?

Wenn das viel ist, könnte ein Managed Server diese Last problemlos verkraften oder wäre auch das nur eine Frage der Zeit?

Mit einem größeren Server beseitigst du das Problem nicht, ergo: Letzteres.

"Schuhe" kommt genauso vor wie:
"heimarbeit kugelschreiber" oder auch
"lukrative heimarbeit kugelschreiber" oder
"italienische Schuhmode vom Designer" oder
"Ferienhaus mit Hund und Familie in den Alpen" etc.

Mit solchen Einträgen wird das Finden ein reines Glücksspiel, der Betreiber muss im Voraus raten, nach was für einem Satzteil wohl jemand suchen könnte. Du hast zum Beispiel "Ferienhaus mit Hund und Familie in den Alpen" in der Datenbank. Was machst du, wenn jemand nach "Ferienhaus mit Familie und Hund in den Alpen" sucht? Ist genau das Gleiche, aber geht schon in die Hose, es sei denn, du baust jedwede in der deutschen Sprache denkbare Kombination ein. So wird das nix.

Wenn du eine Suchfunktion willst, dann mindestens auf Basis einzelner Stichwörter, d.h. die Wörter werden einzeln in der Datenbank gespeichert und nicht wie bei dir zu (fast) fertigen Sätzen zusammengebaut.

Beitrag von **euroexchange.de** » 28.01.2010, 17:49

Nach was wurde gesucht, das den Begriff "Ferienhaus" enthielt:

Ergebnis:

"Ferienhaus mit Hund und Familie in den Alpen" und
"Ferienhaus mit Familie und Hund in den Alpen"

So wäre die gewünschte Funktionsweise.

Es werden also nicht Sätze konstruiert sondern tatsächliche Suchanfragen gespeichert.

Beitrag von **Anonymous** » 28.01.2010, 18:23

öhm... hab ich eigentlich schon erwähnt das man das super per Volltextsuche lösen kann... die mysql auch eingebaut, zumindest in den halbwegs aktuellen versionen...

Beitrag von **euroexchange.de** » 28.01.2010, 18:30

Danke nochmal für die rege Hilfestellung.

Das was hier mit Volltextsuche und Verteilung auf mehrere Tabellen angeregt wurde, übersteigt, zum jetzigen Zeitpunkt noch meinen Wissensstand.

Ich kann mir darunter sicher etwas vorstellen, weiß aber noch nicht wie ich es umsetze und ob es das Problem wirklich löst.

Dazu muß ich mich jetzt zunächst in die Materie einlesen und das möglichst schnell, weil meine Seiten sonst aus dem Index fliegen.

Ich berichte dann wie es - und was funktioniert hat.

Beitrag von **euroexchange.de** » 28.01.2010, 19:14

Zur Vorgehensweise bei Strato:

Ich hätte es gut gefunden, wenn man mich bei Abschaltung der Datenbank hierüber informiert hätte. So mußte ich in der Nacht ein Support-Ticket aufgeben um 3 Tage später den Grund zu erfahren warum alle meine Seiten nur noch aus MySql Fehlern bestanden.

============================
Und wieder mal paßt es:

Piep piep tuuut ...

Strato Support Hotline:
Guten Tag. Mein Name ist Franzi Flink. Wie kann ich ihnen helfen.

Kunde:
Hallo. Meine Seite xyz geht nicht mehr.

Strato Support Hotline:
Das tut mir leid ...

PAUSE

Strato Support Hotline:
Kann ich sonst nochwas für sie tun?

Kunde:
Und meine Seite. Die geht nicht ...

Strato Support Hotline:
Ich sagte ja bereits das es mir leid tut.
Wenn sie mich gut fanden, würden sie mich dann bewerten.

Kunde:
/()=&%&=/=/ERZ=)RZE)&P
============================

Beitrag von **Anonymous** » 28.01.2010, 19:31

euroexchange.de hat geschrieben:Ich kann mir darunter sicher etwas vorstellen, weiß aber noch nicht wie ich es umsetze und ob es das Problem wirklich löst.

Dazu muß ich mich jetzt zunächst in die Materie einlesen und das möglichst schnell, weil meine Seiten sonst aus dem Index fliegen.

du weist doch selber das du dir da ein unoptimiertes script "zusammengebastelt" hast, und damit das abschalten der DB selber verursacht hast... da musste nu nicht noch über Strato schimpfen.... die meisten webhoster reagieren so wenn dort ein script die shared DB in die knie zwingt.... ich selber habe schon mehr als einmal bei Hosteurope fremde scripte abschalten lassen weil die die DB, die auch ich dort nutze, zum stillstand gebracht hatten...

jeder der sich mit PHP und mysql wirklich auskennt hätte es von vornherein anders gemacht.... du hättest ja einen Fachmann mal eben einen Blick draufwerfen lassen können und ihm dafür etwas bezahlen können.... nie am falschen Ende sparen.... auch gehören wichtige Projekte auf einem eigenem Server, und nicht irgendwo in ein shared hosting.... sehe den verdioenstausfall die nächsten Tage einfach mal als lehrgeld an....