Best Practice bei maßgeschneiderten Suchfunktionen für Hochschulen

16.11.2017 um 11:53 Uhr – gepostet von Alexander Büttner in Web Development

Der folgende Beitrag ist ein Abstract des entsprechenden Vortrags bei den TYPO3 University Days 2017 in Darmstadt.

Suchen sind bei strukturell und inhaltlich komplexen Seiten eines der wichtigsten Features, um Informationen gezielt abrufen oder - in der anderen Richtung - vermitteln zu können. Je komplexer die Inhalte selbst sind, umso größer sind die Herausforderungen, denen sich die Suchfunktion stellen muss. Die Erwartungshaltung der Nutzer hinsichtlich Usability ist dabei ein weiteres wichtiges Augenmerk. Wir zeigen anhand unserer Erfahrungen im Hochschulbereich, wie mit MKSEARCH und Apache Solr eine leistungsstarke und flexible Suchfunktion realisiert werden kann, die Dank ihrer Open Source-Basis ebenso kostensparend wie zukunftssicher ist.

Welche Herausforderungen begegnen uns bei Hochschulseiten?

Strukturelle Komplexität: Inhalte auf Hochschulseiten verteilen sich meist auf verschiedene Microsites (Subdomains) und komplexe Menüstrukturen.

Systematisierte Unschärfe: Aufgrund der thematischen und strukturellen Ähnlichkeit der Microsites (insb. Fakultätsseiten) kann es zur Unschärfe bei den Suchergebnissen kommen (bspw. wenn jede Fakultät eine Seite namens „Dekanat“ hat).

Geschützte Inhalte: Inhalte aus internen Bereichen dürfen nicht über die öffentliche Suche gefunden werden.

Diversität von Informationstypen und Datenstrukturen: Es gibt unterschiedliche Typen von Datensätzen und Metainformationen, nach denen gesucht werden können sollte.

Performance: Die Suche muss trotz enormer Datenmengen performant sein.

Aktualität: Aufgrund der Vielzahl an Redakteuren wird es häufig zu Änderungen am Content kommen, welche dann auch schnellstmöglich gefunden werden können sollen.

Usability: Der User ist durch Google und Co. unterstützende Funktionen bei der Suche gewohnt und erwartet diese auch – bspw. Synonymsuche, Tippfehlerkorrekturen, Autocomplete, Highlighting.

Mehrsprachigkeit: Inhalte können in verschiedenen Sprachen vorliegen.

All diesen Punkten können wir mit Apache Solr und MKSEARCH beikommen.

Apache Solr ist ein Enterprise Search-Server aus dem Apache Lucene Projekt, welcher durch die Apache Software Foundation, eine Non-Proft Corporation, bereitgestellt wird. Dahinter steht also eine Community von Entwicklern, welche quelloffene Projekte aktiv und ständig vorantreibt und zur Verfügung stellt. Im Fall von Apache Solr geschieht das bereits seit 2004.
Apache Solr kann als Enterprise Search Server in Plattformen wie TYPO3, Magento und anderen Unternehmensanwendungen integriert werden, da Solr für den Zugriff http verwendet und die Ergebnisse wahlweise als XML oder JSON-Strings ausgibt. Die Integration ist damit nicht an bestimmte Programmiersprachen oder Plattformen gebunden. Die Erweiterung von Solr erfolgt per Java, die Konfiguration über XML-Dateien.
Für die Indexierung und Suche kommt die Java-Bibliothek Lucene zum Einsatz, weitere Anpassungen sind dank einer umfangreichen Plugin-Architektur möglich.

Indexierung bezeichnet in diesem Kontext den Vorgang, um in der Suchmaschine ein Dokument (mit den Daten eines konkreten Datensatzes) in den Index aufzunehmen bzw. ein bestehendes zu aktualisieren.
Beim Crawling parst ein Crawler den Sourcecode einer konkreten HTML-Seite. Die Indexierung ist also ein dem Crawling nachgelagerter Vorgang.
Bei einer Indexierung mittels eines eigenen Indexer (bei MKSEARCH) werden die Daten für den Index ohne Crawling direkt aus der Datenbank generiert. Dafür gibt es eine entsprechende Logik in PHP (bei uns als „Indexer“ bezeichnet). Damit können die entstehenden Dokumente um für die Suche relevante Felder angereichert werden, die im Markup nicht enthalten sind und beim Crawling damit nicht mitkommen würde. Zum Beispiel könnten bei News-Daten die Kateogorien mit indexiert werden.

