Ausgegugelt

Inhaltsverzeichnis

Aus der Perspektive eines Benutzers ist eine Suchmaschine leicht zu beschreiben: „Zum Suchen trägt man in ein Textfeld einen Begriff ein und klickt einen Button. Anschließend erhält man eine Liste mit URLs, bei denen man die Informationen finden kann.“ Dieses Verfahren zur Informationsgewinnung hat Google in den letzten Jahren so stark geprägt, dass sich der Begriff „googeln“ für die Recherche im Internet einbürgert.

Die Angebote des Markführers reichen scheinbar in jeden Bereich der Suchmaschinentechnik. Die Ergebnisse sehen auf den ersten Blick plausibel aus, man kann seine eigene Website über ein Plug-in indizieren lassen, und für die Daten auf der eigenen Festplatte bietet Google ebenfalls Lösungen an. Je heller Google strahlt, desto dunkler wird das so genannte „dark web“, der Teil des Internet, den bestehende Suchmaschinen nicht erfassen oder erfassen können. Ohne Suchmaschinen, die ein Hintergrundwissen voraussetzen, ist eine Informationsgewinnung aus diesen Quellen nahezu unmöglich.

Neben frei verfügbaren Informationen gewinnen unternehmens- und organisationsinterne Datenquellen mehr und mehr an Wert. Dezentrale Webserver publizieren Informationen schneller und aktueller. Der Vorteil solcher Webserver liegt in der flachen Hierarchie und den geringen prozeduralen Hürden. Der Preis der Schnelligkeit ist die Wiederauffindbarkeit des Wissens. Eine eigene nicht öffentliche Suchmaschine kann einen zentralen Anlaufpunkt zum Nutzen der Mitarbeiter und Kollegen bilden.

Freie Suchmaschinenprojekte

Die Anforderungen an Suchmaschinensoftware, die einen Teil des Internet oder des Intranet erfassen will, ist hoch. Sie muss entkoppelt von den „Quellservern“ viele Seiten einsammeln, analysieren, indizieren. In Richtung der Benutzer muss ein schnelles Suchinterface bereitgestellt werden. Dieser Artikel greift zwei Open-Source-Lösungen heraus, die beide geeignet sind, über eine Million Webseiten erfassen zu können.

Zunächst zu Aspseek. Obwohl der Name es vermuten lässt, hat es nichts mit den ASP-Seiten von Microsoft zu tun. Hinter dem Namen verbirgt sich eine in C++ geschriebene Suchmaschine. Die Software umfasst alle Funktionen einer solchen Maschine: vom Sammeln der Webseiten („crawlen“) über das Indizieren, die Datenspeicherung bis zur Benutzerschnittstelle. Die Informationen legt das Werkzeug zum Teil in einer MySQL-Datenbank, zum Teil im Dateisystem ab. Unterstützte Plattformen sind offiziell Linux und BSD - prinzipiell sollte die Software aber auf allen Unix-Systemen lauffähig sein. Zum Betrieb ist ein normaler Webserver mit CGI-Unterstützung erforderlich.

Im Gegensatz zu dem schon etwas gesetzteren Aspseek ist Nutch ein vergleichsweise junges Projekt: komplett in Java implementiert und prinzipiell unabhängig vom eingesetzten Betriebssystem. Das Projekt konzentriert sich besonders auf die Skalierbarkeit und Robustheit der Suchmaschine. Die Benutzerschnittstelle nutzt JSP-Seiten unter einem Apache-Tomcat-Server. Bei der Indizierung setzt es auf dem Apache-Projekt Jakarta-Lucene auf, eine vollständig in Java geschriebene Bibliothek zur Textindizierung. Der offizielle Betastatus von Nutch täuscht über die große Reife der Software hinweg. Schon im Juni 2003 haben die Entwickler erfolgreich ein Demo-System mit über 100 Millionen indizierten Dokumenten aufgebaut. Auf Grund des Ressourcenbedarfs musste es leider wieder vom Netz gehen.

