Seminararbeit Enterprise Search

Lehrstuhl für Softwaretechnik Universität Augsburg Seminararbeit Enterprise Search im Seminar moderne Entwurfsmethoden für Innovative Softwaresysteme Michael Hübschmann Betreuung: Dr. Hella Seebach Studiengang: Bachelor Informatik Datum: 14. Januar 2014

Abstract. Unternehmensweite Suche ist für jedes größere Unternehmen mittlerweile essentiell geworden, da Mitarbeiter schnell auf großen, heterogenen Datenmengen suchen wollen. Enterprise Search setzt hier an und bietet einen effizienten und zentralen Zugriff auf alle verfügbaren Daten, der auch Zugriffseinschränkungen für den jeweiligen Benutzer beachtet. ElasticSearch wird als neuester Vertreter einer adaptiven, hochskalierbaren Suchmaschine untersucht. 2

Fig. 1. Probleme im Umgang mit Informationen... 5 Fig. 2. Aufbau einer Suchmaschine mit Query-, Index- und Ranking-Modul... 8 Fig. 3. Antwortzeiten des ElasticSearch Servers für den gesamten Testzeitraum. Drei verschiedene Konfigurationen des Servers sind aufgeführt.... 17 Fig. 4. Abschalten von Knoten während des Testlaufs.... 18 3

1 Einleitung und Motivation... 5 2 Datenflut in Unternehmen... 6 2.1 IT-Infrastruktur... 6 2.2 Informations-Management-Systeme... 6 2.3 Unternehmensprozess Informationsgewinnung am Beispiel... 7 3 Unternehmensweite Suchmaschine... 7 3.1 Grundsätzlicher Aufbau einer Suchmaschine... 8 Query-Modul.... 8 Indexierung.... 9 Ranking/Matching.... 9 3.2 Besonderheiten bei Enterprise Search... 10 Heterogene Datenquellen.... 10 Filterung.... 11 Authentifizierung/Rechteproblematik.... 11 4 Technische Konzepte für eine unternehmensweite Suche... 12 4.1 Desktop-Suchmaschine... 12 4.2 Enterprise-Content-Management-Suchmaschine... 12 4.3 Peer-to-peer-Suchmaschine... 13 4.4 Metasuchmaschine... 13 4.5 Client-Server-Suchmaschine... 13 4.6 Expertensuche... 14 5 Praxisbeispiel ElasticSearch... 14 5.1 Grundlagen... 14 5.2 Wurzeln von ElasticSearch... 15 5.3 Besondere Stärken von ElasticSearch... 15 5.4 Evaluierung... 16 5.5 Außergewöhnliche Anwendungen... 19 6 Zusammenfassung und Ausblick... 19 7 Literaturverzeichnis... 21 4

1 Einleitung und Motivation Die heutige Gesellschaft kann man wegen der Fokussierung auf Dienstleistungsunternehmen, die sich in hohem Maße auf Wissen stützen, auch als Wissensgesellschaft bezeichnen. Die Organisation des Wissens stellt bei der wachsenden Menge von Daten dabei eine immer größere Herausforderung dar (1). In vielen Unternehmen liegt dieses Wissen in unterschiedlichster Form, oft nicht einmal digitalisiert, an unterschiedlichsten Stellen. Um Wissen jedoch effektiv nutzen zu können, muss ein Zugriff kurzfristig und schnell möglich sein. Während der Einsatz von Informationstechnologie hierbei schon große Fortschritte ermöglicht, ergeben sich durch den verstärkten Einsatz aber auch neue Problematiken. Speziell die Verknüpfung und der einheitliche Zugang zu den IT-Systemen, die das Wissen enthalten, ist ein aktuelles Thema. Einer Umfrage unter Österreichischen Unternehmen aus dem Jahr 2009 zufolge kommt es bei ~90% der Befragten gelegentlich oder häufig vor, dass Informationen überhaupt nicht gefunden werden können (siehe Abbildung 1). Hierfür ist also eine effiziente und flexible Suche nötig. Fig. 1. Probleme im Umgang mit Informationen (2) In dieser Arbeit sollen in Kapitel 3 und 4 die unternehmensweite Suche selbst sowie ihre Ursprünge beleuchtet werden. Zudem wird ElasticSearch im praktischen Teil der Arbeit in Kapitel 5 als eine der neuesten Realisierungen einer solchen Suche vorgestellt. 5

2 Datenflut in Unternehmen 2.1 IT-Infrastruktur Seit den 80er Jahren hat sich in Unternehmen der Einsatz von IT massiv auf alle Bereiche ausgebreitet. Dabei wuchsen die Anforderungen an IT-Unterstützung meist schneller als der Personalstab, der diese umsetzen sollte, wodurch IT-Infrastruktur immer wieder partiell erweitert oder aufgerüstet wurde. Neue Technologien werden oft nicht ausgehend von Geschäftsführungsebene unternehmensweit, sondern zuerst innerhalb von Abteilungen erprobt und eingeführt, was sich aber nur mit einer Änderung der Grundeinstellung verbessern kann: Die IT sollte nicht erst dann in Aktion treten, wenn es darum geht, geplante Wertsteigerungen des Unternehmens umzusetzen. Als Werttreiber hat die IT die Aufgabe, Wertsteigerungspotentiale für das Unternehmen zu identifizieren und proaktiv voranzutreiben (3). Viele Informationen liegen unter anderem aufgrund dieses Missmanagements meist weit verstreut auf unterschiedlichen Systemen, lokal auf Mitarbeiterrechnern oder auf Servern. 2.2 Informations-Management-Systeme Zur Lösung dieses Problems setzen viele Unternehmen inzwischen auf eine zentralisierte Speicherung der wichtigsten Daten mithilfe von IT-Systemen. Vor allem im Internetumfeld weit verbreitet sind Content-Management-Systeme kurz CMS. Die Ausgabe der Inhalte erfolgt meist in Form von Websites, aber das System selbst ist unabhängig vom Ausgabemedium. Ein CMS läuft zentral auf einem Server und ermöglicht daher verschiedenen Benutzern im Netzwerk das Erstellen und Abrufen von Inhalten. Dabei müssen die Autoren nicht über Programmierkenntnisse verfügen, sondern editieren über eine benutzerfreundliche grafische Oberfläche - wie in einem Textverarbeitungsprogramm - die Inhalte. Diese können aber auch Audio- oder Videoformate sein. Meist werden die Inhalte hierarchisch gegliedert und sind mit Metadaten (Erstelldatum, Autor) versehen. Dokumenten-Management-Systeme unterscheiden sich von CMS insofern, als dass die Speicherung der Informationen nicht medienneutral erfolgt, sondern in Form von spezifischen Dokumenten oder Datenstrukturen. Zusätzlich kommt hier oft eine Versionsverwaltung zum Einsatz, mithilfe derer alle Änderungen rückverfolgt und einem Benutzer zugeordnet werden können. Bei Wissens-Management-Systemen hingegen liegt der Fokus auf der Integration von Informationen und entsprechenden Querverweisen. Beim bekanntesten Wissens- Management-System MediaWiki können Einträge zusätzlich von allen Benutzern bearbeitet und kommentiert werden. 6

