In einem meiner letzten Posts "Inventur im Content-Universum auf yeebase.com" habe ich bereits einen Blick auf unsere Inhalte geworfen und versucht eine erste Grundordnung in unserem Content-Universum herzustellen. Dabei sind auch schon die ersten Hintergrund-Ideen à la "Machine Tags" und "Kontrolliertes Vokabular" kurz zur Sprache gekommen, auf die ich später noch in separaten Artikeln eingehen werde. Im Folgenden möchte ich erst einmal die weitere geplante Vorgehensweise beim Aufbau unseres "yeebase media Indexers" (zukünftig nur noch "Meta" genannt) skizzieren und auch schon auf die im weiteren Verlauf benötigten Basis-Komponenten eingehen.

1) Indexing-Engine: das Search-Backend

Wir brauchen eine solide Indexing-Engine. Im Gegensatz zu relationellen Datenbanken, sorgt diese dafür, dass selbst bei großen, ständig wachsenden Datenmengen, Suchergebnisse extrem schnell ausgeliert werden können. Als großen Beispiel zeigt in diesem Bereich natürlich Google, was technisch möglich ist, aber auch die unglaubliche Index-Größe der Twitter-Suche spricht Bände.

Im Open-Source-Indexer-Engine Umfeld ist vor allem die Java-basierte Lucene-Library weit verbreitet. Aber auch alternativen wie z.B. das Sphinx-Projekt oder das mnoGoSearch. Anders als vielleicht bei den anderen Teilbaustellen, sollte man sich bei der Wahl der richtigen Indexer-Software wirklich genau anschauen, was man sich damit ins Boot holt und genug Zeit für die technische Evaluierung einplanen. So lockt zum Beispiel der PHP-basierte Lucene-Port "Zend_Search_Lucene" mit Lucene-Index-File-Kompatibilität und leichter Installation, kann bei genauerer Betrachtung allerdings mit Java-basierten Lösungen in den Punkten Wartbarkeit und Geschwindigkeit nicht annähernd mithalten.

Da die Indexer-Engine später das "Herz" von Meta darstellen wird, kommt es auf die Folgenden Punkte an:

• Einrichtungsaufwand (Kann man das Ding unkompliziert aufsetzen und an die eigenen Bedürfnisse anpassen?)
• Wartbarkeit (Kann ich im Laufenden Betrieb Updates einspielen?)
• Stabilität (Wie lange gibt es das Projekt? Gibt es Stable-Releases/Bugtracker/SVN? Gibt es kommerziellen Support?)
• Unterstütze Programmiersprachen (Können wir das Ding aus der Script-Sprache unserer Wahl ansprechen?)
• Funktionsumfang (Werden alle benötigten Funktionen abgedeckt? Facetted Search? Stemming? ...?)
• Zukunftssicherheit (Gibt es eine Große Community um das Projekt?)

Die Wahl der richtigen Indexer-Engine fällt wirklich nicht leicht. Nachdem ich mir inzwischen schon 2 Jahre den Open-Source-Markt anschaue und neben Lucene, Sphinx und Zend_Search noch viele weitere Engines auch in Verbindung mit MySQL angeschaut habe, bin ich am Ende bei Apache Solr gelandet. Apache Solr basiert im Kern auf Lucene, erweitert dieses jedoch um eine solide REST-API, mit der man die Search-Engine unkompliziert aus anderen Script-Sprachen (z.B. PHP) heraus ansprechen kann. Zudem hat sich um Apache Solr die Firma Lucid Imagination gebildet, die im Ernstfall für kommerziellen Support zur Seite steht und zudem die Entwicklung von Solr weiter vorantreibt.

2) Message-Queue: die Warteschlange

Wenn man rechenintensivere Aufgaben aus einer webbasierten Applikation heraus durchführen möchte - wie zum Beispiel das automatisierte Kategorisieren und Indexieren von Inhalten - kommt man auf Dauer um eine Message Queue nicht mehr herum. Die Message Queue ist eigentlich nichts anderes als ein überdimensional schneller Netzwerk-Speicher-Dienst, dessen einzige Aufaufgabe es ist Nachrichten entgegenzunehmen und auf Nachfrage wieder herauszugeben. Die Message Queue läuft meist als Dienst im internen Netz auf einem bestimmten Port und ist in einer "soliden" Programmiersprache wie C++,Java oder neuerdings auch oft Erlang geschrieben. Zunächst denkt man sich beim Thema Message-Queue irgendwie immer:

Warum soll ich das brauchen? Meine Anwendungen können doch z.B. auch eine MySQL-Tabelle oder gemountetes Netzwerk-Storage als Queue nutzen.

Wer sich aber mal eine Message Queue installiert und ein paar Tests gefahren hat, wird sich schnell der Dimension dieses im Grunde trivialen Stücks "Warte-Schlangencodes" bewusst: Abläufe kapseln, Usability erhöhen, komplexe Prozesse im Hintergrund ausführen lassen = Skalierbarkeit

Aber genug der Theorie. Ich habe mir verschiedene Open-Source-Message-Queue-Lösungen angeschaut. Dropr, beanstalkd, ActiveMQ,... mir war wichtig, dass das Ding monstersolide, schnell und unkompliziert aufzusetzen ist und am Ende bin ich bei Kestrel gelandet. Ja, ich weiß, klingt erstmal überdimensioniert (das ist die MessageQueue von Twitter ;), aber das tolle bei Kestrel ist, dass das System brettschnell und persistent ist und zudem das Memcache-Protokoll verwendet. Da ich aus PHP heraus daraufzugreifen möchte, ist das extrem super, da mit php5_memcache bereits ein Modul die nötige Bibliothek für die Kommunikation mit Kestrel zur Verfügung stellt.