Kurzvorstellung Aspseek und Nutch
	Aspseek	Nutch
Homepage	www.aspseek.org/	lucene.apache.org/nutch/
begonnen	2000	2002/03
Programmiersprache	C++ mit STL	Java
Datenspeicherung	MySQL-Datenbank und -Dateisystem	Dateisystem
Plattform	Linux, BSD	unabhängig
benötigte Software	MySQL, Webserver, Unix	Java, Tomcat
Lizenz	GPL	ASL

Aspseek: C++-Sucher

Bei der Installation von Aspseek taucht leider gleich zu Beginn ein Hindernis auf. Das letzte offizielle Release stammt aus dem Juli 2002. Zwischenzeitlich sind C++ und dessen Standard-Template-Library (STL) standardisiert worden, was zentrale Funktionen und Datenstrukturen der STL erneut verändert hat. Unabhängig davon, ob dies sinnvoll war, führt es auf jeden Fall zu erheblichen Kompatibilitätsproblemen zwischen den Gnu-C++-Compilern der Version 2 und 3. Der Code von Aspseek basiert noch auf der STL der Version 2.

Zur Installation gibt es daher drei Varianten: Man nimmt ein älteres Binary-Release, installiert sich einen älteren Gnu-C++-Compiler oder weicht auf die aktuelle Entwicklerversion aus. Für diesen Artikel diente eine aktuelle Entwicklerversion von www.sourceforge.net als Basis, die identisch mit der Version unter www.apsseek.org vom Sommer letzten Jahres ist.

Wenn man die Unterschiede zwischen den Versionen und die Hintergründe verstanden hat, fällt die restliche Installation leicht. Durch die unter Linux gewohnte Befehlsfolge configure; make; make install lässt sich die Software ohne weiteres installieren. Für die Einrichtung der MySQL-Tabellen steht ein Shell-Script zur Verfügung. Im letzten Schritt wandert die Kopie des CGI-Scripts auf den Webserver und der im Hintergrund laufenden Search-Daemon startet, der die Verbindung zwischen Webseite und Datenbank herstellt.

Positiv wirkt die mitgelieferte Dokumentation, die klar gehalten in Man-Pages vorliegt. Zusätzlich kann man in einem Webforum mit anderen Benutzern Kontakt aufnehmen. Hier ist das gesetzte Alter des Projekts ein Vorteil: Viele Schwierigkeiten haben Mitstreiter schon gelöst.

Der erste Schritt für den Betrieb einer Suchmaschine ist die Indizierung der betreffenden Websites. Wer die Konfiguration von Unix-Anwendungen über Textdateien und den Betrieb auf der Unix-Kommandozeile gewohnt ist, dürfte mit Aspseek sofort zurechtkommen. Die Parameter sind überwiegend vernünftig vorbelegt, sodass man nach einer Prüfung der Dateien sofort seinen ersten Internet-Cawler zur Sammlung und Indizierung starten kann. Diese Prozesse lassen sich über Unix-Shell-Scripts anschließend leicht automatisieren. Die Prozesse selber laufen stabil und zuverlässig. Neue Sites lassen sich per Kommandozeile hinzufügen oder löschen. Die Sammlung und Indizierung der Internetseiten selber ist schnell. Sofern man sich auf reine HTML- und Textseiten beschränkt, kann man die Software ohne Anpassungen verwenden. Andere Dateiformate muss man mit externen Konverterprogrammen in HTML oder Text überführen. In der Dokumentation haben die Autoren vielfältige Beispiele hierfür gegeben. Durch die offene Architektur lassen sich recht einfach PDF, Postscript oder Office-Dokumente einsammeln und integrieren. Die notwendigen Konverter sind unter Linux oft schon vorhanden.