2.3 Unternehmensprozess Informationsgewinnung am Beispiel Bei einem mittelgroßen Industrieunternehmen sind mehrere Systeme im Einsatz. Während die meisten produktbezogenen Informationen mithilfe von SAP-Lösungen verwaltet werden, werden Projektinformationen in verschiedenen Microsoft Sharepoint Systemen verwaltet. Globale und abteilungsspezifische Wikis werden mit allgemeinem Wissen gefüttert. In der Softwareentwicklung kommen noch zusätzliche Systeme wie Microsofts Teamfoundation Server, IBM Software und Eigenentwicklungen hinzu. Unternehmensweit wird durch ein Portal versucht, alle Informationen zentral zugänglich zu machen, auch Dokumentvorlagen und Ähnliches findet sich hier. Es sind also verschiedene Systeme (vgl. Kapitel 0) parallel im Einsatz. Will ein Mitarbeiter Informationen zu einem bestimmten Produkt, kann er die Suche in SAP- Systemen nutzen. Benötigt er zusätzlich jedoch Informationen aus dem Entstehungsprozess oder patentrechtliche Daten, muss er zu anderen Systemen wechseln. Die Zuordnung zum Produkt ist dabei schwierig und zu den meisten Systemen braucht man für den Zugriff allgemeine Berechtigungen oder Zugangsdaten. Eventuell sind diese Informationen auch in einem der Wikis, die einzeln durchsucht werden müssen. Um bei weiteren Fragen schnell einen Kollegen zu kontaktieren, muss er im Portal recherchieren, eventuell Organigramme durchforsten, usw. Dies alles kostet viel Zeit, obwohl es gesammelte Informationen zu nur einem Produkt sind. 3 Unternehmensweite Suchmaschine Um für Mitarbeiter einen effizienten Zugriff auf alle im Unternehmen verfügbaren Daten zu bieten, benötigt man daher eine unternehmensweite Suchmaschine. Für eine solche Suchmaschine hat sich der Begriff Enterprise Search oder Federated Search etabliert. Den Inbegriff für eine Suchmaschine schlechthin stellt Google im Internet dar. Mitarbeiter sind daher im Umgang mit Suchmaschinen über Jahre durch Google geprägt worden und Enterprise Search bricht mit dessen Grundsätzen nicht. Übernommen wurde: Der Ein-Feld Ansatz, also die Eingabe sämtlicher Suchbegriffe in ein einziges Textfeld Umfassende und nach Millisekunden gewonnene Suchergebnisse Listenform der Ergebnisse Diese Punkte betreffen allerdings hauptsächlich das Front-end, also die Benutzeroberfläche. Vor allem im Back-end, bei Logik und Informationsgewinnung, unterscheidet sich eine unternehmensweite Suchmaschine allerdings eklatant von Internetsuchmaschinen. Dies liegt z.b. an der Vielfalt von Datenquellen, die nicht nur Websites, sondern auch Datenbanken und Anwendungen sein können. Folglich reicht Googles Pagerank, bei dem Suchergebnisse nach Anzahl der Verlinkungen bewertet werden, nicht aus. Zu- 7

dem will der Suchende im Internet oft nur Fakten finden, während im Unternehmen sehr partikulare Suchbedürfnisse gestillt werden müssen (4). In Unternehmensnetzwerken ist zudem von Vorteil, dass es bereits eine eindeutige Identifizierung der Benutzer und keinen Spam oder Werbung gibt. 3.1 Grundsätzlicher Aufbau einer Suchmaschine Es gibt Unterschiede in der Umsetzung, drei Module haben jedoch die meisten Suchmaschinen gemein: Das Query-Modul sucht im Index nach dem Suchbegriff, das Index-Modul erstellt aus Quelldaten den Index und hält ihn aktuell und das Ranking- Modul sortiert die Treffer vor der Ausgabe nach Relevanz (5). Fig. 2. Aufbau einer Suchmaschine mit Query, Index und Ranking-Modul Query-Modul. Das Query-Modul kümmert sich um die Umwandlung der Benutzereingabe in eine auf dem Index suchbare Form. Suchformulare machen die gebräuchlichsten Einschränkungen wie Und/Oder-Verknüpfungen und unterschiedliche Gewichtung oder Ausschluss von Suchbegriffen leicht anwendbar, diese werden vom Query-Modul umgesetzt (5). 8

