Suchmaschine für Unternehmen mit Elastic und node.js | QMETHODS Developer Days 2016 von Alexander Aschauer | QMETHODS | Dezember 2016
 

Die QMETHODS DevDays

Einmal im Jahr nehmen wir uns zwei Tage für die Developer Days Zeit, um als QMETHODS Team gemeinsam etwas für uns auf Basis neuer Technologien zu entwickeln. Ziel ist es, Erfahrungen für den Einsatz sowie Umgang mit Technologien zu sammeln und natürlich gemeinsam Spaß zu haben :-)
 

Zielstellung: QSEARCH - Enterprise Search Engine

Vom 22.-23. Dezember 2016 fanden die QMETHODS DevDays 2016 statt. Unser Ziel war es, eine Unternehmenssuchmaschine zu entwickeln, mit welcher wir das Durchsuchen und Auffinden von Artefakten im Unternehmen ermöglichen. Die Suchmaschine tauften wir auf den Namen QSEARCH.
Im Fokus der durchsuchbaren Artefakte standen die Inhalte unserer Internetseite, die Datensätze unserer Anwendungen (QFINANCE, QCRM, QWIKI, QTICKET, QCLOUD) sowie unserer Dateiserver QFILE. Ihr merkt der Buchstabe spielt bei unserer internen Namensgebung eine große Rolle!
Als Fans der agilen Entwicklungsmethode haben wir die zwei Tage des DevDays auf Basis von SCRUM durchgeführt. Vier Iterationen mit einer Iterationsdauer von jeweils 3 Stunden war dann schon ganz schön sportlich. Das User Interface sowie ein paar grobe User Stories hatten wir in Vorbereitung der DevDays bereits erstellt.
 
QSEARCH Benutzeroberfläche
Abbildung: Entwurf der zukünftigen Benutzeroberfläche für QSEARCH
 

Die QSEARCH Systemarchitektur

Im ersten Sprint standen die Systemarchitektur und die eingesetzten Technologien im Vordergrund. ElasticSearch war auf Grund seiner Basisfunktionalität des Indexierens gesetzt. Unser Chefarchitekt Uwe wollte gern, dass der Browser nicht direkt auf die ElasticSearch-Datenbank zugreift, sondern dass über einen Applikationsserver eine Abstraktionsschicht eingefügt wird. Damit können wir die Abfragen gegen den AppServer von Seiten des Browsers noch optimieren, und die Browser Implementierung wird einfacher. Als AppServer standen Java und node.js zur Diskussion. Wir haben uns für node.js entschieden, um einfach auch hier mehr Erfahrung zu sammeln. Im Nachhinein hat uns der Einsatz von node.js sehr positiv überrascht, da wir uns damit eine sehr leichtgewichtige und mächtige Lösung herangezogen haben. Java hätte hier doch ein Vielfaches an "Boilerplate"-Aufwand bedeutet.
 
QSEARCH Systemarchitektur
Abbildung: QSEARCH Systemarchitektur
 
In der Browser-Implementierung haben wir auf Bootstrap und jQuery gesetzt, da wir hier schon einige Erfahrung durch unseren Internetauftritt gesammelt haben. Für die Importer wollten wir möglichst viele fertige ElasticSearch Frameworks nutzen, um den Aufwand hier für uns minimal zu halten.
 

Der QSEARCH Entstehungsprozess