Die Benutzerschnittstelle besteht im Wesentlichen aus dem CGI-Programm. Das Layout der Seiten können Betreiber über einen speziellen Template-Mechanismus anpassen. Es gab zwar Ansätze zur Schaffung einer PHP-Schnittstelle, die ist jedoch zur Zeit noch nicht zu empfehlen. Das CGI-Programm verbindet sich mit einem speziellen Search-Daemon, der Verbindung zu den Dateien und der Datenbank herstellt. Die Suchanfragen protokolliert MySQL, sie lassen sich aus dem DBMS leicht auswerten.

Optimiertes Antwortverhalten

Gehaltvoll wird eine Suchmaschine erst nach einigen Tagen Betrieb. Mit der Zeit wachsen die Indizes, und mit der Benutzung kommen die ersten Fragen. Aspseek ist besonders hinsichtlich des Antwortverhaltens der Benutzerschnittstelle optimiert. Damit ist die erste Hürde der Akzeptanz durch die Benutzer schnell genommen. Anfragen sind reproduzierbar und weder von der Tageszeit noch vom Elbewasserstand abhängig. Das schnelle Antwortverhalten geht mit der Komplexität bei der Nachvollziehbarkeit des Rankings der Ergebnisse einher. Zwar sind die Antworten plausibel, aber die Frage, warum eine Seite in der Ergebnisausgabe vor einer anderen landet, führt zu einer längeren Suche im Programmcode. Bei der Integration einer Suchmaschine in den eigenen Website stellt sich außerdem die Frage nach der Anpassbarkeit des Layouts. Hier nutzt Aspseek den erwähnten Template-Mechanismus. Ausgehend vom mitgelieferten Beispielcode kann man mit etwas HTML- und Programmierkenntnissen das Layout leicht anpassen.

Als Betreiber einer Suchmaschine bleibt man immer mitverantwortlich für die gefundenen Ergebnisse und dargestellten Links. Aus diesem Grund entsteht oft der Wunsch, erkannten Webspam oder bestimmte Websites wieder aus dem Index der Suchmaschine zu löschen. Löschungen erfolgen bei Aspseek über die URL oder URL-Teile. Allerdings sollte man nach jeder Indizierung nachprüfen, ob sie nicht doch wieder unerwünschte Seiten aufgenommen hat. Ein weiterer Faktor, den jeder Betreiber beachten muss, ist: Eine Suchmaschine muss ständig beobachtet werden. Auf Grund der offenen Architektur des Internet kann es immer sein, dass sich ein automatisch laufendes Programm an den Besonderheiten einer einzelnen Website festfrisst. Dies kann zu einer überproportionalen Belastung der Website und zur Schädigung eines anderen führen. Es hat sich bewährt, immer nur eine feste Menge an URLs in einem Lauf einzusammeln. Selbst im Falle eines Fehlers beendet sich der Prozess von allein, ohne unkalkulierbare Schäden zu verursachen.

Den eindeutigen Schlüssel zur Unterscheidung der Ergebnisse stellt bei Aspseek die URL dar. Viele Websites und Webforen speichern Sitzungsinformationen innerhalb der URL. Sofern man solche Angebote indiziert, muss man beachten, dass unterschiedliche Sitzungen zu doppelten Ergebnissen im Index führen. Hier muss man die Konfiguration des Indizierers an die aktuellen Erfordernisse anpassen. Der Indizierer lässt sich nur schwer über mehrere Maschinen verteilen, da die Daten im Dateisystem und der Datenbank abgelegt sind. Das Einsammeln der Seiten und die Indizierung der Dokumente sind in einem Prozess zusammengefasst. Einen weiteren Engpass der Indizierung bilden die externen Konverterprogramme. Da sie bei jedem speziell zu betrachtenden Dokument einen neuen Prozess starten, hängen sie in ihrer Leistungsfähigkeit direkt von den freien Ressourcen des Servers ab und bremsen unter Umständen den gesamten Indizierungsprozess aus. Die Benutzerschnittstelle hingegen kann man über mehrere Maschinen verteilen, um eine Leistungssteigerung beim Antwortverhalten zu erzielen. Einen kritischen Engpass stellt die MySQL-Datenbank dar. Bei größeren Installationen muss der Administrator sie auf jeden Fall hinsichtlich ihres Ressourcenverbrauchs optimieren.