Indexierung. Um mit einer Suchmaschine nicht auf Dateien selbst suchen zu müssen, was langsam und rechenintensiv wäre, nutzt man einen Index, auf dem die Suchanfragen ausgeführt werden. Der Suchmaschinenindex ist darauf optimiert, möglichst schnell durchsucht werden zu können, indem er z.b. keine Formatierungsinformationen sondern ausschließlich reinen Text enthält. Indexierung, auch Crawling genannt, bezeichnet dabei den Prozess des Durchsuchens aller Quelldaten, aus welchen dann komprimierte und mit Metainformationen versehene Indexeinträge erstellt werden. Metainformationen sind zusätzliche Attribute zu den Quelldaten und werden hinzugefügt, um die Auffindbarkeit zu erhöhen. Die wichtigsten Metainformationen sind das Erstelldatum und das Datum der letzten Änderung sowie vorkommende Schlüsselwörter ( tags ) oder Kategorien. Außerdem wird als Metainformation vermerkt, wo und wie auf das Quelldokument zugegriffen werden kann. Der Index muss regelmäßig aktualisiert werden, sonst liefert die Suche veraltete Ergebnisse. Nach der Erstindexierung wird nur noch für alle Änderungen, meist anhand des sowieso vorhandenen last-change Datums, der Index erstellt bzw. geändert. Bei großen Quelldatenmengen wäre der Aufwand für jede Aktualisierung des Index sonst zu groß. Neueste Suchlösungen setzen auf Push-Indexierung, bei der die Datenquellen selbst Änderungen an die Suchmaschine schicken. Der Vorteil liegt in der ständigen Aktualität des Index. Im Gegensatz zum konventionellen Ansatz, nach dem die Indexierung wegen geringer Auslastung der Quellsysteme meist auf die Nacht gelegt wird, erhöht sich hier jedoch die Last noch zusätzlich schon während der Operationen. Ranking/Matching. Das Ranking dient dazu, dem Benutzer zu seinem Suchbegriff möglichst relevante Ergebnisse zu liefern. Bei Enterprise Search findet hier meist eine Kombination aus verschiedenen Verfahren Anwendung. Prominent werden Ergebnisse gelistet, die genau den Suchbegriff enthalten (Matching), gewichtet nach Häufigkeit des Suchbegriffes im Eintrag. Phonetisch ähnliche Wörter können direkt oder erst bei leeren Ergebnissen abgefragt werden. Eine weitere wichtige Einflussgröße stellen statische Listen dar, die von Administratoren gepflegt werden und Suchbegriffe fest mit Ergebnissen verbinden. Oft wird dies für Standardanwendungen oder Dokumente genutzt, sodass z.b. ein Dokument Urlaubsantrag auch als erstes Ergebnis bei entsprechender Eingabe erscheint. Durch neuartige Ansätze versucht man die Ergebnisqualität weiter zu verbessern. Bei Enterprise Search kann der Benutzerkontext eine wichtige Rolle spielen. 9

In einer Firma bestehen schon feste Strukturen (technisch meist in Active Directory 1 ), die Mitarbeiter ihren Abteilungen oder bestimmten Fachbereichen zuordnen. Damit lassen sich bestimmten Benutzergruppen spezifische Rankings zuordnen. Nötig ist das, da derselbe Begriff im Kontext verschiedener Benutzergruppen unterschiedlichste Bedeutungen haben kann, aber nur die jeweilig relevanten Ergebnisse weit oben erscheinen sollen. Der Begriff Vertrag sollte für Mitarbeiter der Personalabteilung zum Beispiel Ergebnisse rund um den Arbeitsvertrag liefern, während es in der Support-Abteilung meist eher um Kundenverträge geht. Dabei kann die Zuordnung entweder manuell oder automatisiert erfolgen, indem vergangene Suchanfragen und entsprechende Aufrufe nach Benutzergruppen ausgewertet werden. Der Verfasser eines Dokumentes kann ebenfalls für die Einstufung verwendet werden (6). Web 2.0 Ansätze sind in Unternehmen beliebt, Social Media ist daher auch für Enterprise Search ein Thema. Social Media im Unternehmenskontext bedeutet, dass alle Mitarbeiter sich aktiv durch die Arbeit an Daten beteiligen. Bei der Suche können Benutzerbewertungen, ähnlich wie das Facebook-Like in das Ranking einfließen oder Dokumente z.b. durch Benutzer getaggt, also um bestimmte Metainformationen ergänzt werden (7). Die Ergebnisse bleiben dadurch stets dynamisch, aktuell und auch bei großen Unternehmen qualitativ hochwertig. Administratoren werden zudem bei der manuellen Zuordnung entlastet. 3.2 Besonderheiten bei Enterprise Search Heterogene Datenquellen. Für Enterprise Search muss eine Vielzahl unterschiedlichster Datenquellen herangezogen werden. Wie im Internet, so gibt es auch im Unternehmen Websites. Einerseits öffentlich verfügbar wie die Unternehmenswebsite, andererseits intern oder sogar nur für kleine Benutzergruppen verfügbar, wie Wikis oder Projektseiten. Weil sie aus reinem Text bestehen, sind diese Seiten für die Suchmaschine leicht zu durchsuchen und per Hyperlink in der Ergebnisliste referenzierbar. Durch die bekannte HTML Seiten-Struktur sind Metainformationen zudem leicht zu extrahieren. Bei allen Unternehmen sehr wichtig, stellen Datenbanken aber eine größere Herausforderung dar. Um die Relevanz der Ergebnisse zu erhöhen, werden spezifische Tabellen oder Spalten festgelegt, in denen Daten für den Benutzer stehen. Da ein Datenbankeintrag für den Benutzer oft unleserlich ist, müssen die Daten aufbereitet werden, oder die Suchmaschine muss in der Ergebnisliste auf eine entsprechende Anwendung verweisen, die die Informationen darstellt. Die größten Datenmengen liegen in Filesystemen gespeichert vor und dementsprechend fallen hier die meisten Suchanfragen an. Da bei Filesystemen Zugriffsrechte und schnelles Lesen im Vordergrund stehen, ist eine direkte Suche sehr langsam. 1 Active Directory ist ein Verzeichnisdienst für Windows Netzwerke, mit dem die Gliederung eines Unternehmens in Abteilungen nachgebildet wird und der Zugriff auf alle Netzwerkressourcen administriert werden kann. 10