Eigene Suchmaschine mit ElasticSearch + node.js | QMETHODS Developer Days 2016 Für die unterschiedlichen Artefakte wird pro Datenquelle (HTML, Datenbank, Dateisystem) ein spezifischer Importer entwickelt. Jeder Importer scannt die jeweilige Datenquelle und erzeugt pro auffindbarem Datensatz eine Datei im JSON Format. Die JSON Dateien werden anschließend in die ElasticSearch importiert und von dieser automatisch indexiert.
In der ersten SCRUM Iteration am Mittwochvormittag konnte der Importer für die Webseiten fertiggestellt werden. Hier konnten wir mit einem einfachen XSLT-Script entsprechende JSON-Dateien erstellen, da unsere Webseiteninhalte in XML hinterlegt sind.
Das zweite Team hat in der Zeit ElasticSearch und den node.js AppServer aufgesetzt und eine erste Funktion node.js implementiert, welche die Suchergebnisse ohne weitere Bearbeitung durchreicht.
Eigene Suchmaschine mit ElasticSearch + node.js | QMETHODS Developer Days 2016 Im zweiten Sprint ging es um die weitere Automation der Importer sowie um die Entwicklung der Browser-GUI und deren Verbindung zum Application Server. Am Ende des Sprints konnten über die Browser-GUI bereits die ersten Suchen erfolgreich ausführen. Ebenfalls umgesetzt wurden die Funktionen für Pagination und Typ der Suchergebnisse (Website, Datenbank etc.), um diese dann später entsprechend gesondert im Browser anzeigen zu können.
Bei der Implementierung des Datenbank-Importers wollten wir das Framework ElasticSearch-JDBC einsetzen. Dieses ist jedoch stark von der eingesetzten ElasticSearch Version abhängig und ist aus unserer Sicht nur unter begrenzten Rahmenbedingungen einsetzbar. Letztendlich haben wir uns für eine händische Implementierung in node.js entschieden. Wow - und da haben wir mal wieder gestaunt wie schnell und einfach wir mit node.js vorangekommen sind. So langsam gewinnt JavaScript unsere Herzen :-)
Die letzte SCRUM Iteration beinhaltete die Finalisierung des FrontEnds sowie das Hardening der einzelnen Komponenten. Im FrontEnd wurde die Darstellung und Auswertung der Ergebnisse implementiert. Im BackEnd wurde die Automation des Imports, vor allem im Bereich Datenbanken, vorangetrieben.
 
QSEARCH
Abbildung: QSEARCH in Action
 

QSEARCH und DevDays Retrospektive

Wir sind erst einmal erstaunt, dass wir gemeinsam in zwei Tagen wirklich einen vorzeigbaren Prototyp einer Enterprise Search Engine realisieren konnten. Natürlich hakt es noch an einigen Stellen, die Workarounds müssen noch einmal sauber umgesetzt werden und die Implementierung des Importers für das Dateisystem war wohl ein wenig zu ambitioniert für die zwei Tage. Aber wir haben viel über neue Technologien gelernt und wie diese die Umsetzung von komplexen Benutzeranforderungen in effizienter Form ermöglichen.
Was gab es sonst noch für Feedback aus dem Team:

SCRUM - Das Projektziel im Blick behalten

Das agile Vorgehen hat uns trotz rudimentärer Anforderungen und weiterer Wünsche aus den Iterationen geholfen, unsere Zielstellung nicht aus dem Auge zu verlieren (Fokus auf Ergebnisse in definierter Zeit und Qualität; keine funktionsgetriebene Entwicklung).

node.js - Der Booster für die Entwicklung

node.js hat für die Entwicklung des AppServers und der Importer seine Leichtigkeit und Mächtigkeit. Wir sind begeistert und werden in Zukunft mehr auf node.js setzen!

Architektur - Wie Baut man ein Haus?

Die Suchlogik in den AppServer zu verlegen schafft eine bessere Abstraktion. So kann sich die Browser-Implementierung rein auf Anfrage und Anzeige der Suchergebnisse konzentrieren und bekommt vom AppServer fertige Funktionen für Offset und Lazy Loading bereitgestellt. Des Weiteren können die Möglichkeiten der Suchanfragen leichter im AppServer umgesetzt werden.

Datenmodell - Frühzeitige Struktur spart Zeit und Aufwand

Die JSON-Datenstruktur in ElasticSearch haben wir frühzeitig im Projekt definiert. Somit kann jetzt der Importer in Abhängigkeit von der Datenquelle definieren, was im Browser angezeigt wird. Die Browser-Implementierung muss auch für neue Datenquellen/Importer nicht angepasst werden.
 
Und wie geht es weiter? Wir werden QSEARCH im ersten Quartal 2017 QMETHODS intern in Betrieb nehmen und die Alterstauglichkeit speziell der Möglichkeiten der Suchanfragen erhöhen. Danach steht einem Einsatz von QSEARCH in unseren Kundenprojekten nichts mehr im Weg. Die ersten Anfragen liegen schon vor :-)



Ihr Kommentar zum Blog-Beitrag

Nennen Sie uns bitte Ihren Namen und E-Mail-Adresse zur Verifikation. Die E-Mail Adresse wird nicht veröffentlicht!