{"id":201,"date":"2021-01-22T13:59:28","date_gmt":"2021-01-22T12:59:28","guid":{"rendered":"https:\/\/informatik.htwk-leipzig.de\/seminar\/?p=201"},"modified":"2021-02-01T18:12:48","modified_gmt":"2021-02-01T17:12:48","slug":"enterprise-search-engine","status":"publish","type":"post","link":"https:\/\/informatik.htwk-leipzig.de\/seminar\/lehrveranstaltungen\/betriebliche-informationssysteme\/2021\/enterprise-search-engine\/","title":{"rendered":"Enterprise Search Engine"},"content":{"rendered":"

Motivation<\/h1>\n

\u201eZeitfresser Dokumentensuche: Verbesserungsbedarf in deutschen B\u00fcros\u201c so lautet am 14.07.2017 die Schlagzeile eines Artikels der Fachzeitschrift \u201eZDNET\u201c. Schon 2017 und wahrscheinlich auch einige Jahre zuvor stieg aufgrund der immer gr\u00f6\u00dfer werdenden Flut an Dokumenten, wie beispielsweise Formulare oder Antr\u00e4ge, der Zeitaufwand, den Mitarbeiter haben, um aus all diesen Textst\u00fccken das Richtige herauszusuchen. Das Neuanlegen eines Dokuments ist oftmals schneller als die Suche nach dem bereits angelegten. Der Autor des Artikels beruft sich dabei auf eine Studie von KYOCERA, die in Kooperation mit dem Portal Statista erstellt wurde. Dabei wurde festgestellt, dass mehr als die H\u00e4lfte der Befragten aus dem Bereich Administration\/Verwaltung (67%) und Finanzen\/Buchhaltung (71%) mehr als eine Stunde (durchschnittlich 119 min) am Tag mit der Suche und Ablage von Dokumenten und Dateien verbringen (Vgl. Abbildung 1).<\/p>\n

\"\"
Quelle: KYOCERA Document Solutions Deutschland GmbH und Statista Online-Befragung (2018): Studie_Dokumente_gesucht_gefunden, 2018.<\/figcaption><\/figure>\n

Aufgrund des hohen Zeitaufwandes k\u00f6nnen sich die Mitarbeiter weniger auf ihre eigentlichen Aufgaben fokussieren. Folgen daraus sind ineffiziente Gesch\u00e4ftsprozesse und resultierende Kosten f\u00fcr den Ausgleich dieser Ineffizienz. Neben dem hohen Zeitaufwand k\u00f6nnen Unternehmen zus\u00e4tlich hohe Kosten durch\u00a0 erh\u00f6hten Bedarf an IT-Ressourcen entstehen.<\/p>\n

Eine M\u00f6glichkeit dem genannten Problem entgegenzuwirken ist die Einf\u00fchrung einer Enterprise Search Engine. Eine solche unternehmensweite Suchmaschine verk\u00fcrzt die Datenzugriffszeiten deutlich und stellt zus\u00e4tzlich f\u00fcr die Nutzer relevante Informationen bereit.<\/p>\n

\u00dcberblick<\/h1>\n

Enterprise Search oder auf Deutsch \u2013 unternehmensweite Suche, ist ein Begriff aus dem Forschungsumfeld des Information Retrieval und somit ein Teilgebiet dessen. Sie durchsucht Datenbanken, Unternehmenswebseiten, Intranet, Mailserver und Dateisysteme nach Dokumenten, weiteren Textinhalten und wenn gew\u00fcnscht auch nach Metadaten von Grafiken und Fotos. Dabei ist es nicht notwendig den prozessualen Ablauf f\u00fcr die Mitarbeiter zu ver\u00e4ndern. Das bedeutet, dass Mitarbeiter ihre Dokumente wie gewohnt abspeichern k\u00f6nnen und sich nicht auf neue Ordnerstrukturen oder Speicherorte einstellen m\u00fcssen. Diese spezielle Art von Suchmaschinen unterscheidet sich in ihrem Aufbau nicht von herk\u00f6mmlichen Internetsuchmaschinen. Die wesentlichen 3 Bestandteile einer solchen Websuchmaschine sind Crawler oder Crawling Engine, Indexer und Query Engine, welche f\u00fcr die Beschaffung, Aufbereitung und Bereitstellung der Ergebnisse zust\u00e4ndig sind.<\/p>\n

\"\"
Abbildung 2 Konzeptionelle Architektur einer Enterprise Suchmaschine
Quelle: Eigene Darstellung angelehnt an Lewandowski, Dirk(hrsg) (2009), S. 340<\/figcaption><\/figure>\n

Abbildung 2 zeigt, wie Enterprise Suchmaschinen aufgebaut und die internen Abl\u00e4ufe bei einer Suchanfrage geregelt sind. Nach Eingabe der Suchanfrage durch den Anwender wird diese verarbeitet und mit Metadaten, unter anderem mit Benutzerdaten, angereichert. Anschlie\u00dfend werden die ben\u00f6tigten Informationen aus dem Index gezogen. Dieser besteht aus aufbereiteten Daten, welche bei der Inhaltsakquise aus verschiedenen Datenquellen gezogen wurden. Das Speisen des Index mit Daten ist ein von der Suche durch den Anwender abgekoppelter zyklischer Prozess. Die gesammelten Datens\u00e4tze werden dem Suchenden in Form einer Liste pr\u00e4sentiert, dieser kann dann die Ergebnisse bewerten und die Suche gegebenenfalls anpassen. Die Bewertung des Benutzers l\u00f6st eine Anpassung des Benutzerprofils aus, welche dann in der Datenlogik unter Benutzerdaten abgespeichert wird.<\/p>\n

Elastic Search<\/h1>\n

Im Jahr 2010 ver\u00f6ffentlichte Shay Banon die erste Version seiner Open Source Enterprise Suchmaschine Elasticsearch. Realisiert ist die Suchmaschine in Java als Webservice und bietet somit eine plattformunabh\u00e4ngige Anwendung basierend auf der Softwarebibliothek Lucene von Apache. Die Kommunikation mit Elasticsearch funktioniert entweder direkt in der Programmiersprache Java \u00fcber zwei integrierte Clients (Node-Client und Transport Client) oder durch verschiedene andere Programmiersprachen \u00fcber eine RESTful API mithilfe von JSON (JavaScript Object Notation) und http. Die Systeminfrastruktur kann sowohl als Stand-Alone System oder verteilt auf vielen verschiedenen Servern realisiert werden.<\/p>\n

Elasticsearch ist dokumentenorientiert, das bedeutet, dass bei dieser Anwendung, anders als \u00fcblich, gesamte Dokumente und Objekte abgespeichert und indexiert werden. Dies erm\u00f6glicht das Suchen gesamter Dokumente und erspart das Aufschl\u00fcsseln der Metadaten in verschiedene Spalten einer Datenbanktabelle. Zudem m\u00fcssen die Dokumente nicht jedes Mal aus diesen Informationen der Datenbank rekonstruiert werden. Zur Serialisierung der Dokumente verwendet die Suchmaschine JSON, welches trotz komplexer Objekte die Konvertierung und die anschlie\u00dfende Indizierung einfacher macht als ein \u00e4quivalenter Prozess mit Tabellenstruktur. Zus\u00e4tzlich existieren JSON Bibliotheken f\u00fcr nahezu alle Programmiersprachen, welche die Umwandlung, egal welcher Datenstruktur, in dieses Format erm\u00f6glichen. Zur Speicherung der Dokumente nutzt Elasticsearch einen Index in Form invertierter Listen.<\/p>\n

Beispiel<\/h1>\n

 <\/p>\n

 <\/p>\n

\"Abbildung
Abbildung 3 Elastic Stack Quelle: Eigene Darstellung<\/figcaption><\/figure>\n

In unserem Beispiel haben wir uns f\u00fcr die Realisierung mit dem Elastic Stack bestehend aus Elasticsearch, der Grafischen Oberfl\u00e4che Kibana und dem Datenanbindungstool Logstash entschieden. Alle Komponenten, die in Abbildung 3 zu sehen sind laufen dabei auf einer separaten Dockerinstanz arbeiten jedoch zusammen. Logstash dient in diesem Fall dazu die Daten aus unserer Beispieldatenbank (MySQL) zu akquirieren und anzureichern, um sie anschlie\u00dfend mit Elasticsearch zu synchronisieren. Die von Logstash gesammelten Daten werden dann von Elasticsearch Indexiert und durchsuchbar gemacht. Die grafische Oberfl\u00e4che Kibana dient der Administration von Logstash und Elasticsearch. Hier werden Metriken und Monitoring-Daten visualisiert, Log-Daten k\u00f6nnen analysiert werden und Anfragen k\u00f6nnen f\u00fcr in den Devtools getestet werden Elasticsearch ist dabei \u00fcber eine REST-Api erreichbar.<\/p>\n

\"docker-compose
Quelle: eigene Darstellung<\/figcaption><\/figure>\n

In unserem Beispiel haben wir Elasticsearch \u00fcber Loigstash mit einer Buchdatenbank verbunden.<\/p>\n

Eine Anfrage an Elastic k\u00f6nnte dann z.B. so aussehen:<\/strong><\/p>\n


\nGET books\/_search?size=3 \/\/max. 3 Ergebnisse anzeigen
\n{
\n\"query\": {
\n\"multi_match\": {
\n\"query\": \"Adventures Mark Twain\", \/\/Suchbegriffe
\n\"fields\": [\"title\", \"authors\"] \/\/zu durchsuchende Felder
\n}
\n}
\n}
\n<\/code>
\nDas Ergebnis k\u00f6nnte dann folgenderma\u00dfen aussehen:<\/strong><\/p>\n


