Textdatei oder Datenbank für Such-Script ?

[Gerd Marstedt]

Ich habe ein site-internes Suchscript erstellt. Es werden alle Dateien indiziert (Zählung der Worthäufigkeit, keywords, title, description usw.) und die Auswertungsergebnisse derzeit in einer Textdatei gespeichert, die für alle HTML-Dateien zeilenweise die jeweiligen Informationen bereit hält:

• Datei 1: Dateiname
• Title
• Description
• Keywords
• Wörter in der Datei (bereinigt um Stoppwörter, getrennt durch Komma)
• Häufigkeit des Wortvorkommens
• Datei 2 ..

Beim Suchaufruf wird dann mit suchen.pl nur diese Datei geöffnet und ermittelt, welche HTML-Seiten die besten Suchergebnisse liefern.

Das läuft schon recht schnell, ich frage mich jedoch, ob es nicht noch eine andere Möglichkeit gibt (anstelle der Text-Datei) die genannten Informationen zu speichern. Immerhin vergeht einige Zeit schon dafür, die einzelnen Zeilen z.B. für Wörter in der Datei mit der Funktion split in arrays umzuwandeln usw.

Wäre die Verwendung einer DB-Datenbank deutlich schneller?

Danke!
Gerd

[RFZ]

Wäre die Verwendung einer DB-Datenbank deutlich schneller?

Eine Volltextsuche in MySQL in einer 260MB großen Datenbank dauert bei mir durchschnittlich 50ms.
Ich denk schon dass das schneller ist ;)

Gerd

cu RFZ

[Philipp Hasenfratz]

Halihallo Gerd

Wäre die Verwendung einer DB-Datenbank deutlich schneller?

Bei kleinen Datenmengen ist die textuelle Verarbeitung über Flat-Files schneller. Aber
je grösser der Datenbestand, desto mehr holt die Verarbeitung über die Datenbank
(bei deinem derzeitigen Such-Algorithmus) auf und wird dann schliesslich viel, viel
besser.
Der Grund dafür ist einfach:
In einer Datenbank kannst du Indizies definieren, diese sind wahre Performancebuster,
da nicht mehr jeder Datensatz der Tabelle durchforstet werden muss, sondern diese
bereits wie in einem Telefonbuch sortiert vorliegen (man stelle sich ein unsortiertes
Telefonbuch vor, da dauert das Auffinden der gesuchten Adresse einige Zeit).

Natürlich könntest du dies auch im Flat-File nachprogrammieren, aber es macht wohl mehr
Sinn, sich auf getestete Datenbanksysteme zu verlassen, die das alles schon per se
mitliefern. Programmierst du den Algorithmus jedoch so um (Verarbeitung von
vorsortierten Listen und binärer Suche), kann's gut sein, dass die Datenbank nie an deine
Performance rankommt; aber ob sich der Zeitaufwand für eine eigene Umsetzung lohnt ist
deine Entscheidung.

Fazit: Bei deinem momentan implementierten Algorithmus (zeilenweises vorrücken und
testen) ist die Datenbank ab einer gewissen (nicht einmal sehr grossen) Datenmenge
eindeutig schneller. Verbesserst du deinen Algorithmus kannst du aber _einiges_
gutmachen; die Frage ist eben wie weit bzw. wie lange du noch weiterprogrammieren
möchtest.

Viele Grüsse

Philipp

[Gerd Marstedt]

je grösser der Datenbestand, desto mehr holt die Verarbeitung über die Datenbank
(bei deinem derzeitigen Such-Algorithmus) auf und wird dann schliesslich viel, viel
besser. Der Grund dafür ist einfach:
In einer Datenbank kannst du Indizies definieren, diese sind wahre Performancebuster,
da nicht mehr jeder Datensatz der Tabelle durchforstet werden muss