MKSEARCH ist eine quelloffene und kostenlose TYPO3-Extension, die von DMK entwickelt bzw. kontinuierlich weiterentwickelt wird. Sie erlaubt die Integration von verschiedenen Suchtechnologien, etwa Apache Solr, PHP-Lucene oder ElasticSearch. Die Ausgabe der Suchtreffer lässt sich je nach Datensatz individuell gestalten, denkbar sind zum Beispiel auch Geo-Visualisierungen von Treffern über Google Maps oder OpenStreetMap.
Darüber hinaus hat MKSEARCH eine offene API zur Anbindung von Suchmaschinen, sodass hier jederzeit eine Erweiterung erfolgen kann. Die Extension ist auch bereits für TYPO3 8 kompatibel.

Im Vergleich zu anderen Suchextensions bringt MKSEARCH vor allem den großen Vorteil mit sich, nicht auf einen Seitencrawler zu setzen, sondern die Ergebnisdokumente über spezielle PHP-Indexer direkt aus der Datenbank zu generieren. Dies geschieht dabei nicht in der MySQL-Datenbank von TYPO3, sondern mithilfe eines eigenen Suchservers. Gepaart mit einem großen Standard-Featureset und der Möglichkeit, die Extension flexibel und individuell für spezielle Anwendungsfälle anzupassen, ist MKSEARCH als Framework eine skalierbare, leistungsstarke Suchfunktion, die sich auch für umfangreiche und komplexe Portale eignet.

MKSEARCHIndexed_searchSolr (Extension)Ke_search
Art
Spezielle Indexer in PHP

CrawlingCrawlingSpezielle Indexer in PHP
SuchserverLucene, Solr, ElasticSearchMysql-DB-von TYPO3SolrMysql-DB-von TYPO3
Eignung fürKleine bis sehr große SeitenKleine SeitenKleine bis sehr große SeitenKleine bis mittlere Seiten
FunktionsumfangSehr großSehr geringGroß, bestimmte Features müssen über teilweise kostenpflichtige Addons erworben werdenMittel, erweiterte Features erfordern eine kostenpflichtige Premiumversion
FlexibilitätSehr großSehr geringGroßGering-Mittel

Vergleich von MKSEARCH zu anderen Suchextensions 

Um den Punkt nochmals aufzugreifen: Wenn der Index in MySQL liegt, verliert man bei der Konfiguration und der Anpassung bzw. Erweiterung der Suchfunktionalitäten ein großes Maß an Flexibilität. Da es sich dabei auch um keine Speziallösung handelt, welche auf die Anforderungen der Suchfunktion zugeschnitten ist, und sich die Suche die Datenbank mit TYPO3 teilt, verliert man zusätzlich Speicherplatz und Performance. Verwendet man hingegen einen dedizierten Suchserver (Solr, Elastic Search etc.), kann je nach Anwendungsfall bzw. Komplexität, Menge der Daten usw. ein entsprechender Server so punktgenau konfiguriert werden, dass er genau den Anforderungen entspricht.

Wie helfen uns MKSEARCH und Apache Solr nun bei den Herausforderungen im Hochschulkontext?

Strukturelle Komplexität: Inhalte auf Hochschulseiten verteilen sich meist auf verschiedene Microsites (Subdomains) und komplexe Menüstrukturen
Menüstrukturen lassen sich über eine Filterung abbilden, sodass Suchergebnisse bspw. nur aus bestimmten Menüpunkten angezeigt werden (Filter „Verortung“). Diese Facettierung lässt sich dynamisieren, falls sich mal etwas an den Menüstrukturen ändern sollte.