Auch liegen die Daten in vielen verschiedenen Dateiformaten vor, in manchen Fällen kann sogar eine Versionsverwaltung integriert sein. Die Suchmaschine muss all diese Dateiformate lesen können und eventuell verschiedene Revisionen der Versionsverwaltung durchsuchen. Auch vorhandene Offline Daten wie z.b. DVDs sollten von der Suchmaschine, mit entsprechendem Verweis auf den Zugangsort, gefunden werden können. Zuletzt muss auch die Anbindung an vorhandene (Web-)Anwendungen möglich sein. Die Lösung nennt sich Konnektor und erlaubt der Suchmaschine von der Anwendung Informationen zu gewinnen. Der Konnektor übernimmt dabei die Umwandlung von anwendungsspezifischen zu suchmaschinenlesbaren Daten. Hinter einer Anwendung liegen zwar auch meist Datenbanken und die Ausgabe mag in HTML-Seiten erfolgen, doch ein Konnektor bietet (meist über eine API) einen schnelleren und bei Anwendungsupdates konsistenten Zugang, der nur im Anwendungskontext wichtige Daten liefert. Die Anzahl unterschiedlicher Datenquellen ist das eine Problem, die Ergebnisse je nach Datenquelle zu gewichten, oder die richtigen Quellen für eine Suchanfrage einzugrenzen, ist das andere Problem. Hier zeigen Untersuchungen, dass das Gleichgewicht zwischen hoher Treffergenauigkeit und schneller Suche schwer zu finden ist (8). Filterung. Bei vielen Treffern zu einem Suchbegriff ist eine Filterung der Ergebnisse unerlässlich. Mittels facettierter Suche können die Ergebnisse nach bestimmten Kategorien(Facetten) weiter eingeschränkt werden. Diese Kategorien ergeben sich bereits aus Attributen der Quelldaten oder werden durch dynamisches Gruppieren 2 erzeugt. Eine kurze Ergebnisvorschau, z.b. die Anzahl der erwarteten Treffer, hilft dem Benutzer beim Einschränken. Bekannteste Kategorien sind Erstelldatum, Ergebnis(datei)typ und Quelle. Weil bei Enterprise Search so verschiedenste Datenquellen durchsucht werden, ist diese zusätzliche Information zum Suchbegriff wichtig und wird im Vergleich zur Internetsuche deutlich häufiger genutzt (9). Zusätzlich müssen bereits die Datenquellen selbst gefiltert werden, um irrelevante, veraltete oder mehrfach vorhandene Daten nicht mit in den Index aufzunehmen (10). Für jedes Dateiformat wird ein anderer Filter benötigt, um Inhalte und Metainformationen zu extrahieren. Authentifizierung/Rechteproblematik. Zugriffsrechte spielen in vielen Unternehmen eine wichtige Rolle. Sicherheitskritische Dokumente dürfen ausschließlich bestimmte Mitarbeiter bearbeiten, personalbezogene Daten müssen diskret behandelt werden. 2 Dynamisches Gruppieren beschreibt das Unterteilen von Datenobjekten nach vorher nicht festgelegten Kriterien zu Gruppen. Die Kriterien hängen meist von der gewünschten Menge an Ergebnisgruppen ab. 11

Die aus meist auch per Active Directory verwalteten Rechten folgenden Einschränkungen müssen bei der Suche berücksichtigt werden (11). Wird aber erst beim Suchvorgang für jeden Treffer im Quellsystem überprüft, ob der Benutzer berechtigt ist, zieht das eine Mehrbelastung und lange Antwortzeiten nach sich. Somit werden die Berechtigungen meist direkt bei der Indexierung in die Suchmaschine übernommen, was allerdings ein potentielles Datenleck darstellt, da die Zugriffsrechte doppelt gehalten werden. Sind die Daten in der Suchmaschine veraltet, könnte fälschlicherweise Zugriff gewährt werden. 4 Technische Konzepte für eine unternehmensweite Suche Am Anfang aller Suchkonzepte steht die anwendungsspezifische Suche. Durch die Beschränkung auf eine Anwendung und die lokalen Daten der Anwendung erreicht eine solche Suchmaschine eine hohe Ergebnisqualität. Vor allem die jeweils wichtigsten Metainformation können da bekannt - beachtet werden. Eine Indexierung kann effizient implementiert werden, weil Änderungen vom Benutzer ausgehen und der Index sofort aktualisiert wird. Ein Administrationsaufwand entfällt aufgrund des einzigen Benutzers ebenfalls. Benutzer sollen aber unternehmensweit auf alle Daten Zugriff haben. Die wichtigsten Ansätze zum Aufbau einer Suche für Enterprise Search werden im Folgenden kurz vorgestellt. Die Auflistung stützt sich größtenteils auf Ausführungen im Artikel Enterprise Search - Suchmaschinen für Inhalte im Unternehmen (12). 4.1 Desktop-Suchmaschine Die Desktop-Suchmaschine ist - da in allen Betriebssystemen integriert - weitverbreitet. Während zuerst noch ineffizient und langsam direkt nach Dateinamen in den Verzeichnissen gesucht wurde (z.b. Microsoft Windows XP), hat sich eine Indexierung von lokalen Dateien und Anwendungen, aber auch Netzlaufwerken sowie Intranet/Internetseiten inzwischen etabliert. Der größte Nachteil besteht daher auch darin, dass zentrale Informationsquellen wie Netzlaufwerke von allen zugreifenden Benutzern unabhängig für einen eigenen Index durchsucht werden, was eine große Last für diese zentralen Systeme erzeugt. Jede Suchmaschine muss zudem pro Rechner eingerichtet und administriert werden. Der Einsatz im Enterprise Search Umfeld für viele Benutzer ist somit nicht praktikabel und eine Desktop-Suchmaschine wird meist nur zum Durchsuchen lokaler Dateibestände genutzt. 4.2 Enterprise-Content-Management-Suchmaschine Eine Suche auf Enterprise Content Management Systemen ist eine anwendungsspezifische Suche auf einem erweiterten CMS (vgl. CMS und DMS S. 6). Die dementsprechend großen Vorteile bezüglich Indexierung, Ergebnisqualität und Rechteverwaltung kommen erst zum Zuge, wenn alle Unternehmensdaten in diesem ECM gepflegt wer- 12