Der einzige Index, (der mir einfällt), der für eine schnellere performance sorgen kann, wäre m.E. eine Sortierung der Datei-Wörter nach Anfangsbuchstaben. Dann müsste, wenn der Suchbegriff "Beethoven" ist, nur noch in der Tabellenrubrik "Dateiwörter mit Anfangsbuchstaben B" gesucht werden. Oder gäbe es noch andere sinnvolle und performance sparende Indizes für ein Suchscript? Wie sind denn bei Google (mal abgesehen vom Page ranking) die über robots gesammelten Dateiinformationen und gefundenen Suchwörter indiziert?

[Philipp Hasenfratz]

Halihallo Gerd

Der einzige Index, (der mir einfällt), der für eine schnellere performance sorgen kann, wäre m.E. eine Sortierung der Datei-Wörter nach Anfangsbuchstaben. Dann müsste, wenn der Suchbegriff "Beethoven" ist, nur noch in der Tabellenrubrik "Dateiwörter mit Anfangsbuchstaben B" gesucht werden.
Oder gäbe es noch andere sinnvolle und performance sparende Indizes für ein Suchscript? Wie sind denn bei Google (mal abgesehen vom Page ranking) die über robots gesammelten Dateiinformationen und gefundenen Suchwörter indiziert?

</archiv/2003/8/54963/#m306077> war sehr ausführlich zu diesem Thema.

Viele Grüsse

Philipp

[rolfrost]

hi,

eine gute und sehr performante Alternative zu Textdateien ist das Dateiformat einer ini Datei und der Zugriff via
Config::IniFiles; tie %hash;

Auf meiner WebSuite hab ich derzeit den gesamten Content in einer solchen ini gespeichert, das ist quasi der index und die Volltextsuche mit Text::Query (das Modul ist auch für kommerz. DBs geeignet) ist sehr flott.

Viele Grüße, Rolf

=ein bischen code zur suchfunktion

Suchergebnis ermitteln

sub results{
 my $mode = param('mode');
 my $query_string = trim(param('query_string')) or error("Eingabefehler", "keine Suchbegriffe...");
 form();

my $query = new Text::Query(
  $query_string,
  -mode => $mode
 );

my @resultkeys;
 foreach my $section(keys %content_ini){
  if ( $query->match("$content_ini{$section}{'body'} $content_ini{$section}{'descr'}") ){
   push @resultkeys, $section
  }
 }

....

}

content_ini sieht so aus
#[]
[40.14]
name=Zentrale Darstellung von Daten verteilter Systeme
descr=Clients stellen Informationen an der CGI - Schnittstelle bereit und ein Hauptsystem holt sich diese Daten ab um sie zentral darzustellen... die <i>libwww</i> und das <i>http</i> - Protokoll machen es möglich.
new=1
body= <<EOT
...
EOT

[Philipp Hasenfratz]

Halihallo rolfrost

eine gute und sehr performante Alternative zu Textdateien ist das Dateiformat einer ini Datei und der Zugriff via
Config::IniFiles; tie %hash;

Performant? - Ein INI-File ist immer aperformant, denn es kann in _jedem_ Fall so
abgebildet werden, dass es schneller durchsucht werden kann. Z.B. der Ini-Schlüssel
in jedem Datensatz vorne wiederholen, so könnte man einen B-Tree darauf aufbauen, wenn
die Schlüssel sortiert sind. Bei einer INI-Datei müsstest du selbst dann wesentlich
mehr Daten verarbeiten, da du nie wüsstest, wo der Schlüssel zu finden ist. Bzw. bei
einer schlechten Umsetzung des Verarbeitens einer INI-Datei, die gesamte Datei auf einmal
eingelesen wird.

Auf meiner WebSuite hab ich derzeit den gesamten Content in einer solchen ini gespeichert, das ist quasi der index und die Volltextsuche mit Text::Query (das Modul ist auch für kommerz. DBs geeignet) ist sehr flott.

Wo ist bei dieser Lösung der Index? - Das was du hier beschreibst, entspricht einem
Fulltable-Scan in der Datenbank und hat wenig mit Index zu tun und wohl noch weniger
mit Performance.