Es ist nur bedingt sinnvoll, die Inhalte nach der jeweiligen Microsite zu filtern – sofern es 50 Microsites gibt (was bei Hochschulen keine Ausnahme sein muss), gäbe es 50 unterschiedliche Filter, wobei viele dieser Microsites inhaltlich so überschaubar sein werden, dass sie nur in den allerwenigsten Fällen ein relevantes Suchergebnis beisteuern können. Hier gilt es also, die wichtigsten Microsites zu identifizieren (bspw. die Fakultätsseiten), und für diese einen (nicht dynamischen) Filter zu ermöglichen, während die Inhalte aller anderen Microsites in die allgemeine Ergebnisliste mit einfließen.

Systematisierte Unschärfe: Aufgrund der thematischen und strukturellen Ähnlichkeit der Microsites (insb. Fakultätsseiten) kann es zur Unschärfe bei den Suchergebnissen kommen (bspw. wenn jede Fakultät eine Seite namens „Dekanat“ hat)
Wenn eine definierte Facettierung nach Verortung oder Microsite vorliegt, lässt sich diese (ähnlich wie der Ergebnistyp) auch direkt am Suchergebnis ausgeben. Am Suchtreffer steht dann nicht nur der (eventuell uneindeutige) Seitentitel, sondern auch in welcher Microsite diese Seite liegt. Diese zusätzliche Information kann sehr wertvoll sein, wenn aus Titel und Teaser nicht ersichtlich wird, in welchem Kontext das Suchergebnis steht.

Möglichkeit von Boosting und der Nutzung von Keywords zur Präzisierung der Suchergebnisse: Hier erweist sich als vorteilhaft, dass keine Seiten gecrawlt werden, sondern Inhaltselemente.

Durch die auf Inhaltselementen basierende Indexierung kann es vorkommen, dass wenn ein Suchbegriff mehrfach auf einer Seite in verschiedenen Inhaltselementen vorkommt, die gleiche Seite mehrfach in der Suchergebnisliste auftaucht. MKSEARCH bietet hier die Möglichkeit, ein Clustering zu aktivieren, sodass dieser Effekt unterbunden werden kann und relevante Trefferseiten nur einmal gelistet werden.

Geschützte Inhalte: Inhalte aus internen Bereichen dürfen nicht über die öffentliche Suche gefunden werden
Inhalte aus geschützten Bereichen (bspw. Intranet) können entweder gezielt von der Indexierung ausgeschlossen werden, oder aber nur dann in den Suchergebnissen Berücksichtigung finden, wenn der User eingeloggt ist. Ob sie dann als normaler Treffer in der allgemeinen Liste mit auftauchen oder es einen eigenen Filter dafür gibt, ist lediglich eine Frage der Konfiguration.

Diversität von Informationstypen und Datenstrukturen: Es gibt unterschiedliche Typen von Datensätzen und Metainformationen, nach denen gesucht werden können sollte
Grundsätzlich lässt sich für die allermeisten Anwendungsfälle ein eigener Indexer schreiben – damit lässt sich sowohl eine Suche in Datensätzen (bspw. News, Veranstaltungen, Personenregister), in Dateien (bspw. PDF, Office) und regulären Seiteninhalten bewerkstelligen.

MKSEARCH kann sich bei Bedarf (bspw. einer entsprechend konfigurierten Personensuche) Daten aus externen Datenquellen wie dem LDAP ziehen.

Auch eine Suche in externen Seiten ist möglich, ebenso wie das Crawling zusätzlicher nicht in TYPO3 befindlicher Seiten mit Apache Nutch. Die Indexierung erfolgt mit Solr und die Ausgabe dann mit mksearch.

Performance: Die Suche muss trotz enormer Datenmengen performant sein.
MKSEARCH in Verbindung mit Apache Solr ist eine inhaltsbasierte Suche. Es werden also Inhaltselemente indexiert, keine Seiten. Das hat den Vorteil, dass kein Crawler benötigt wird, der die Seiten immer und immer wieder scannt. Stattdessen landen Änderungen in einem Indexstack, welcher kontinuierlich im Hintergrund verarbeitet wird und damit ressourcenschonend arbeitet.