den. Die Migration zu einem solchen System ist aufwändig, trotzdem kann ein ECM manchmal nicht alle Anforderungen vollumfänglich abdecken. Beispielhaft sieht man das am weitverbreiteten Microsoft Sharepoint: Der Fokus liegt mehr auf abteilungsspezifischem als auf unternehmensweitem Einsatz. Eine Dokumenten-/Versionsverwaltung ist nur unvollständig vorhanden und das Einbinden von Drittanwendungen - z.b. um diese in die Suche einzuschließen ist kompliziert (13). 4.3 Peer-to-peer-Suchmaschine Eine Peer-to-peer kurz P2P Suchmaschine nutzt verknüpfte gleichwertige Peers, die jeweils einen eigenen Index bereitstellen. Bei einer Anfrage wird somit der eigene Index und, nach dem Metasuchprinzip, die der verbundenen Peers durchsucht. Der Hauptvorteil liegt somit in der Skalierbarkeit, bei vielen Peers steigt die Netzauslastung aber stark an. Zwecks Administration und Redundanz in Indexen ergeben sich dieselben Probleme wie bei einer Desktop-Suchmaschine. Anwendung findet dieses Prinzip nur wenig, und das Hauptaugenmerk liegt hier meist auf Ausfallsicherheit oder der zusätzlichen Verfügbarkeit von lokalen Dokumenten anderer Peers für die Suche. 4.4 Metasuchmaschine Mit dem Konzept der Metasuchmaschine wird versucht, die Vorteile einer anwendungsspezifischen Suchmaschine für das ganze Unternehmen verfügbar zu machen. Die Suchmaschine leitet Suchanfragen nach einer Aufbereitung an verschiedene Quellsuchmaschinen weiter. Die Ergebnisse dieser Suchmaschinen werden dann vereinigt und dem Benutzer präsentiert. Das Ranking gestaltet sich durch die vorkonfektionierten Ergebnislisten der Quellsuchmaschinen schwierig und Redundanzen treten leicht auf, wenn unterschiedliche Quellsuchmaschinen auf gleiche Datenquellen zugreifen. Durch eine Metasuchmaschine könnten im Enterprise-Search-Kontext alle Quellsysteme eingebunden werden und mithilfe von Impersonation 3 auch Zugriffseinschränkungen gewahrt bleiben. Da hier allerdings das Einschränken nach Metainformationen sowie Geschwindigkeit eine große Rolle spielen, wird das Prinzip meist nur zusätzlich eingesetzt. 4.5 Client-Server-Suchmaschine Am weitesten verbreitet sind Client-Server-Suchmaschinen. Alle relevanten Operationen laufen zentral auf einem Server, während die Clients nur die Benutzeroberfläche rendern und Suchanfragen an den Server senden. Dadurch ist jede (administrative) Änderung sofort für alle Clients gültig. Teilweise werden auch Elemente der Metasuchmaschine verwendet, sodass nicht nur der Index auf dem Server verwendet wird. 3 Weiterreichen der Benutzeridentität, sodass sich eine Anwendung als derjenige Benutzer ausgeben kann und auf entsprechende Ressourcen Zugriff hat. 13

Alle Zugriffseinschränkungen müssen hier ebenfalls zentral verwaltet werden, was Probleme aufwirft (siehe Kapitel 0). 4.6 Expertensuche Vor allem Ingenieure vertrauen hauptsächlich auf die Expertise von Kollegen (14). Um bei großen Firmen noch den Überblick zu behalten, ist eine Suche nach Experten für bestimmte Fachgebiete daher notwendig. Die Datenquelle kann ein Verzeichnisdienst wie Active Directory sein, aber auch manuell gepflegte Datenbanken oder indirekt durch Analyse von Dokumenten und deren Urheber gewonnene Daten werden verwendet. Eine Expertensuche wird häufig in Enterprise Search integriert um in einer Oberfläche alle Funktionalitäten abrufbar zu machen. 5 Praxisbeispiel ElasticSearch ElasticSearch ist eine Open-Source Client-Server Suchmaschine für Enterprise Search. Anhand dieser Suchmaschine sollen einige Aspekte von Enterprise Search untersucht werden. 5.1 Grundlagen ElasticSearch nutzt als Client-Server Suchmaschine offene Standards und Technologien, die hier zum besseren Verständnis kurz Erwähnung finden sollen. Mit einem ElasticSearch Server kommuniziert man per RESTful API. REST ist ein Konzept, dass verschiedene Eigenschaften wie z.b. Zustandslosigkeit, Adressierbarkeit und festgelegte Operationen für entsprechende Dienste vorschreibt. Ein solcher Dienst wird durch das bekannte HTTP-Protokoll umgesetzt und auch ElasticSearch verwendet HTTP-Anfragen. Jede Suchanfrage wird als URL formuliert und ist eindeutig (Adressierbarkeit), führt also immer dieselbe definierte Funktion aus. Anfragen enthalten zudem eine der HTTP-Operationen 4. Damit ist bei geringstem Datenaufkommen eine einfache Steuerung aller Funktionen von ElasticSearch möglich. Javascript ist eine objektorientierte Skriptsprache und stellt einen Quasi-Standard bei der Client-seitigen Webentwicklung dar. Mit Javascript lassen sich dynamische Websites 5 erstellen. Obwohl Javascript beim ElasticSearch Server direkt keine Verwendung findet, sind fast alle Client-Anwendungen dafür in Javascript verfasst. Einer der Gründe hierfür ist auch das bei ElasticSearch verwendete leichtgewichtige Datenübertragungsformat JSON (Javascript Object Notation). JSON hat deutlich weniger 4 5 Die verwendeten HTTP-Operationen sind GET, POST, PUT, DELETE, HEAD. Sie werden wie der Wortlaut eingesetzt, also z.b. GET um Informationen vom Server zu bekommen. Dynamische Websites reagieren auf Benutzereingaben, ohne dass ein komplettes neu-laden der Seite erfolgt. 14