\n{<\/p>\n

\"took\" : 1,<\/p>\n

\"timed_out\" : false,<\/p>\n

\"_shards\" : {<\/p>\n

\"total\" : 1,<\/p>\n

\"successful\" : 1,<\/p>\n

\"skipped\" : 0,<\/p>\n

\"failed\" : 0<\/p>\n

},<\/p>\n

\"hits\" : {<\/p>\n

\"total\" : {<\/p>\n

\"value\" : 13, \/\/insgesamt 13 Suchergebnisse gefunden<\/p>\n

\"relation\" : \"eq\"<\/p>\n

},<\/p>\n

\"max_score\" : 8.961069, \/\/Score des besten Ergebnis<\/p>\n

\"hits\" : [<\/p>\n

{ \/\/Suchergebnis mit dem h\u00f6chsten Score<\/p>\n

\"_index\" : \"books\",<\/p>\n

\"_type\" : \"_doc\",<\/p>\n

\"_id\" : \"9781402726002\",<\/p>\n

\"_score\" : 8.961069,<\/p>\n

\"_source\" : {<\/p>\n

\"title\" : \"The Adventures of Huckleberry Finn\",<\/p>\n

\"publication_date\" : \"2006-10-28T00:00:00.000Z\",<\/p>\n

\"isbn\" : \"9781402726002\",<\/p>\n

\"authors\" : \"Mark Twain\/Scott McKowen\/Arthur Pober\"<\/p>\n

}<\/p>\n

},<\/p>\n

