Hallo Michael!
ups - in Verdana kann ich davon nichts lesen.
ah ja, eigene CSS...
Innerhalb der Textarea dann schon: Ah, ja.
Die Tabelle wort_in_postings ist diejenige, welche von FULLTEXT quasi implizit erzeugt wird.
Was ich jetz imme rnoch nicht genau verstanden habe - erstellt FULLTEXT jetzt eine interne Tabelle wie oben, oder einen B-Baum? SO wie ich das jetzt verstanden habe wohl ersteres, aber wo ist das noch logarithmisch?
Dann weiß ich allerdings nicht, warum Du zwischen wort_ID und wort_STRING noch einen JOIN machen willst, wo Du doch auch beide Tabellen über die ID verschmelzen kannst. Die ID muß in _dieser_ Tabelle nicht unique sein - sie muß nur einen unique-Zugriff in postings erlauben.
Ja, dann hat man das ganze halt nicht mehr so "schön relational", aber der JOIN ist vermutlich teurer als der zusätzlich erzeugte IO-Traffic durch "unnötige" mehrfache Speicherung, oder?
Genau. Und FULLTEXT würde von der Datenbank sogar noch seitenweise ein- und ausgelagert ...
Was meinst Du mit "seitenweise"?
das macht Perl mit seinem Hash vielleicht auch, aber ich fürchte, Du mußt die Daten bei der Perl-Lösung wenigstens einmal komplett "durch den Speicher schießen", bevor sie in der paging area landen.
"paging area"? Was ist das?
Wenn Du den Faktor 10 zwischen RAM und Platte damit bezahlst, den kompletten Index und damit tausendmal so viel wie notwendig einlesen zu müssen, dann hast Du nichts gewonnen.
Ist doch dasselbe wie bei dem unnötigen Join, ich werde schneller und bezahle das mit mehr Speicher, scheint öfter so zu sein. Die Frage ist nur ob man ein System was immer komplett auf die Festplatte zugreifen muß so schnell bekommt? Denn wie schnell ist nochmal eine IDE Leitung? War glaube ich praktisch nicht mehr als 50MB/sekunde, und wie macht das die Datenbank? Die mußt doch erstmal die _komplette_ Tabellendatei, oder besser gesagt die Fulltext_index Datei von der Festplatte holen, mit allem drum und dran(alte Archive...) sind das gut und gerne 250 MB, was also schonmal 5 Sekunden dauert, wenn man die komplette Bandbreite 5 Sekunden für eine einzige Suchanfrage zur Verfügung hat. Der Rest geht dann echt flott, aber gerade das ist glaube ich das Problem bei mir! Und bei meinem 133er DDR SDRAM ist die Rate immerhin bei 2,1 GB/sekunde, zumindest theoretisch, aber das wäre schonmal der Faktor 40, also deutlich mehr als 1 Zehnerpotenz!
Gut, bei mir sind es nur 110 MB die der Index groß ist, also dürfte ich noch andere Probleme haben, und Ihr habt doch SCSI, und RAID (welches?), wordurch ihr ja doch an erheblich höherer Raten gelangen könntet, aber wie gesagt, die Suche ist ja nicht alles was auf dem Server läuft! Da sehe ich auch den Vorteil in der Verzeichnisbaum-Version, da muß nicht viel von der Festplatte geholt werden, das Sortieren geschieht einfach mit dem Verzeichnisbaum, also logarithmisch und nicht linear => 2 Vorteile in einem.
Aber mit hinzufügen von Informationen könnte wirklich kritisch werden, wobei, das würde sowieso ein Script erledigen und ich wüßte jetzt nicht wo das Problem liegen sollte, naja, aber das eine Datenbank da einfacher sein wird glaube ich sehr wohl.
Genau. Und die sind so unscharf, daß sie auf die schwarze Liste gehören.
Ja! Hab ich ja, aber das bringt sooo viel auch nicht! Das Wort kommt nunmal vor und muß dem entsprechend auch gesucht werden.
Bei guten Suchbegriffen bist Du deutlich schneller geworden, dachte ich? Oder sind es immer erst mal 5 Sekunden, egal was Du suchst?
Ich bin bei seltenen eher langsamer(bei wiederholter(ge-cachter) Suche) geworden, das war früher sauschnell, aber durch das vorsortieren der Begriffe... geht natürlich Zeit verloren, aber das macht eigentlich nicht viel, bei schlechten Suchbegriffen habe ich mich deutlich verbessert, von sagen wie mal 20 Sekunden am Anfang, auf 5 Sekunden, halt wegen der Sorterung. Genau wie bei seltenen BEgriffen, da bin ich jetzt auch schon bei der ersten Suchanfrage akzeptabel schnell(1-2 Sekunden). Aber sobald ein Wort wie Javascript in der Query vorkommt, bin ich bei den blöden 5 Sekunden, und beim 4. mal immer noch über 1 Sekunde. Bei 1 oder 2 seltenen Wörtern bin ich wie gesagt sofort ziemlich schnell, ca. 1 Sekunde und danach noch schneller. Aber Deine Suche ist meiner durch die Modifikationen in _allen_ Belangen überlegen(schneller), früher war ich wenigstens wenn ich Anfragen im Cache hatte recht flott, das bin ich jetzt nicht mehr(in dem Maße, dafür halt beim 1. mal verbessert). ich guck mal ob ich das ganze gleich mal auf einen echten Webserver hochladen kann, dann kannst Du Dir selbst ein Bild machen. Das Problem ist da nur, dass ich vermutlich keinen Thread so lange laufen lassen kann, bis der Fulltext-Index fertig ist, mal schaun.
Bei dieser Anforderung ist "opener" der 'gute' Suchbegriff, der die Sache schnell macht. Und da er nicht auf der schwarzen Liste steht, im Gegensatz zu "javascript", weißt Du auch, wie Du diese beiden Begriffe zu sortieren hast ...
Das mach ich ja, dadruch hat sich die Geschwindigkeit von 20 auf 5 Sekunden verbessert! Aber irgendwas mache ich da wohl noch ganz grob falsch! So sieht meine Suche aus:
1. Sortierung der Suchbegriffe
2. generiere Query: "CREATE TEMPORARY TABLE...SELECT...FROM postings WHERE MATCH(...) AGAINST('opener') AND MATCH(...) AGAINST('javascript')"
3. Frage temp-Tabelle ab: "SELECT ... FROM temporäre_tabelle... ORDER BY time"
Schritt 2 ist das Problem, der braucht 99% der Zeit. Nur Suchen gegen _ganz_ seltene Begriffe sind schnell, aber diese Suchen sind auch sehr selten, und vermutlich gar nicht mehr so schnell wenn gleichzeitig 10 Leute nach Javascript, HTML & Co. suchen.
Du bist Dir bewußt, daß dies (über eine entsprechende Notation im Eingabefeld) alles bereits mit der bestehenden Suchfunktion möglich ist? (Ausgenommen die Checkbox - die ist bisher auf "aktiv" festgebrannt.)
Sehr bewußt sogar, ich benutze das auch öfter, vor allem author:"Andreas Korthaus". Was aber nicht funktioniert ist category:"ZU DIESEM FORUM", das geht nicht. Und außerdem:
Wie oft benutzt das jemand: http://webalizer.teamone.de/selfforum/search_200211.htm?
Ich denke so ein Forumlar mit den direkten Eingabe-Möglichkeiten würden mehr Leute benutzen, vor allem "Anfänger", und damit allen anderen den Gefallen tun die Suche erheblich zu entlasten.
Ist auch entspannter mal eben aus einem SelectFeld die KAtegorie auszuwählen, als das komplett als category:"ZU DIESEM FORUM" auszuschreiben. Da bin ich faul ;-)
Durch das vorherige Sortieren der Suchbegriffe kann ich das schonmal erheblich besser in meine Suche einbauen.
Bist Du Dir bewußt, daß Du dann mehr als einen FULLTEXT-Index verwenden wollen wirst?
Nein. Wieso? Ich kann eh nur einen Index verwenden und da _muss_ ich den Fulltext über alle Spalten nehmen. Wozu braucheich einen Volltext-Index bei Kategorie? Da habe ich ja feste Strings die ich vergleiche kann. Ich könnte sogar die Strings in Zahlen umfandeln, halt für jede Kategorie eine Zahl das dürfte nochmal helfen! Bei den Namen ist es egal, wenn ich da instr() verwende, wird die Query kein Stück langsamer. Und Wenn jetz jemand _nur_ seine letzten Postuings sucht, dann könnte man das bestimmt optimieren, aber darum geht es mir vorerst nicht. mit geht es um Eingaben wie :
Suchstring: fsockopen
Autor: Andreas
dann mache ich wieder einen match gegen fsockopen, und danach ein AND instr(author,"Andreas"). DAs geht IMHO sehr gut, auch wenn nicht verstehe wieso. Aber was soll ich sonst machen? Einen Index kann ich eh vergessen, denn fsockopen braucht nunmal unbedingt den Fulltext-Index. Dann muß ich gucken wie ich noch den Namen filtere, "Andreas" ist natürlich kein selten vorkommender Name, aber was will man machen? Denn anders herum, erst alle Postings von "Andreas" mit einem Fulltext über die Spalte Author abzufragen udn dann mit Like oder instr() den Rest, das ist doch vermutlich _erheblich_ schlechter, oder? Wieviele Andreas-Postings gibt es? Sind alleine von mir über 2000 und ich bin nicht der einzige Andreas. Ich denke man sollte das mit dem Fulltext index sein lassen und mal mit einer eigenen Tabelle wie ganz oben geschreiben probieren, da hat man mehr Freiheit und zumindest ich versteh das ganze dann besser, der Fulltext Index ist doch noch irgendwie ein Mysterium für mich, obwohl ich das Kapitel schon mehrfach gelesen habe, ist leider nicht sonderlich lang, und ausführlich, aber wenn das ganze logarithmisch funktionieren würde(was es IMHO nicht tut), dann müßte ich doch wenigstens so Werte wie Deine lineare PERL Suche erreichen, bei so vielen Datensätzen. Ich weiß es nicht aber die Volltext-Suche kann ich irgendwie nicht richtig fassen, ich habe so wenig Einfluß darauf, oder zumindest kann ich meinen Einfluß nicht ausnutzen. Vielleicht hat es auch mit meiner erheblich langsameren "Festplattenanbindung" zu tun, aber auch dann ist der Unterschied immer noch zu groß.
Wenn Du mit derartig komplexen Möglichkeiten anfängst, dann wird die Sache mit der Generierung einer guten Query sehr viel anspruchsvoller. Denn eine Blacklist für Suchbegriffe hat eine ganz andere Wirkung als eine Blacklist für Autoren etc.
Ja, die Query wird deutlich schneller, ist aber immer noch viel zu langsam ;-)
Bisher ging das mit den Datenbanken immer ganz gut, da habe ich mir nie Gedanken über eine Query gemacht, aber das hier ist schon verrückt denn so viele Gedanken wie ich mir gemacht habe(mit Deiner Hilfe), und trotzdem ist noch nicht so viel bei rumgekommen.
Viele Grüße
Andreas