Natürlich, bei kleineren Datenmengen ist Deine Lösung OK, aber wenn's in wirklich
grosse Datenmengen geht... Fertig, INI-Datei. Ich muss gestehen, ich sehe hier nicht
ein, was dies mit einer performanten und skalierbaren Umsetzung zu tun hat!?

Viele Grüsse

Philipp

[rolfrost]

hi,

eine gute und sehr performante Alternative zu Textdateien ist das Dateiformat einer ini Datei und der Zugriff via
Config::IniFiles; tie %hash;

Performant? - Ein INI-File ist immer aperformant, denn es kann in

Absolut. tie() sorgt dafür dass die ini an einen hash gebunden wird wobei jedoch nicht die komplette ini datei im Speicher liegt.

teste mal die Suchfunktion auf meiner Suite ;-)

viele Grüße, rolf

[rolfrost]

Halihallo Philipp,

damit es keine Missverständnisse gibt:

Wo ist bei dieser Lösung der Index? - Das was du hier beschreibst, entspricht einem
Fulltable-Scan in der Datenbank und hat wenig mit Index zu tun und wohl noch weniger
mit Performance.

• bei mir ist der gesamte Content in der INI, es gibt keinen Index, die Suche erfolgt direkt im Content.

Aber

• es gibt die Möglichkeit, einen Index auf das Web zu erzeugen und in einer solchen INI abzulegen.

Und mit den genannten Modulen kann ein SuchCGI auf diesen index aufsetzen.

Das ist sozusagen die herkömmliche Variante: Statisches HTML in einer Verzeichnisstruktur, Index erzeugen, Suche im Index.

Meine Gedanken gehen dahin, dass diese Methode für eine Volltextsuche umständlich ist, weil: Wenn ich den Content in einer *DB* habe warum dann nicht gleich im Content suchen?

Text::Query bietet im advanced_mode z.B. den NEAR Operator. Dieser funktioniert _nur_ wenn direkt im Content gesucht wird, weil ein index welcher auf performanze ausgerichtet ist wohl kaum dieselben Textmuster hat wie in einem Dokument (welches indiziert wurde).

Hier noch ein interessantes Modul für DBI:
http://theoryx5.uwinnipeg.ca/CPAN/data/DBIx-TextIndex/DBIx/TextIndex.html

viele Grüße, Rolf

[Philipp Hasenfratz]

Halihallo rolfrost

• bei mir ist der gesamte Content in der INI, es gibt keinen Index, die Suche erfolgt direkt im Content.

Ist für diese Zwecke auch OK. Fulltext-Indizies sind nicht einfach zu erstellen :-)
Besonders wenn Kontext- und Positionsoperatoren wie z.B. NEAR dazukommen.

Aber

• es gibt die Möglichkeit, einen Index auf das Web zu erzeugen und in einer solchen INI abzulegen.

Du bist ein INI-Fanatiker, Rolf :-)
Ja, man kann Indizies damit schreiben.

Und mit den genannten Modulen kann ein SuchCGI auf diesen index aufsetzen.

Das dementiere ich nicht. Ich sage nur, dass Ini-Dateien eigentlich immer weniger
performant verarbeitet werden können, als Text-Files.

Meine Gedanken gehen dahin, dass diese Methode für eine Volltextsuche umständlich ist, weil: Wenn ich den Content in einer *DB* habe warum dann nicht gleich im Content suchen?

Nun ein Nachteil ist bestimmt, dass der Inhalt einer HTML-Datei nicht umbedingt für eine
Suche aufbereitet ist (oder kann bei dir wer nach "<body>" suchen?).

Hier noch ein interessantes Modul für DBI:
http://theoryx5.uwinnipeg.ca/CPAN/data/DBIx-TextIndex/DBIx/TextIndex.html

Oh, vielen Dank! - Kannte ich nicht und wollte es ziemlich genau so selber umsetzen,
jetzt hast du und der Author mir die Arbeit abgenommen :-)

Viele Grüsse

Philipp

[rolfrost]

Hi Philipp;

• bei mir ist der gesamte Content in der INI, es gibt keinen Index, die Suche erfolgt direkt im Content.