Overhead 6 als das ebenfalls weitverbreitete XML. Inhalte im JSON-Format können in Javascript direkt als Datenobjekte verwendet werden und in fast allen Programmiersprachen gibt es entsprechende Parser. Ein ElasticSearch Server nutzt das JSON- Format zur effizienten Datenübertragung von Suchanfragen, Suchergebnissen, sowie allen Steuerungsoperationen. ElasticSearch baut auf der Open-Source Programmbibliothek Apache Lucene auf und vereinfacht und erweitert dabei deren Funktionen. Apache Lucene selbst ermöglicht hauptsächlich effiziente Volltextsuche. Ursprünglich für Java geschrieben gibt es Portierungen für alle wichtigen Programmiersprachen (15). 5.2 Wurzeln von ElasticSearch ElasticSearch entstand 2010 als Nachfolger des kleinen Open-Source Such-Projekts Compass. ElasticSearch wurde komplett neu entwickelt, da die Anforderungen an Skalierbarkeit und facettierte Suche durch eine Erweiterung des Vorgängers nicht mehr erfüllt werden konnten (16). 2012 haben einige der Entwickler von ElasticSearch und Apache Lucene eine Firma gegründet, um Support für ElasticSearch leisten und Fortbildungen halten zu können. Bei einigen großen Internetunternehmen wurde ElasticSearch mittlerweile durch diese Firma erfolgreich implementiert (17). Das Marktangebot an Open-Source Enterprise Search Lösungen ist insgesamt sehr klein. Als größtes Projekt, noch vor ElasticSearch, gilt Solr (sprich [Solar]). Es setzt wie ElasticSearch auf Apache Lucene auf. Solr wird dabei als offizielle Enterprise Search Lösung der Apache Software Foundation entwickelt und bietet hohe Skalierbarkeit und Performance (18). Im Vergleich zu ElasticSearch ist die Aktivität des Open-Source Projektes jedoch inzwischen geringer (19). Konfiguration sowie Wartung sind bei Solr zudem aufwändiger. Trotzdem hat Solr als Haupkonkurrent viel zur schnellen Entwicklung von ElasticSearch beigetragen, da von Solr bekante Probleme bereits von Beginn an vermieden werden konnten. 5.3 Besondere Stärken von ElasticSearch ElasticSearch hat im Vergleich zu Apache Solr Vorteile bei der verteilten Suche. Durch verbundene Suchknoten stellt ElasticSearch eine hohe Verfügbarkeit sicher, erhöht die Flexibilität des Systems und hat vor allem bei Big-Data Performance- Vorteile gegenüber Apache Solr. Auch das Handling von mehreren Indizes und Knoten ist bei ElasticSearch deutlich unkomplizierter (17). Der Aufbau von ElasticSearch ist ebenso unkompliziert. In einem Index werden unterschiedlichst strukturierte Dokumente gespeichert. Ein Dokument besteht aus mehreren Feldern, die je nach Inhalt automatisch einen Datentyp zugewiesen bekommen und auch selbst wieder Dokumente enthalten können, multivalued Felder dürfen pro Dokument sogar mehrfach vorkommen. 6 Overhead (~Überschuss) beschreibt den Anteil an den Gesamtdaten, der vom Datenformat selbst belegt wird, also nicht aus den zu transportierenden Daten besteht. 15

In ElasticSearch können mehrere Indexe erzeugt werden, und entsprechend kann auch über mehrere Indexe gesucht werden (20). Eine weitere Besonderheit ist das Sharding, das Aufsplitten der Daten. Ein Knoten stellt eine eigenständige Einheit dar, meistens entspricht ein Knoten einem realen Rechner oder Server. Falls ein Knoten die benötigte Leistung nicht erbringen kann, wird ein Teil der Dokumente auf einen neuen zweiten Knoten bewegt. Die Suche läuft nun wie bei P2P Suchmaschinen (vgl. Kapitel 4.3). Möglich ist außerdem Replication. Das bedeutet, dass ein Knoten dupliziert wird, und im Falle eines Ausfalles das Duplikat einspringen kann, was die Ausfallsicherheit erhöht (20). Sharding, Replication sowie multiple Indizes und Knoten werden automatisch verwaltet, was beim Einrichten einer solchen Suche viel Arbeit erspart. Die Suche wird bei Elastic Search near real-time, also nahezu in Echtzeit durchgeführt. Jede Änderung im Index wird sofort an alle relevanten Knoten weitergegeben, und die nächste Suchanfrage liefert bereits ein aktuelles Ergebnis. In Kombination mit Push-Indexierung fließt jede Änderung auf den Quellsystemen sofort in den Index ein, womit ein wirkliches Suchen in Echtzeit möglich ist. 5.4 Evaluierung Um die Performance von ElasticSearch genauer zu untersuchen, wird ein Testsystem aufgesetzt. Als Server wird eine Workstation mit 4 Ghz Intel Quadcore und 8 GB RAM verwendet. ElasticSearch 0.90.7 ist auf einer SSD installiert. Health Monitoring, also das Überwachen von Auslastung und Konfiguration des Servers wird mithilfe der Webanwendung ElasticHQ 7 betrieben, welche als Plugin auf dem ElasticSearch Server installiert wird. Eingaben werden entweder über diese grafische Oberfläche oder über das Browser Plugin Sense 8 getätigt, welches die verschiedenen REST Anfragen ermöglicht. Um dem ElasticSearch-Index nun Dokumente hinzuzufügen, wählt man entweder das bereits beschrieben Push-Verfahren, bei dem das Quellsystem entsprechende REST Anfragen an den ElasticSearch Server schickt, sobald sich Änderungen ergeben, oder man wählt das Pull-Verfahren, bei dem sich der ElasticSearch-Server selbst Daten vom Quellsystem holt. Das funktioniert mithilfe eines bei ElasticSearch river genannten Plugins, welches die Interpretation der Datenquelle übernimmt und die Daten in ElasticSearch lesbare Dokumente umwandelt. Nahezu für alle Arten von Datenquellen sind bereits rivers verfügbar. Die Konfiguration mithilfe von river-plugins erfordert also keine Manipulationen an der Datenquelle und vor allem muss eine Datenquelle auch keine zusätzlichen Funktionalitäten bieten. Daher wird für diese Evaluation ein Wikipedia-river verwendet, und damit ein Dump-file aller Artikel der deutschsprachigen Wikipedia (~12 GB) eingelesen. In ElasticSearch wird daraus ein ~9GB großer Index, unterteilt in 5 gleich große Shards. 7 www.elastichq.org 8 chrome.google.com/webstore/detail/sense 16