3) Base-Anwendung: das Such-Interface, Content-API und Worker-Scripte.

Die Base-Anwendung von Meta soll eine schlanke Symfony-Applikation mit Doctrine-Backend bilden. Natürlich könnte man sich auch komplett auf Solr verlassen und müsste nicht die gleichen Daten nochmal in einer Schicht darüber in einer MySQL-Datenbank vorhalten, allerdings reizt mich der Gedanke, durch diesen Aufbau zusätzliche Flexibilität zu gewinnen, da so zum Beispiel bestimmte Content Elemente auf den Status "nicht indexieren" gesetzt werden können oder gezielte Reindexierungs-Vorgänge gestartet werden können (z.B. wenn man das Solr Schema anpassen musste oder es ein technisches Problem gab). Achso: Symfony ist übrigens ein PHP-Framework und Doctrine ein Object-Relation-Mapper (ORM), also für Leute, die keinen Bock mehr haben SQL zu schreiben - so ähnlich wie Hibernate für JAVA. Mit beiden Komponenten in Kombination kann man auf einfache Art und Weise pragmatische Lösungen an den Start bringen. So kann man Doctrine-Models zum Beispiel relativ leicht so erweitern, dass sie beim Ausführen der UPDATE- und SAVE-Methode auch den Solr-Index aktualisieren.

Die Base-Anwendung wird am Anfang erstmal ein einfaches Suchinterface à la Google Search bieten, um die korrekte Funktionsweise von Meta live überprüfen zu können. Später ist geplant über ein API-Modul es den Subportalen zu ermöglichen auf die Meta-Daten zuzugreifen und inhaltliche Verknüpfungen darzustellen (z.B. thematisch ähnliche hype-Artikel auf der Einzelansicht einer News auf t3n.yeebase.com). In der Base-Anwendung wird es zudem eine Möglichkeit geben die Themenschwerpunkte bzw. das kontrollierte Vokabular zur automatisierten Verschlagwortung zu verwalten. So soll Meta relativ früh in der Lage sein, bei der Indexierung Inhalte aufgrund der vorhandenen Objekt-Definition und definierten Themen-/Schlagwort-Sets für eine semantische verknüpfung vorzuschlagen - ein Artikel zum Thema "Suchmaschinenoptimierung mit TYPO3" müsste dann automatisiert zum Objekt "TYPO3" auf opensource.yeebase.com und dem Themenschwerpunkt "SEO" zugeordnet werden. Dazu aber später mehr.

Wichtig auf der Seite der Base-Anwendung sind noch die Worker-Scripte. Diese sind als Symfony-Task implementiert und werden mit Hilfe des Linux-Tools "daemon" als Prozesse in mehreren Instanzen gestartet. Ihr Aufgabe besteht darin, die Message Queue alle 250ms nach neuen Aufgaben zu fragen und diese nach Eintreffen schnellstmöglich abzuarbeiten.

4) Base-Clients: Content-Synchronisierung bei Änderung aus den Portalen

Die beste Suchmaschine macht keinen Spaß, wenn sie keine Suchtreffer bietet. Dass die Inhalte von *.yeebase.com ordentlich erfasst werden gibt es zwei Wege, die implementiert werden müssen.

• Client-Script (Komplettindexierung)
• CMS-Client-Hooks (selektive INSERTS, UPDATES, DELETES)

Das Synchronisierungs-Script für die einzelnen Portale ist eine schlanke PHP-Anwendung, die als einzige Aufgabe hat alle Inhalte aus einem Portal zu extrahieren und in einem bestimmten Format in die Message-Queue zu schreiben. Auf der Console sieht das dann ungefähr so aus:

./client t3n:sync

Der Befehl würde jetzt alle auf t3n veröffentlichten Artikel zur Indexierung in die Message-Queue schreiben, worauf auf der anderen Seite, dann die Worker-Scripte sich die Artikel schnappen und sowohl in der Base-Anwendung als auch im Solr verarbeiten würden. Nach der Einmalsynchronisierung über das client-Script, das im späteren Betrieb bei Problemen wohl auch noch öfter zur "harten" Neuindexierung eingesetzt werden wird, stellt sich die Frage, wie neue Artikel und Änderungen am Inhalt (z.B. löschen eines Kommentars) an den Indexer geschickt wird. Hier müssen für jedes eingesetzte System (z.B. Wordpress bei t3n.yeebase.com und jobberbase bei jobs.yeebase.com) die jeweiligen Hook-Möglichkeiten genutzt werden. Das heißt, alle Stellen, wo gespeichert, veröffentlicht, gelöscht oder geupdatet wird, müssen so erweitert werden, dass auch dort ein entsprechender Auftrag in der Message Queue abgelegt wird.

Fazit

Viele Baustellen, wenig Zeit, großes Verzettelungspotential. Um dennoch einigermaßen konstruktiv mit dem Meta-Projekt weiterzukommen, wird man bei den einzelnen Komponenten Abstriche machen müssen. Der Solr bekommt erstmal ein halbfertiges Schema verpasst, die Base-Anwendung sieht evtl. erstmal aus, als ob sie 1986 designed wurde und die semantische Logik stellen wir auch erstmal hinten an.

Dennoch erscheint mir der aktuelle Aufbau ganz solide und wir dürften damit relativ schnell eine erste Version am Start haben. Mal schauen, wie unsere Server-Architektur da mitspielt.