Ist für diese Zwecke auch OK. Fulltext-Indizies sind nicht einfach zu erstellen :-)
Besonders wenn Kontext- und Positionsoperatoren wie z.B. NEAR dazukommen.

Also ich hab sowas  aufgegeben und gehe so meinen Weg ;-)
Meine Suite ist ja noch klein... da geht das.

Aber

• es gibt die Möglichkeit, einen Index auf das Web zu erzeugen und in einer solchen INI abzulegen.

Du bist ein INI-Fanatiker, Rolf :-)

hihi, Stimmt. Das sind die Datenbanken des kleinen Mannes...

Ja, man kann Indizies damit schreiben.

Und mit den genannten Modulen kann ein SuchCGI auf diesen index aufsetzen.

Das dementiere ich nicht. Ich sage nur, dass Ini-Dateien eigentlich immer weniger
performant verarbeitet werden können, als Text-Files.

Möglicherweise, ja.

Meine Gedanken gehen dahin, dass diese Methode für eine Volltextsuche umständlich ist, weil: Wenn ich den Content in einer *DB* habe warum dann nicht gleich im Content suchen?

Nun ein Nachteil ist bestimmt, dass der Inhalt einer HTML-Datei nicht umbedingt für eine
Suche aufbereitet ist (oder kann bei dir wer nach "<body>" suchen?).

Du hast meine Volltextsuche also nicht getestet ;-)

body als tag wird nicht gefunden, weil das nicht als tag im Content steht.

Insgesamt ist der Content jedoch nicht extra für die Suche aufgearbeitet und tag - haltig, aber wer such schon nach tags...
Wenn ich mir mein Logfile so anschaue - die verwendeten Suchbegriffe sind immer recht einfach...

Hier noch ein interessantes Modul für DBI:
http://theoryx5.uwinnipeg.ca/CPAN/data/DBIx-TextIndex/DBIx/TextIndex.html

Oh, vielen Dank! - Kannte ich nicht und wollte es ziemlich genau so selber umsetzen,
jetzt hast du und der Author mir die Arbeit abgenommen :-)

Auf jeden Fall werde ich auf Dich zurückkommen (wenn ich darf), wenn das Thema Indizierung für mich mal akut werden sollte.

Viele Grüße, rolf

[Philipp Hasenfratz]

Halihallo Rolf

Aber

• es gibt die Möglichkeit, einen Index auf das Web zu erzeugen und in einer solchen INI abzulegen.
  Du bist ein INI-Fanatiker, Rolf :-)
  hihi, Stimmt. Das sind die Datenbanken des kleinen Mannes...

Du sprichst von Bill Gates? ;)

Meine Gedanken gehen dahin, dass diese Methode für eine Volltextsuche umständlich ist, weil: Wenn ich den Content in einer *DB* habe warum dann nicht gleich im Content suchen?
Nun ein Nachteil ist bestimmt, dass der Inhalt einer HTML-Datei nicht umbedingt für eine
Suche aufbereitet ist (oder kann bei dir wer nach "<body>" suchen?).
Du hast meine Volltextsuche also nicht getestet ;-)

Ich bezog mich nicht auf deine Suche, sondern auf einen allgemeinen Nachteil, wenn man
die Suche gleich im Content der Seiten durchführt.

body als tag wird nicht gefunden, weil das nicht als tag im Content steht.

Eben, du hast die Inhalte aufbereitet. Das ist richtig so.

Hier noch ein interessantes Modul für DBI:
http://theoryx5.uwinnipeg.ca/CPAN/data/DBIx-TextIndex/DBIx/TextIndex.html
Oh, vielen Dank! - Kannte ich nicht und wollte es ziemlich genau so selber umsetzen,
jetzt hast du und der Author mir die Arbeit abgenommen :-)
Auf jeden Fall werde ich auf Dich zurückkommen (wenn ich darf), wenn das Thema Indizierung für mich mal akut werden sollte.

Oh, sehr gerne. Leider sind derart interessante Fragen im Forum nicht alltäglich, gut
wenn das sich etwas ändert.

Viele Grüsse

Philipp