Als Ergebnis kann man festhalten: Aspseek liefert eine stabile Lösung zur Indizierung kleinerer Websites und Netze. Leider ist das Projekt zurzeit faktisch eingeschlafen, sodass die Weiterentwicklung stagniert. Angesichts der recht ausgereiften Software stellt sie eine gute Lösung für Suchmaschinen dar, die nur einige 100 000 Seiten indizieren sollen. Wartungs- und Betriebsaufwand sind erfreulich gering.

Nutch: Alternative in Java

Während Aspseek sich eher an Unix-Administratoren richtet, spricht Nutch die Entwickler an. Ziel dieses Projekts ist es, eine transparente Alternative zu den kommerziellen Suchmaschinen anzubieten. Skalierung und Robustheit stehen im Vordergrund. Ziel der Entwickler ist es, eine Software bereitzustellen, die in der Lage ist, mehrere Milliarden Seiten monatlich zu erfassen und einen von der Größe unabhängig schnell antwortenden Index über diese Seiten zu erstellen. Dabei haben sie durchaus die Betriebskosten einer solchen Lösung im Auge. Der Kritikpunkt, dass es durch den frei verfügbaren Quellcode für Webspammer leichter sei, die Ergebnisse zu manipulieren, fällt insofern in sich zusammen, als sich gezeigt hat, dass Webspammer kommerzielle Anbieter ebenso austricksen. In diesem Zusammenhang ist ein öffentlich verfügbarer Ranking-Algorithmus der Suchergebnisse sogar leichter anpassbar. Gerade beim Ranking und der Objektivität laufen die subjektive und objektive Bewertung einzelner Suchmaschinen stark auseinander. Die Entwicklung des Nutch-Projekts geht zügig voran. Die offiziellen Releases (Stand Mai 2005 ist Version 0.6) sind bisher circa alle sechs Monate erschienen. Die Entwicklergemeinschaft arbeitet fleißig und besteht zurzeit aus grob geschätzt 30 Kernentwicklern und etwa 300 Nutzern. Der Hauptentwickler und Koordinator Doug Cutting ist neben dem Nutch-Projekt beim Lucene-Projekt der Apache-Software-Foundation aktiv. Dies erklärt die große Nähe zwischen beiden Projekten. Anfang dieses Jahres sind die Sourcen und das Projekt von der Nutch-Foundation auf die Apache-Foundation übergegangen.

Sofern man über eine aktuelle Java-Umgebung verfügt (ab Version 1.4.x), reicht es, das vorhandene Paket herunterzuladen und zu entpacken. Die Steuerung der RAM-Nutzung erfolgt über eine Unix-Umgebungsvariable, eine XML-Datei enthält die restliche Konfiguration. Für die Benutzerschnittstelle benötigt man einen funktionsfähigen Tomcat (Version 4.x), und die Installation der Webapplikation erfolgt über eine war-Datei, die alle benötigten Dateien zusammenfasst. Das Layout steuern JSP-Seiten und XML/XSLT-Templates. Die aktuelle Version der Software kann man über das CVS laden und automatisch mit Ant übersetzen.

Für die ersten Schritte und Erfolge ist aber keine getrennte Übersetzung notwendig. Das Betastadium der Software zeigt sich im Wesentlichen in der Dokumentation. Sofern man über die ersten Tests hinausgekommen ist und die Einsteigerdokumentation hinter sich gelassen hat, ist man gefordert, sich mit der Quellcode-Dokumentation auseinander zu setzen. Die ist zwar ausführlich, und die Entwickler sind stets hilfsbereit, aber das notwendige Java-Know-how muss zum Verständnis vorhanden sein. Auch das Wiki des Projekts ist eine wertvolle Hilfe und wächst permanent. Auf der anderen Seite relativiert sich dieser Stolperstein, wenn man bedenkt, dass der Betrieb einer Suchmaschine dieser Größenordnung grundsätzlich ein größeres Hintergrundwissen und Erfahrung erfordert.

