nicht angemeldet
Hallo Miachel!
Danke für die ausführliche Erklährung, habe es zwar noch nicht "umfassend verstanden", aber es wird... ;-)
Keineswegs.
Ein Volltext-Index wird nicht viel anders funktionieren als jeder andere Index auch.
Also wird der Index nicht als binär-baum sondern als interne (index-)Tabelle abgespeichert?
Das verstehe ich aber nicht. Es ist doch genau so linear den Text der Tabelle Datensatzweise zu durchsuchen, als alle Wörter in eine Tabelle zu schreiben um die dann linear zu durchsuchen?!
Das, was Dir mySQL-Fulltext tatsächlich abnimmt, ist:
- Definition einer separaten Tabelle mit zwei Spalten "wort" und "dokument_id".
- Anlegen eines non-unique Index über die Spalte "wort".
- Implementieren eines Wort-Zerlegers, der bei einem INSERT auf Deine Original-Tabelle den Inhalt eines Dokuments in Worte zerlegt und pro Wort ein INSERT in diese separate Tabelle macht.
Ist das </archiv/2002/11/30580/#m165087> in etwa das was Du damit gemeint hast?
Mit beliebig vielen Flat-files - sicher. Denn wie auch immer eine Baumstruktur tatsächlich codiert ist, sie wird auf Speicherseiten abgelegt, und Du kannst mit Flat-files natürlich Speicherseiten emulieren ... ;-)
ich habe eine Idee wie man das vielleicht machen könnte:
Man könnte den Wortzerleger über das Archiv laufen lassen, mit stopwords und allem Schnick-Schnack, und dann aus den erhaltenen Wörtern je ein Verzeichnbis erstellen. Jedes Wort darf nur einmal vorkommen. In Das Verzeichnis kommen dann symb. links auf jedes Posting in dem das Wort vorkam und zwar auf ein unabhängiges Posting-Verzeichnis, in dem alle Postings mit der ID als Dateinamen stehen und mit den Meta-daten als Inhalt: Titel, Autor, Zeitpunkt...
Wie ich mir das jetzt in meiner Naivität gedacht habe, dürfte der Zugriff auf ein spezielles Verzeichnis doch extrem schnell sein, oder?
Auch wenn das dann einige 100.000 Verzeicnisse in einer Ebene sind, es ist doch ein Unique-Name, ich habe keien Ahnung wie sowas vom OS implementiert ist, nur ich hoffe das es sehr schnell ist.
Vemutlich ist da irgendwo ein Haken, oder wieso macht das keiner? Ich stelle mir den Suchvorgang dann so vor:
Jemand gibt in die Suche ein: "Javascript opener"
dann kommt einfach
- öffne Verzeichnis "/bla/bla/javascript" und lese alle enthaltenen Dateien ein
- öffne Verzeichnis "/bla/bla/opener" und lese alle enthaltenen Dateien ein
Die Dateien ggfs. noch auswerten(AND...) und fertig.
Naja, jetzt wo ich das schreibe, dann dürfen im Verzeichnis "javascript" wohl ein paar mehr Dateien stehen die erst geöffnet werden müßten. OK. Das ist blöd. Wenn denn AND-Verknüpfungen vorliegen, dann reicht es ja auch, erstmal nur die Dateinamen, wobei es sich wie gesagt um Posting-IDs handelt, einzulesen, die mit dem anderen Verzeichnis abzugleichen und nur die Schnittmenge zu öffenen. Sollte das denn nciht gehen? Zumal alle diese Vorgänge doch sehr schnell sein sollten, oder irre ich mich?
Wenn das dann doch zu viele Verzeichnisse auf eienr Eben sind, könnte man ja noch mal vorsortieren, meinetwegen mit den 2 oder 3 Anfangsbuchstaben, dann sollte es auf alle Fälle gehen, also so:
"/bla/bla/JAV/Javascript/", oder "/bla/bla/JAV/ascript/"
Und sonst hatte ich noch überlegt, pro Buchstabe einn Verzeichnis, also bei Javascript:
"/bla/bla/J/A/V/A/S/C/R/I/P/T/"
Was sagt Ihr dazu, was habe ich übersehen oder unterschätzt?
Ich habe mir auch Dank Franks Posting ein paar Sachen dazu durchlesen können, bin wie gesagt auch auf Implementierung von B-Bäumen in PERL gestoßen, aber da muß erst der komplette Inhalt in einen Hash geladen werden und der Baum zur Laufzeit erstellt werden, das hate ich unten bereits geschreiben das ich das für wenig optimal halte!
Grüße
Andreas