Themensuchmaschine: Anforderungen an Server/Skripte/Programme?

[Julian Hofmann]

Hallo.

In den letzten Wochen kam mir mehr und mehr der Gedanke eine kleine Suchmaschine für ein bestimmtes Themengebiet aufzubauen. Nur habe ich absolut keine Ahnung wie man da anfängt.
Umfangmäßig würde ich mal mit bis zu 1500 Websites rechnen.

• Welche Voraussetzungen an Hardware müssten für sowas gegeben sein?
• Welche Software (z.B. Datenbank) wäre vermutlich unabdingbar?
• Wie würde sowas von der Programmierung her in etwa aussehen (Aufbau/Ablauf)?
• Welche Sprache sollte überhaupt verwendet werden um das alles halbwegs vernünftig (und zukunftsorientiert) aufzubauen?

Bin über alles dankbar.

Grüße aus Würzburg
Julian

[Stephan Huber]

Hallo Julian,

In den letzten Wochen kam mir mehr und mehr der Gedanke eine kleine Suchmaschine für ein bestimmtes Themengebiet aufzubauen. Nur habe ich absolut keine Ahnung wie man da anfängt.

Wie legst Du fest, was zum Themengebiet gehört? Ich nehme mal an, Du willst zuerst einmal einen Katalog machen, in dem themenspezifische Webseiten stehen, und von da ausgehend spidern. Wann hörst Du auf? Am sichersten ist es, wenn Du einfach nur von den redaktionell gesichteten Seiten "nach unten" gehst, also Links ignorierst, die ein Verzeichnis höher führen, oder in eine andere Domain. Das Konzept ist dann eher sowas wie eine Volltextsuche über alle aufgelisteten Sites eines redaktionell erstellten Katalogs. Oder hast Du etwas anderes vor?

• Welche Voraussetzungen an Hardware müssten für sowas gegeben sein?

Kommt wie immer auch auf die Besucherzahlen an, aber in diesem Fall wahrscheinlich eher auf die Aktualität des Indexes, da die Besucher den Server, wenn es nicht wirklich sehr viele sind, lange nicht so beanspruchen, wie der spider, der ja unabhängig von den Besucherzahlen laufen muß. Wenn Du von jeder der 1500 Sites 20 Seiten indizierst, muß der Server bei monatlicher Aktualisierung des Index 0,7 Seiten in der Minute schaffen, das sollte mit einem normalen Dedicated (was man halt jetzt so für 50-100 Euro bekommt) gar kein Problem sein, vor allem da nach der ersten Erstellung des Index ja nur noch neuindiziert wird, wenn sich eine Seite geändert hat, bei vielen Seiten wirst Du also bei darauffolgenden Durchläufen des Robots nur noch HTTP-Header abfragen, nicht die ganzen Seiten. Plattenplatz sollte auch kein Problem sein, htdig z.B. gibt als Orientierungswert für die Größe des Index 12K mal die Anzahl der Dokumente an, das wären dann bei der Annahme ca. 350MB.

• Welche Software (z.B. Datenbank) wäre vermutlich unabdingbar?

Du brauchst eine Datenbank (PostgreSQL, MySQL, usw. )für den Katalog, und dann eine Suchmaschine, falls Du die nicht selber programmieren willst, wovon ich stark abraten würde. Man hat zwar schnell irgendein Skript, daß Seiten aufruft und nach Links durchsucht, aber das so zu machen, daß es z.B. auch robots.txt versteht, und die ganzen HTTP-Antworten (Redirects, usw.), wäre doch sehr aufwendig, und es gibt genügend gute open source Software, damit man das Rad nicht neu erfinden muß.

• Wie würde sowas von der Programmierung her in etwa aussehen (Aufbau/Ablauf)?

Im wesentlichen würde die Arbeit darin bestehen, sich eine Katalogsoftware zu basteln oder ein bestehendes Skript anzupassen (gibts ja auch wie Sand am Meer z.B. in PHP). Dann brauchst Du nur noch eine Suchmaschine, der Du die Ausgangslinks übergeben kannst. Ich habe bis jetzt nur mnogosearch benutzt, und htdig mal näher angeschaut, aber denen kann man zumindest in der Konfigurationsdatei die Server/urls geben, von denen sie ausgehen sollen, und auch sagen, ob sie z.B. jeweils innerhalb der angegebenen Domain bleiben sollen, wie weit sie spidern sollen, usw. Du brauchst also dann nur noch ein Programm, daß alle URLs aus dem Katalog holt, und sie in der Konfigurationsdatei des Spiders regelmäßig aktualisiert, oder den Spider mit den neu zu indizierenden urls als parameter aufruft (bei htdig z.B. sollte das gehen)
Und eine Möglichkeit, den Spider regelmäßig so laufen zu lassen, daß er dabei nicht die ganzen Ressourcen des Servers verbrät. Wie man das geanu macht, hängt von der Suchmaschinensoftware ab, unter Unix kannst Du das z.B. entweder mit "nice" kontrollieren, oder immer eine begrenzte Indizierung einiger Seiten per cron starten, usw.

• Welche Sprache sollte überhaupt verwendet werden um das alles halbwegs vernünftig (und zukunftsorientiert) aufzubauen?

Englisch, Spanisch und Chinesisch ;-)

Viele Grüße
Stephan

[Michael Schröpl]

Hi Julian,

In den letzten Wochen kam mir mehr und mehr der
Gedanke eine kleine Suchmaschine für ein bestimmtes
Themengebiet aufzubauen. Nur habe ich absolut keine
Ahnung wie man da anfängt.