Nutch trennt zwischen dem Sammeln der Seiten (Crawlen), der Pflege einer Liste zur Speicherung des Status der gesammelten Seiten (welche URL wurde wann mit welchem Status eingesammelt und wann ist die nächste Indizierung notwendig, vom Projekt kurz „WebDB“ genannt), der Indizierung der gefundenen Dokumente und der Benutzerschnittstelle. Ein Vorteil der Trennung von Sammlung und Indizierung liegt darin, dass Erstere unabhängig von der Komplexität der Seiten bleibt. Zusätzlich lassen sich gezielt indizierte einzelne Websites leicht in einen globalen Index integrieren. Mit diesem Ansatz können schon kleine Suchmaschinen durch punktuelle Tiefe einen Mehrwert für ihre Benutzer generieren. Alle notwendigen Befehle lassen sich per Kommandozeile steuern und damit leicht automatisieren. Eine Filterung der Webadressen und Inhalte ist auf verschiedenen Ebenen realisierbar. So lassen sich schon beim Sammeln die URLs über reguläre Ausdrücke oder Substrings filtern. Aus dem Index kann man Dokumente sogar über den Inhalt ausschließen.

Nutch verfügt über eine eigene Plug-in-Schnittstelle, mit deren Hilfe man verschiedene Dokumenttypen bei der Indizierung verarbeiten kann: momentan HTML, Text, PDF, MS-Word und RTF; weitere Plug-ins sind in Entwicklung. Die Integration externer Konverter ist nicht vorgesehen, da es für viele Dokumententypen fertige Java-Schnittstellen gibt. Die Umsetzung scheitert zurzeit im Wesentlichen lediglich an der verfügbaren Entwicklungskapazität.

Tempo durch Prozessaufteilung

Nach einigen Tagen fällt einem bei Nutch die relativ konstant bleibende Geschwindigkeit bei der Sammlung und Indizierung auf. Dies resultiert aus der anfangs genannten Aufteilung der Prozesse. Die Web-Datenbank umfasst einen Graphen mit potenziell zu indizierenden und schon indizierten Seiten. Aus dieser Quelle erzeugt Nutch die Listen der zu ladenden URLs. Da die Datenbank im Laufe der Zeit bei einer Internetsuche immer größer wird, steigt der Aufwand für die Erzeugung der Segmente. Das nachfolgende Sammeln der Dokumente ist wie die Indizierung unabhängig von der Größe der Datenbank. Erst bei der Verschmelzung der Segmente für die Benutzerschnittstelle entsteht ein gewisser Ressourcenbedarf.

Durch einen speziellen Modus kann man statt einer Internet- eine Intranetsuche starten. Die umfasst eine oder mehrere ausgewählte Websites. Für die aus dieser Suche gewonnenen Daten lassen sich dieselben Verfahren wie bei der Internetsuche anwenden. Im Bereich der Internetsuche wird die Last an die indizierten Server künstlich reduziert, während bei der Erfassung eines Intranets diese künstliche Begrenzung der Anfragelast entfallen kann. Das macht den Einsatz von Nutch für Unternehmensnetze genauso interessant wie für öffentliche Suchmaschinen.

Die Präsentation der Ergebnisse ähnelt stark denen der bekannten Suchmaschinen (Link, Auszug aus der Seite und gespeichertes Ergebnis). Ein bemerkenswerter Zusatz ist der Punkt „Explain“, der für jedes Suchergebnis die Berechnungsgrundlage liefert. Sofern man Zweifel an der Einordnung der Ergebnisse hat, findet man hier einen Ansatz zur Diskussion. Der Punkt „Anchors“ neben jedem Ergebnis zeigt, mit welchen Begriffen auf diese Seite verlinkt ist. Das kann einen Teil des Webspams unter Umständen reduzieren.

