Mit “lucene” getaggte Einträge von rainboxx - Matthias Dietrich
Demletzt gab es im Netz eine Reihe von Artikeln über die Wichtigkeit von Suchmaschinen in Websites bzw. Communities. Es wurde angesprochen, auf was man Wert legen sollte und was Suchmaschinen eigentlich genau machen. Ich hatte mich ursprünglich darüber gefreut und gleichzeitig gewundert, dass es auf diesem Blog zu finden war, wurde dann aber bald enttäuscht: die Artikelreihe ging nicht in die Tiefe, sondern wollte den Leuten sagen, dass es besseres gibt als eine LIKE-Suche. Der Artikel ist übrigens auf Gründerszene zu finden.
In mindestens einem meiner schlummernden Projekte habe ich eine Suchmaschine eingeplant. Bisher war ich ziemlich auf Lucene aus - einfach aus dem Grund: es ist weit verbreitet und ich selbst habe (noch) nicht viel Ahnung vom Aufsetzen und richtigen Konfigurieren. Die Hoffnung war, entsprechende Dokumentation und Hilfe aus der Community zu finden, so dass die Suchmaschine erstmal ganz ok funktioniert und später erweitert werden kann. Eine LIKE-Suche kam allerdings nie in Frage.
Gestern, am Eröffnungstag des 11. Deutschen Perl Workshops in Frankfurt im Haus der Jugend, hatte ich die Session von Andreas Scherbaum besucht, die den Titel "PostgreSQL optimieren und mit Perl kombinieren" gehalten hatte (die alternative Session von Alvar Freude mit dem Titel "42 Goldene Regeln für Perl im Unternehmenseinsatz" war für mich nicht interessant). Neben vielen nützlichen Tipps und Internals, bei denen einige noch neu für mich waren, wurde die in PostgreSQL integrierte Volltextsuche angesprochen. Die Volltextsuche von MySQL habe ich schon im praktischen Einsatz bei einem Kunden gesehen und verwendet, hatte mich aber nie vom Hocker gehauen. Denn diese Indexiert einfach nur die Wörter, die in einer Spalte enthalten sind, damit man einfacher darüber suchen kann. Doch die von PostgreSQL ist ein wenig mehr...
PostgreSQL hat einen integrierten Stemmer
Was ist ein Stemmer? Ein Stemmer generiert Grundformen vom Wörtern. Enthält ein Text z.B. das Wort "Katzen", wird daraus (je nach Stemmer unterschiedlich) "Katz". Ebenfalls werden die Suchanfragen durch den Stemmer gejagt, so dass der Text bei der Suche nach "Katze" und "Katzen" gefunden wird. Es werden somit Konjugationen, Mehrzahlformen etc. vereinheitlicht - und das ist viel Wert.
PostgreSQL unterstützt viele Sprachen und lässt sich flexibel erweitern bzw. man kann seinen eigenen Stemmer schreiben. Dabei ist es egal, ob es sich um Wörter oder Zahlen handelt. Z.B. könnte man auch Artikelnummern "normalisieren".
Stop Words werden gefiltert
Stop Words oder auch Stoppwörter sind sehr häufig in Texten vorkommende Wörter. Im Deutschen z.B. "das", "ist", "ein", "was", "es", etc. Eine Suche nach einem kurzen Satz, der eines dieser Wörter findet, würde jeden Text finden. Um das zu vermeiden, werden Stop Words definiert, die beim Indexieren herausgefiltert werden, um auch wirklich das zu finden, was man wirklich suchen möchte.
Die Stop Words können ebenfalls definiert und abgeschaltet werden. Das kann durchaus Sinn machen, man sollte das aber nicht ohne Grund tun.
Macht das denn alles Sinn in einer Datenbank?
Ja, das ist eine gute Frage. Datenbanken sind zwar dazu da, Texte und Daten zu speichern. Eine Datenbank als Suchmaschine zu verwenden, scheint allerdings recht abwägig. Ich bin auch der Meinung, dass das nicht der beste Weg ist, allerdings für die erste Version einer Suchmaschinenwebsite scheint es durchaus passend zu sein: man kann gezielt suchen, die Suchbegriffe durch AND's und OR's erweitern und erhält akzeptable Suchergebnisse bei scheinbar auch etwas höherer Last.
Das Problem: es skaliert nicht. Verwendet man eine Datenbank für die normalen Daten und zusätzlich als Suchmaschine, kann man die nicht einfach so auf eine weitere Hardware schieben und parallel suchen. Man müsste die Datenbank clustern oder replizieren, was recht aufwändig ist. Es bleibt also meistens bei einer Datenbank, und bei vielen Suchanfragen werden die Resourcen knapp und dies beeinträchtigt die normalen Datenabfragen. Eine Suchmaschine wie Lucene kann man dagegen recht einfach auf mehrere Rechner verteilen und den Index wie scp oder rsync ständig aktuell halten. Das skaliert dann auch.
In mindestens einem meiner schlummernden Projekte habe ich eine Suchmaschine eingeplant. Bisher war ich ziemlich auf Lucene aus - einfach aus dem Grund: es ist weit verbreitet und ich selbst habe (noch) nicht viel Ahnung vom Aufsetzen und richtigen Konfigurieren. Die Hoffnung war, entsprechende Dokumentation und Hilfe aus der Community zu finden, so dass die Suchmaschine erstmal ganz ok funktioniert und später erweitert werden kann. Eine LIKE-Suche kam allerdings nie in Frage.
Gestern, am Eröffnungstag des 11. Deutschen Perl Workshops in Frankfurt im Haus der Jugend, hatte ich die Session von Andreas Scherbaum besucht, die den Titel "PostgreSQL optimieren und mit Perl kombinieren" gehalten hatte (die alternative Session von Alvar Freude mit dem Titel "42 Goldene Regeln für Perl im Unternehmenseinsatz" war für mich nicht interessant). Neben vielen nützlichen Tipps und Internals, bei denen einige noch neu für mich waren, wurde die in PostgreSQL integrierte Volltextsuche angesprochen. Die Volltextsuche von MySQL habe ich schon im praktischen Einsatz bei einem Kunden gesehen und verwendet, hatte mich aber nie vom Hocker gehauen. Denn diese Indexiert einfach nur die Wörter, die in einer Spalte enthalten sind, damit man einfacher darüber suchen kann. Doch die von PostgreSQL ist ein wenig mehr...
PostgreSQL hat einen integrierten Stemmer
Was ist ein Stemmer? Ein Stemmer generiert Grundformen vom Wörtern. Enthält ein Text z.B. das Wort "Katzen", wird daraus (je nach Stemmer unterschiedlich) "Katz". Ebenfalls werden die Suchanfragen durch den Stemmer gejagt, so dass der Text bei der Suche nach "Katze" und "Katzen" gefunden wird. Es werden somit Konjugationen, Mehrzahlformen etc. vereinheitlicht - und das ist viel Wert.
PostgreSQL unterstützt viele Sprachen und lässt sich flexibel erweitern bzw. man kann seinen eigenen Stemmer schreiben. Dabei ist es egal, ob es sich um Wörter oder Zahlen handelt. Z.B. könnte man auch Artikelnummern "normalisieren".
Stop Words werden gefiltert
Stop Words oder auch Stoppwörter sind sehr häufig in Texten vorkommende Wörter. Im Deutschen z.B. "das", "ist", "ein", "was", "es", etc. Eine Suche nach einem kurzen Satz, der eines dieser Wörter findet, würde jeden Text finden. Um das zu vermeiden, werden Stop Words definiert, die beim Indexieren herausgefiltert werden, um auch wirklich das zu finden, was man wirklich suchen möchte.
Die Stop Words können ebenfalls definiert und abgeschaltet werden. Das kann durchaus Sinn machen, man sollte das aber nicht ohne Grund tun.
Macht das denn alles Sinn in einer Datenbank?
Ja, das ist eine gute Frage. Datenbanken sind zwar dazu da, Texte und Daten zu speichern. Eine Datenbank als Suchmaschine zu verwenden, scheint allerdings recht abwägig. Ich bin auch der Meinung, dass das nicht der beste Weg ist, allerdings für die erste Version einer Suchmaschinenwebsite scheint es durchaus passend zu sein: man kann gezielt suchen, die Suchbegriffe durch AND's und OR's erweitern und erhält akzeptable Suchergebnisse bei scheinbar auch etwas höherer Last.
Das Problem: es skaliert nicht. Verwendet man eine Datenbank für die normalen Daten und zusätzlich als Suchmaschine, kann man die nicht einfach so auf eine weitere Hardware schieben und parallel suchen. Man müsste die Datenbank clustern oder replizieren, was recht aufwändig ist. Es bleibt also meistens bei einer Datenbank, und bei vielen Suchanfragen werden die Resourcen knapp und dies beeinträchtigt die normalen Datenabfragen. Eine Suchmaschine wie Lucene kann man dagegen recht einfach auf mehrere Rechner verteilen und den Index wie scp oder rsync ständig aktuell halten. Das skaliert dann auch.

Feed dieses Blogs abonnieren
Neueste Kommentare
Philipp on Schade: kein erweiterter Heise-Newsfeed: Hi, ich wü
Ano Nym on Schade: kein erweiterter Heise-Newsfeed: Ich würde
Jonas on Schade: kein erweiterter Heise-Newsfeed: Ich wäre a
mots on Schade: kein erweiterter Heise-Newsfeed: Ich würd d
Bastian on Zwei Jahre ist es her...: Hej, willk
Heiko W. Rupp on PostgreSQL und Volltextsuche: Im letzten
Josef on Schade: kein erweiterter Heise-Newsfeed: Würde mich
Martin on Schade: kein erweiterter Heise-Newsfeed: ich reihe
Guido on Schade: kein erweiterter Heise-Newsfeed: Dich hätte