Das Hinzufügen von Dokumenten zum Suchmaschinenindex verursacht jedoch hauptsächlich eine hohe Last bei Quellsystemen und im Netzwerk. Interessanter ist es daher, die Performance bei Suchanfragen auf großen Datenbeständen zu messen. Mithilfe von Apache JMeter 9 werden von einem zweiten Rechner aus vorkonfigurierte Anfragen gesendet und die Antwortzeit gemessen. Da bei ElasticSearch die Ergebnisse zwischengespeichert werden, wird für jede Anfrage ein anderer Suchbegriff verwendet 10. Der begrenzende Faktor in diesem Szenario ist die CPU-Leistung des ElasticSearch Servers. Die Rechenkerne werden voll ausgelastet. Je effizienter diese Leistung genutzt wird, desto eher ist die Anzahl an gestellten Suchanfragen vollständig abgearbeitet. Fig. 3. Antwortzeiten des Servers über den gesamten Testzeitraum. Drei verschiedene Konfigurationen des ElasticSearch Servers sind aufgeführt. Erstellt mit Apache JMeter 9 Bei mehreren Knoten wird der vorhandene Index von ElasticSearch automatisch in Shards aufgeteilt und den Knoten zugewiesen. Ab 10 Knoten verdoppelt sich der Speicherplatzbedarf in dieser Anwendung, da ElasticSearch jeden der 5 Shards dupliziert. Damit ist eine Kopie als Ausfallsicherung vorhanden und eine weitere Aufteilung erfolgt nicht mehr. Die Unterschiede in der Shard-Anzahl können für das Beispiel vernachlässigt werden, da die zusätzlichen Slave Shards nicht durchsucht werden, und nur bei Ausfall eines Knotens mit Master Shard ersatzweise eingebunden werden. Die Messungen ergeben ein klares Bild. Sowohl Antwortzeiten als auch Durchsatz sind bei einem einzigen Knoten natürlich am Besten. Die Leistung fällt jedoch bei deutlich größerer Knotenzahl auch nur um maximal 20% ab. Dieser Leistungsverlust 9 jmeter.apache.org 10 Hierfür wurde der Rohtext des Buches Effi Briest von Theodor Fontane bei jedem Satzzeichen aufgeteilt, sodass man am Ende ~15000 verschiedene Suchterme aus jeweils 1-30 Wörtern erhält 17

ist darauf zurückzuführen, dass die Ergebnisse einer Suchanfrage nun von mehreren getrennten Knoten zusammengeführt werden müssen. Zwischen 10 und 20 Knoten gibt es keinen relevanten Performance-Unterschied mehr. Allerdings erhöht sich der Arbeitsspeicherbedarf mit jedem zusätzlichen Knoten deutlich. Durch das Aufteilen auf mehrere Knoten kann die Leistung also gesteigert werden, ohne dass es zu unverhältnismäßig großen Verlusten durch die Kommunikation zwischen den Knoten kommt. Lohnt sich der Einsatz von mehreren Knoten aber auch, wenn die Leistung einer Instanz eigentlich ausreichen würde? Die Vorteile werden in Abbildung 4 deutlich. Es wurde der gleiche Testaufbau mit 10 Knoten verwendet, doch während des Testlaufes wurden Knoten abgeschaltet. Nach dem Ausfall eines Knotens mit Master Shard bei Sekunde 33 springt ohne Verzögerung sofort der Knoten mit entsprechendem Slave Shard ein und es wird weiterhin gesucht. Fig. 4. Abschalten von Knoten während des Testlaufs. Erstellt mit Apache JMeter 9 Ein wenig anders verhält es sich nach Verlust von beiden Knoten zu einer Shard, wie es bei Minute 2 passiert. Die komplette Shard ist jetzt offline, es fehlen also 20% des Indexes. Der ElasticSearch Server beginnt daher sofort, die Datenquelle wieder zu indexieren, währenddessen laufen die Suchanfragen weiter auf dem unvollständigen Index. Durch die Verkleinerung können die Anfragen schneller berechnet werden, sodass trotz gleichzeitiger Neuindexierung der Durchsatz konstant gehalten wird. Die Qualität der Suchergebnisse ist zu Beginn zwar schlecht, verbessert sich jedoch progressiv, während der Index neu erstellt wird. Die Untersuchungen haben gezeigt dass ElasticSearch seine Versprechen in Bezug auf Skalierbarkeit und Adaptivität einlösen kann. Gruppen von Knoten sind leicht zu verwalten und verursachen nur geringe Effizienzeinbußen. Durch eine Sicherstellung des Dauerbetriebs selbst bei Teilausfällen und gleichzeitig minimalem Administrationsaufwand beweist ElasticSearch seine Praxistauglichkeit. 18

5.5 Außergewöhnliche Anwendungen In Forschungsprojekten wird aus obigen Gründen immer häufiger auf ElasticSearch gesetzt. Dabei unterscheiden sich die untersuchten Themengebiete erstaunlich stark voneinander: Im Rahmen der Initiative SIMSSA 11 wird das Ziel verfolgt, Liederbücher durchsuchbar zu machen. Zwar sind viele Liederbücher und Noten bereits digitalisiert verfügbar, in den meisten Fällen jedoch nur als Scan, also nicht maschinensuchbarer Bilddatei. Zuerst am Beispiel eines 2300 Seiten starken Liederbuches kombinierte das Team daher automatisierte Texterkennung mit automatisierter Noten/Musikerkennung. Die gewonnenen Daten wurden in Datenbanken einsortiert, die jeweils Notenfolgen bestimmter Länge enthalten. Dadurch sind die Daten zusätzlich mehrfach vorhanden. Um diese gewaltige Datenmenge schnell durchsuchen zu können, wurde jetzt ElasticSearch verwendet. ElasticSearch bietet dank der Möglichkeit, multiple Indizes einzusetzen, die Kapazität und gleichzeitig die Geschwindigkeit, die für dieses Projekt nötig ist (21). Auf den ersten Blick völlig verschieden dazu ist eine andere Anwendung. Biologen analysieren Gensequenzen um Unterschiede und Gemeinsamkeiten bei verschiedenen Lebewesen feststellen zu können und daraus z.b. Heilmethoden abzuleiten. Dabei geht es aber ähnlich wie bei den Notenfolgen im Grunde darum, Vorkommen von bestimmten Buchstabenfolgen zu finden. Die Datenmengen machten bisher solche Vergleiche sehr zeitintensiv, mithilfe von ElasticSearch hat ein Forscher die Abfragezeiten allerdings auf unter eine Minute reduzieren können. Zudem gelang dem Biologen als eigentlich Fachfremdem die Konfiguration und Verwendung von ElasticSearch, welches auch explizit auf diesen Aspekt optimiert ist (22). 6 Zusammenfassung und Ausblick ElasticSearch ist zwar erst wenige Jahre alt, trotzdem schafft es diese Suche mit etablierten Lösungen erfolgreich zu konkurrieren. Die vielfältigen Anwendungsmöglichkeiten und eine einfache Installation werden wohl auch zukünftig zu einer großen Verbreitung von ElasticSearch beitragen. Das größte Anwendungsgebiet wird aber in der Analyse von Big Data liegen, wofür ElasticSearch durch seine verteilte Struktur augenscheinlich besser als die meisten anderen Suchmaschinen gewappnet ist. Während ElasticSearch somit Maßstäbe bei der effizienten Datenorganisation setzt, sieht die Realität in vielen Unternehmen noch anders aus. Enterprise Search stellt sich als sehr komplexes Thema heraus und wird im Umfang von Unternehmen manchmal unterschätzt. Verschiedenste Konzepte für den Aufbau einer solchen Suche und besondere Anforderungen an Rechte- und Datenverwaltung erfordern Investitionen, deren Nutzen schwierig zu ermitteln ist. 11 Single Interface for Music Score Searching and Analysis, siehe www.simssa.ca 19