Nutch zeigt sich als stabile Software für den Aufbau einer Suchmaschine im Internet-, Extranet- oder Intranetumfeld. Das erforderliche Know-how konzentriert sich auf Erfahrungen im Zusammenhang mit Java- und Webapplikationen. Trotz des Betastadiums und der recht geringen Versionsnummer ist die Software für den Regelbetrieb geeignet.

Das Verhalten und der Bedarf einer Suchmaschine zeigt sich immer erst nach einigem Betrieb, da der Datenbestand sich im Laufe der Zeit verändert. Aus diesem Grund entstand auf einem älteren Rechner eine kleine Suchmaschine. Als Testsystem kam ein nicht mehr ganz frischer Pentium III mit 800 MHz, 360 MByte RAM und 120 GByte Festplatte zum Einsatz. Betriebssystem ist ein Linux-System auf Basis der Gentoo-Distribution. Nach circa 12 Wochen Test umfasste der Index von der Nutch-Installation ungefähr fünf Millionen indizierte Seiten, deren URLs in der Web-Datenbank hinterlegt sind. Die Daten belegen auf der Festplatte circa 80 GByte Platz. Während der Indizierung nutzt der Sammler etwa 2 MBit/s Bandbreite (in der Spitze bis zu 8 MBit/s). Ohne Berücksichtigung von Fehlern sammelt das System circa 10 Seiten/Sekunde. Ein Dokument ist dabei im Durchschnitt 25 KByte groß. Begrenzende Faktoren sind die Ausstattung an RAM und die CPU-Geschwindigkeit. Die offiziellen Rahmendaten bei aktueller Hardware sprechen von 40 Seiten Sammeln je Sekunde. Kritischer ist die Größe des Festplattenspeichers, denn ein Index mit 100 Millionen Seiten erfordert etwa 2 TByte. Der Gewinn durch die Komprimierung der Dokumente im Cache geht durch den Verwaltungs-Overhead wieder verloren. Ein optimierter Frontend-Server soll bis zu 50 Suchanfragen je Sekunde bearbeiten können.

Fazit

Dieser Bericht spiegelt die in mehreren Monaten gesammelten Erfahrungen mit Nutch und Aspseek wider. Er kann kein vollständiger Vergleich aller verfügbaren freien Suchmaschinen sein. Gerade in den letzten Monaten haben sich Projekte mit vollkommen neuen Ansätzen hervorgetan, wie die P2P-Suchsoftware Yacy. Zusammenfassend kann man aber sagen, dass es schon heute gute Lösungen für den Aufbau eigener Suchmaschinen gibt.

Eine Überschlagsrechnung zeigt, dass man für eine Suchmaschine mit zwei Milliarden indizierten Seiten schnell über 100 Server benötigt. Betrieb, Überwachung und Wartung der entstehenden Serverfarm erfordern das eigentliche Know-how. Und die Refinanzierung der nicht unerheblichen Betriebskosten stellt eine wesentliche Hürde dar.

Michael Nebel
ist freier Berater im Internetumfeld und Betreiber der Suchmaschine „netluchs.de“.

Mehr Infos

iX-TRACT

• Wer wissen will, warum Suchmaschinen was finden und wie sie es in ein Ranking bringen, kann an Open-Source-Tools vieles nachvollziehen und sie selbst fürs Indizieren nutzen.
• Zwei freie Suchmaschinen, die sich für eigene Zwecke eignen, sind das in C++ realisierte Aspseek und die Java-Alternative Nutch, die beide umfangreiche Indizes erlauben.
• Aspseek eignet sich trotz stagnierender Entwicklung für die kleineren, das noch in Entwicklung befindliche Nutch für größere Vorhaben.

(hb)