{<\/p>\n

\"_index\" : \"books\",<\/p>\n

\"_type\" : \"_doc\",<\/p>\n

\"_id\" : \"9781426423703\",<\/p>\n

\"_score\" : 6.2986403,<\/p>\n

\"_source\" : {<\/p>\n

\"title\" : \"The Adventures of Sally\",<\/p>\n

\"publication_date\" : \"2008-05-29T00:00:00.000Z\",<\/p>\n

\"isbn\" : \"9781426423703\",<\/p>\n

\"authors\" : \"P.G. Wodehouse\"<\/p>\n

}<\/p>\n

},<\/p>\n

{<\/p>\n

\"_index\" : \"books\",<\/p>\n

\"_type\" : \"_doc\",<\/p>\n

\"_id\" : \"9780964366565\",<\/p>\n

\"_score\" : 5.6587152,<\/p>\n

\"_source\" : {<\/p>\n

\"title\" : \"Lo \u00fanico que no podr\u00e1s hacer en el cielo\",<\/p>\n

\"publication_date\" : \"2007-03-01T00:00:00.000Z\",<\/p>\n

\"isbn\" : \"9780964366565\",<\/p>\n

\"authors\" : \"Mark Cahill\"<\/p>\n

}<\/p>\n

}<\/p>\n

]<\/p>\n

}<\/p>\n

}
\n<\/code>
\n\u00dcber ein Score wird bewertet wie gut Suchanfrage und Ergebnis \u00fcbereinstimmen. Der Einfluss bestimmter Worte auf den Score kann auch angepasst werden, so werden in der Regel F\u00fcllw\u00f6rter wie \u201eund\u201c, \u201eoder\u201c, sowie Artikel, geringer gewertet. \u00dcber die API l\u00e4sst sich dann auch ein Frontend f\u00fcr die Suche implementieren, damit diese z.B. auf Webseiten eingebunden werden kann.<\/p>\n

Vortragsfolien<\/h1>\n

BIS<\/a><\/p>\n

Quellen<\/h1>\n