Aktualität: Aufgrund der Vielzahl an Redakteuren wird es häufig zu Änderungen am Content kommen, welche dann auch schnellstmöglich gefunden werden können sollen.
MKSEARCH in Verbindung mit Apache Solr ist eine inhaltsbasierte Suche. Es werden also Inhaltselemente indexiert, keine Seiten. Das hat den Vorteil, dass sehr viel granularer gesucht werden kann (Meta-Informationen direkt am Inhaltselement) und kein Crawler benötigt wird, der die Seiten immer und immer wieder scannt. Stattdessen landen Änderungen in einem Indexstack, welcher kontinuierlich im Hintergrund verarbeitet wird und damit gleichzeitig ressourcenschonend arbeitet und eine höchstmögliche Aktualität der Suchergebnisse bietet.

Durch die auf Inhaltselementen basierende Indexierung kann es vorkommen, dass wenn ein Suchbegriff mehrfach auf einer Seite in verschiedenen Inhaltselementen vorkommt, die gleiche Seite mehrfach in der Suchergebnisliste auftaucht. MKSEARCH bietet hier die Möglichkeit, ein Clustering zu aktivieren, sodass dieser Effekt unterbunden werden kann und relevante Trefferseiten nur einmal gelistet werden.

Usability: Der User ist durch Google und Co. unterstützende Funktionen bei der Suche gewohnt und erwartet diese auch – bspw. Synonymsuche, Tippfehlerkorrekturen, Autocomplete, Highlighting.
Fuzzysearch und Highlighting sind gängige Features von Apache Solr, mit denen MKSEARCH problemlos umgehen kann. Zudem bringt MKSEARCH eine Autocomplete-Funktion mit sich. Bei der Synonymsuche kann sowohl ein eigenes Synonymwörterbuch eingebunden werden als auch - im Bedarfsfall -  der Abstraktionsgrad definiert werden. Dabei lässt sich die Anzahl der Verknüpfungspunkte bzw. Iterationsstufen einschränken oder erweitern.

Mehrsprachigkeit: Inhalte können in verschiedenen Sprachen vorliegen.
Für jede zu unterstützende Sprache kann ein eigener, spezifischer Solr-Core konfiguriert werden. Damit besteht absolute Handlungshoheit über das Suchverhalten in den jeweiligen Sprachen – Synonymsuche kann beispielsweise für Deutsch aktiviert sein, während sie für Englisch nicht zur Verfügung steht.
Wichtig ist dabei nur, dass auf TYPO3-Standardmechanismen bei der Übersetzungsfunktion gebaut wird (Anlegen von Sprachlayern).

Im Rahmen des Vortrags wurden zudem die folgenden Fragen gestellt:

Können Platzhalter (*) verwendet werden?
Eine entsprechende Konfiguration ist möglich.

Kann MKSEARCH für mehrsprachige Suchen verwendet werden, ohne dass fremdsprachige Inhalte in einem entsprechenden Overlay gepflegt wurden, sondern bspw. in einem eigenen Seitenbaum?
Ja, das ist prinzipiell möglich. Eine einfache Variante wäre das Konfigurieren unterschiedlicher Seitenbäume in der “Index-Konfiguration” im TYPO3-Backend.

Gibt es ein Backendmodul?
Ja. Dort erfolgt bspw. die Konfiguration der Indexer sowie das manuelle Triggern der Indexierung.

Berücksichtigt MKSEARCH zeitgesteuerte Inhalte und unterschiedliche FE-Nutzergruppen?
Ja, MKSEARCH berücksichtigt die TYPO3-Mechanismen zur Sichtbarkeit von Inhalten (u.a. hidden, starttime, endtime). Die Sichtbarkeit gem. FE-Nutzergruppen muss entsprechend implementiert werden, ist aber technisch möglich.

Beispiele für Suchfunktionen, die mit Solr und MKSEARCH umgesetzt wurden:

< Google Analytics Summit 2017 in Hamburg

Hinterlasse einen Kommentar