Fast alle Global Player - große international agierende Konzerne - setzen schon länger auf Enterprise Search und beschäftigen dafür eigens Fachpersonal. In mittelständischen Unternehmen in Europa besteht in diesem Bereich dahingegen noch großes Potential (23). Enterprise Search bleibt also ein aktuelles und interessantes Themenfeld, auf dem sich selbst innovative Newcomer noch beweisen können. 20

7 Literaturverzeichnis 1. Heidenreich, Martin. Die Organisationen der Wissensgesellschaft. [Buchverf.] Christoph Hubig. Unterwegs zur Wissensgesellschaft: Grundlagen - Trends - Probleme. Berlin : Sigma, 2000, S. 107-118. 2. Bertram, Jutta. Informationen verzweifelt gesucht - Enterprise Search in österreichischen Großunternehmen. Berlin : s.n., 2011. 3. Buchta, Dieter, Eul, Marcus und Schulte-Croonenberg, Helmut. Strategisches IT-Management: Wert steigern, Leistung steuern, Kosten senken. Wiesbaden : Gabler, 2009. 4. Braschler, Martin et al. Enterprise-Search-Systeme im internen Wissensmanagement: Ergebnisse einer Studie zu Perspektiven der Unternehmen. Datenbank-Spektrum 9. 2009, S. 5-12. 5. Lange, Jürgen. Datenflut - Fluch oder Segen? s.l. : Frankfurter Allgemeine Buch, 2009. 6. Reichhold, Matthias, Kerschbaumer, Jörg und Fliedl, Günther. Optimizing Enterprise Search by Automatically Relating User Context to Textual Document Content. Proceedings of the 11th International Conference on Knowledge Management and Knowledge Technologies. s.l. : ACM, 2011, S. 22. 7. Lewandowski, Dirk. Whitepaper Enterprise Search: Was die Nutzer erwarten und warum Social Media so entscheidend ist. Dresden : T-Systems Multimedia Solutions GmbH, 2010. 8. Wauer, Matthias, Schuster, Daniel und Schill, Alexander. Advanced Resource Selection for Federated Enterprise Search. Business Information Systems Workshops. s.l. : Springer Berlin Heidelberg, 2011, S. 154-159. 9. Eckstein, Raiko. Interactive Search Processes in Complex Work Situations. Bamberg : s.n., 2011. S. 18-25. 10. Mukherjee, Rajat und Mao, Jianchang. Enterprise Search: Tough Stuff. QUEUE. 2004. 11. Huang, Yi, Ma, Xinqiang und Li, Danning. Research and Application of Enterprise Search Based on Database Security Services. Proceedings of the Second International Symposium on Networking and Network Security. 2010, S. 238-241. 12. Bahrs, Julian. Enterprise Search - Suchmaschinen für Inhalte im Unternehmen. Handbuch Internet Suchmaschinen. 2008. 13. AG, PENTADOC. ecm-lounge.com. [Online] 30. Januar 2013. [Zitat vom: 23. November 2013.] www.ecm-lounge.com/2013/01/30/wie-ecm-fahig-ist-microsoftsharepoint/. 14. Hertzum, Mortem und Pejtersen, Annelise Mark. The information-seeking practices of engineers: searching for documents as well as for people. Information Processing & Management. 2000, Bd. 36, 5, S. 761-778. 15. Apache Lucene. [Online] [Zitat vom: 25. November 2013.] lucene.apache.org. 16. Banon, Shay. www.kimchy.org. [Online] [Zitat vom: 25. November 2013.] web.archive.org/web/20130717162300/http://www.kimchy.org/the_future_of_compa ss/. 21

17. ElasticSearch. [Online] [Zitat vom: 25. November 2013.] www.elasticsearch.org. 18. Gruber, Andreas. Andreas Gruber, Informations und Wissensmanagement. [Online] 14. 03 2013. [Zitat vom: 25. 11 2013.] http://www.andreasgruber.at/opensource-enterprise-search-mit-apache-solr-und-elasticsearch/. 19. Ohloh. [Online] [Zitat vom: 25. November 2013.] www.ohloh.net/p/compare?project_0=elasticsearch&project_1=apache+solr. 20. Kuc, Rafal und Rogozinski, Marek. ElasticSearch Server. s.l. : Packt Publishing Ltd, 2013. 21. Thompson, Jessica, Hankinson, Andrew und Fujinaga, Ichiro. Searching the liber usualis: using couchdb and elasticsearch to query graphical music documents. s.l. : Ismir2011, 2011. 22. Tong, Zachary. Going Organic - Genomic sequence alignment in Elasticsearch. [Online] 13. August 2013. [Zitat vom: 25. November 2013.] http://de.slideshare.net/zacharytong/boston-meetupgoingorganic. 23. White, Martin und Nikolov, Stavri G. Enterprise Search in the European Union: A Techno - economic Analysis. Seville : Joint Research Centre, 2013. 22