[Seeky] Offene Suchmaschine(n)

[Niels Dettenbach]

Hallo Axel,

da gebe ich Dir in jedem Fall recht. Das A&O für eine entsprechend skalierbare Struktur ist das Vorhalten entsprechend schneller wie guter Indizes. Es gibt eine ganze Reihe verschiedener Open Source Projekte mit den unterschiedlichsten Ansätzen, aus denen man etwas (dazu-)lernen kann.

Eine verteilte Infrastruktur an (mehr oder weniger "spezialisierten") Indizes halte ich für weitaus skalierbarer als einzelne (machen die Großen wohl nicht sehr viel anders - nur das dort größere Gruppen "enger" beieinanderstehen). Je nach "Komplexität" der Suche werden einzelne oder viele Indizes einbezogen.

Ich könnte mir vorstellen, das ein User zwischen "Geschwindigkeit" einer Abfrage und "Genauigkeit" entweder frei wählen kann oder Ergebnisse zeitlich von "grob" nach "genau" "aufbauen". Häufige oder einfachere Abfragen können schneller beantwortet werden - komplexere brauchen entweder etwas mehr Zeit oder liefern zuerst eine "grobe" Antwort um dann ggf. immer genauer zu werden. Arbeitet man mit Caches (z.B. auch als Indizes) lassen sich einzelne Antwort-Komponenten zwischenspeichern, womit folgende Abfragen schneller erfolgen (ähnlich wie von DNS bekannt). Spezialisierte (kommerzielle) Suchportale können damit werben auch hochkomplexe Abfragen - ggf. mit zusätzlichen Indizes gekoppelt - dank zusätzlich bereitgestellter "Rechenpower" zu ermöglichen, wie man sie bisher ggf. noch nicht kannte.

Bisher geben die Großen (kommerziellen) ja vor, was wir wie suchen dürfen und welche Antworten die "besten" für uns seien. Immerhin bringt - davon bin ich überzeugt - eine "heterogene" Suchumgebung neue Möglichkeiten zur Optimierung von Rankings und machen es so den "Suchmaschinenspammern" ungleich schwerer (auch wenn man heute - auf den ersten Blick - ggf. das Gegenteil annehmen würde), denn statt mit einem Satz Algorithmen von einer Firma müssen sie sich mit den verschiedensten auseinandersetzen, die zudem untereinander im Wettbewerb stehen.

Ein Großteil der Rechenlast fällt idealerweise beim "betr." Webserver an. Ich denke es ist nicht ganz irrig anzunehmen, das die mittlere "Suchlast" auf eine Website proportional der "Besucherlast" ist. Langfristig könnte dies bedeuten, das zu einem guten "Webhosting" auch ein schneller "Bottom-Level-Index" gehört, der sozusagen "exklusiv" für die dort / lokal gehosteten Websites "zuständig" ist und den umfangreichsten Datenbestand pro Website vorhält. Nebenbei wird der Crawler Traffic auf die Seiten minimiert, die nur selten oder quasi nie besucht werden.

Eine Art "Request Router" analysiert eingegebene Anfragen und entscheidet, wie diese möglichst "effizient" bearbeitet werden können und welche Indizies wo zu fragen sind. Nimmt Resultate entgegen und holt bei Bedarf / wenn gewünscht weitere Informationen ein. 

Interessanterweise scheint ein Gutteil der bisherigen "Lösungen" in Java implementiert, was ich persönlich nicht gerade die genialste" Idee halte, zumal schon der Faktor Performance eine der wichtigsten Rollen spielen dürfte und was ich mit Java-Implementierungen nur mit unvergleichbar höherem Aufwand realisierbar sähe.

M.W. verwenden auch Google & Co. wohl kein bis kaum Java in der Infrastruktur - man greift selbst bei "Kernfunktionen" immer noch auf das gute alte Perl sowie C zurück. Aber auch Python kommt hier und da zum Einsatz und wird wohl vor allem für User-Applikationen an deren API empfohlen. 

Ja, Planung ist das A&O in einem solchen Konzept, weshalb mein Vorschlag ist Ideen zu sammeln und in RFCs o.ä. zu bringen, die in der Community diskutiert werden können.

Beste Grüße,


Niels.