[Seeky] Offene Suchmaschine(n)

[Niels Dettenbach]

Hallo Julian,

vielen Dank für Deine Mail.

Ich möchte Java auch nicht unbedingt schlechtreden und Sun hat wohl auch wohl schon vorreitende Konzepte bzgl. "Suchnetzwerken" ausgebrütet, was ich mir aktuell auch mal näher anschauen will / werde.

Meine Erfahrung sagt mir z.B., das es (bisher jedenfalls) typische Java-Applikationen deutlich schwerer zu haben scheinen, wenn es um möglichst einfache Verbreitung (sprich einfache Installation und Inbetriebnahme). Während heute wohl die meisten Webmaster einen Apache grundlegend installiert und eingerichtet bekommen, dünnt sich das Feld bereits bei Jakarta / Tomcat deutlich aus.

Ein weiterer Nachteil sind die prinzipbedingten Grenzen bzgl. Performance und Flexibilität. Zwar kann man auch mit professionellen Java-Tecdhnologien einiges erreichen, der Aufwand aber steigt (bei der Entwicklung wie dem skalirenden Betrieb) mit wachsenden Ansprüchen - sei es an Hardware oder professionelle Entwicklerlösungen bzw. Betriebsumgebungen, wo man schnell an die Grenzen der heutigen Open Source Welt stößt. Während einzelne Klassen oder Applikations-Komponenten oft sehr performant und skalierbar agieren, treten die meisten kritischen Probleme erst nach dem Zusammenfügen auf, da Kapselung und Garbage Collection etc. In der Theorie oft besser funktionieren als in der Praxis. Nicht selten stelllt man dann fest, das man entweder einen kompletten Rewrite braucht oder mit viel zusätzlichem Aufwand (Hardware, Caching, ausführlichste Reviews, Beschleunigungstechnologien etc.) eine akzeptable Performance erreicht.

Es spricht aber auch nichts dagegen, wenn jemand Implementierungen teilweise oder ganz in Java stricken möchte. Dienste-Interfaces für Java-Entwicklungen wird es zudem auch geben können / müssen damit Java Applikationen die Dienste nutzen oder auch bedienen können.

Allerdings - muß ich zugeben - bin ich ein schlechter Java-Coder. Mit den "klassischen" Sprachen wie Perl und grundlegendes C finde ich mich weitaus besser zurecht - Python wohl auch.

Gerade das performante, leistungsfähige, flexible Regex-Handling hat Perl bei selbst den großen Suchmaschinen bis heute einen wichtigen Platz erobert, so das nur einzelne performancekritische Parts in "purem" C realisiert sind. Obgleich es eine Scriptsprache ist, lassen sich - mit etwas KnowHow - relativ "hardwarenah" performanceoptimierte Codestrukturen schreiben, die selbst mit C oft nicht trivial zu schlagen ist. Zudem ist Perl afaik quasi Standard (bzw. eine der wichtigsten Dependencies) auf den allermeisten Distributionen und Module lassen sich recht leicht auch (teilweise) in C realisieren.

Schaut man sich mal die typischen Vergleiche zwischen den gängigen Sprachen an, sieht man recht eindrucksvoll mit wie wenigen Zeilen Code Perl eine gemeinsame Aufgabe zu lösen ist, wogegen Sprachen wie C, Java oder auch Python ein Vielfaches an Code (und Entwicklerzeit) benötigen. Regexes machen ja einen Gutteil jeder Suchlösung aus - auf den verschiedensten Ebenen. Zwar kann Perl-Code auch sehr "freakig" ausfallen, dennoch sind übersichtliche kurze Programme gut realisierbar und vor allem wartbar. Perl-Coder sind ja auch nicht so selten unterwegs, denke ich...

Werde mir auch mal das aktuelle Lucene anschauen ob und in wie weit man Lucene für eine Referenzimplementierung (Harvester, ev. auch Teile Indexer) einbeziehen könnte. Ideal wäre natürlich eine "Harvester" Lösung als Apache Modul oder -Erweiterung verfügbar, die das erfolgreiche Apache Projekt zum Auftrieb kommen könnte.

Mache die Tage mal einen ersten groben Designvorschlag (in Diagrammform) zur Diskussion hier. Um überhaupt Aussicht auf Erfolg zu haben, sollten die ersten Lösungskomponenten bereits von Beginn an signifikante Mehrwerte für Webbetreiber, Carrier usw. bieten - ggf. unter Einbeziehung bestehender, etablierter Suchdienste (habe auch dazu Ideen - mehr in Kürze...).

Beste Grüße und ein schönes Wochenende,

Niels.