Ich empfehle Dir, damit zu beginnen, Such-Formulare zu basteln. Überlege Dir, was Deine Anwender alles tun können sollen.

Dabei lernst Du nämlich zwei Dinge:
a) _Welche_ Informationen muß ich in meiner Datenstruktur gespeichert haben? (Das sagt noch nichts darüber aus, _wie_ die gespeichert sein müssen.)
b) Welche Operationen auf diesen Informationen (Strings-Vergleich, regular expression match, ...) muß ich durchführen können? (Das sagt noch nichts darüber aus, wie diese Operationen implementiert sein werden.)

Beides zusammen liefert Dir wertvolle Informationen sowohl für Deine erforderlichen Datenstrukturen als auch für die Grundzüge der notwendigen Algorithmen.
Wenn Du weißt, _was_ Deine Suche können soll, dann bist Du in der Lage, eine Aufgabenstellung zu schreiben - diese ist Voraussetzung für _alles_ Nachfolgende. Das "was" ist unverzichtbar.
Diese Phase des Projekts dauert etwa 30% der Gesamtlaufzeit - also nimm sie ernst!

Erst danach geht es damit los, sich das "wie" zu überlegen. _Jetzt_ kommen Fragen wie "welche Datenbank" oder "welche Programmiersprache".
Aufgrund der Datenmodellierung weißt Du nun nämlich schon, was Deine zu verwendenden Tools können müssen - also kannst Du solche, die etwas Notwendiges nicht können, zuverlässig verwerfen. Das ist viel schlauer, als erst mal ein Tool zu raten und später zu verzweifeln, weil es eine lebensnotwendige Kleinigkeit nicht (oder nicht performant genug - das kann genauso schlimm sein) unterstützt.

Die gesamte Programmierung wird weitere 30% des Projekts ausmachen. Das mag Dir niedrig vorkommen, aber das ist ein guter Ansatzpunkt für Schätzungen.
Bedenke, daß Dein Produkt anschließend noch gründlich getestet werden will (auf Korrektheit, Usability, Performance usw.), und die Dokumentation, das Benutzerhandbuch, das Betriebskonzept etc. muß schließlich auch irgendwer aufschreiben. Das alles kostet viel Zeit.

• Welche Voraussetzungen an Hardware müssten für
  sowas gegeben sein?

Das hängt von vielen Faktoren ab, die Du nicht genannt hast. Die Zahl der erwarteten Zugriffe und die mittlere Suchdauer (letztere hängt wiederum von der Effizienz Deiner Implementierung und von der Menge der durchsuchbaren Daten ab) ist beispielsweise viel wichtiger als die Menge der Daten allein.

Es kann durchaus sein, daß Du erst mal eine abgespeckte proof-of-concept-Implementierung machen mußt, um zu sehen, wie Du mit der Performance hinkommst, bevor Du wirklich gute Aussagen für die später zu verwendende Hardware machen kannst.

• Welche Software (z.B. Datenbank) wäre vermutlich
  unabdingbar?

Das kann man in diesem Stadium noch nicht beantworten. (Man sollte es in diesem Stadium sogar nicht mal _fragen_. ;-)

• Wie würde sowas von der Programmierung her in etwa
  aussehen (Aufbau/Ablauf)?

Auch dafür ist es zu früh.

Woher beziehst Du Deine zu durchsuchenden Informationen? Sind das ausschließlich lokale Seiten oder mußt Du im Web auf Beutesuche gehen? Schon dieses Detail wird für das Betriebskonzept Deines Indexers essentiell sein.
Also: Aufgabenstellung schreiben - danach sehen wir weiter.

Was die eigentliche Sucherei angeht: Im Wesentlichen besteht der Trick darin, die Arbeit aus der Online- in die Indexing-Phase zu verlegen, damit der Besucher möglichst kurze Wartezeiten erleben darf.
Allgemein haben sich sortierte Bäume als Datenstruktur bewährt - ob Du so etwas selbst implementieren oder aus einer relationalen Datenbank als fertiges Modul übernehmen willst, das hängt von Randbedingungen Deiner Implementierung ab.
Allgemein würde ich sagen, daß Du mit SQL gut fährst - meine persönlichen Erfahrungen mit mySQL sind beispielsweise prima, auch wenn ich für eine bestimmte Suchmaschine den C-Quelltext der mySQL-Engine ändern mußte. Sofern Deine Aufgabenstellung keine exotischen Elemente enthält, wirst Du mit einer einfachen Datenbank, sehr einfachen SQL-Statements und einer beliebigen algorithmischen Sprache für Oberfläche und Indexer auskommen. Die Aufgabe "Suchmaschine" enthält alleine praktisch keine Einschränkungen für die verwendbaren Technologien.

• Welche Sprache sollte überhaupt verwendet werden
  um das alles halbwegs vernünftig (und
  zukunftsorientiert) aufzubauen?

Was ist "zukunftsorientiert"? Wenn Du von weniger als 5 Jahren redest, kannst Du nehmen, was Du willst - redest Du von mehr als 10 Jahren, dann halte ich beliebige Vorhersagen für nicht mehr sonderlich seriös. ;-)

Viele Grüße
      Michael

[Julian Hofmann]

Hallo Michael,
hallo Stephan.

Vielen Dank für Eure beiden doch recht ausführlichen Antworten. Werde mir mal mit deren Berücksichtigung weiter Gedanken dazu machen - und im Zweifel kenn ich bei Problemen ja wieder ein super Forum. :)

Grüße aus Würzburg
Julian