ElasticSearch bzw. OpenSearch : Der Schlüssel zur effizienten Produktsuche im Customer Care

Seit 2011 arbeiten wir für ein renommiertes deutsches Pharmaunternehmen und entwickeln bzw. erweitern unter anderem ein maßgeschneidertes Produkt-Informations-System (PIM). Dieses System enthält eine Vielzahl an Daten zu den Produkten unseres Kunden, darunter Preisangaben, Inhaltsstoffe, Darreichungsformen, Rote-Hand-Briefe, Fach- und Gebrauchsinformationen sowie spezifische medizinische Listen wie eine Teilbarkeitsliste.

Für den Kundenservice ist ein zügiger Zugriff auf diese Informationen von entscheidender Bedeutung. In diesem Blogbeitrag möchte ich die Vorteile von Suchmaschinen wie ElasticSearch oder OpenSearch (ein Fork von ElasticSearch auf GitHub) hervorheben. Im Vergleich zu Suchmethoden, die ausschließlich auf SQL-Abfragen mit dem LIKE-Operator basieren, bieten sie einen klaren Mehrwert beim schnellen Finden von Informationen.

Die in diesem Blogbeitrag vorgestellte Umsetzung ist äußerst flexibel und ermöglicht die Integration in bestehende Unternehmenssoftware wie Customer-Relationship-Management (CRM), PIM, Manufacturing Execution System (MES) usw. Dabei ist lediglich die Anpassung des im übernächsten Abschnitt beschriebenen Search-Indexer an das Datenbankschema des zu integrierenden Systems erforderlich. Dies erfordert eine gründliche Analyse des Datenbankschemas der betreffenden Software (CRM, PIM, MES usw.). In diesem Projekt gestaltete sich dieser Schritt relativ unkompliziert, da wir das PIM-System als maßgeschneiderte Softwarelösung speziell für unseren Kunden entwickelt hatten und somit mit dem Datenbankschema bestens vertraut waren.

SQLs LIKE versus Volltextsuche

Der LIKE-Operator in SQL ist nützlich für einfache Textsuchen, zeigt jedoch im Vergleich zu Volltextsuchfunktionen klare Grenzen:

• Begrenzte Mustererkennung: LIKE erlaubt nur einfache Muster mit Platzhaltern wie % und _. Komplexere Muster, etwa mit regulären Ausdrücken, sind nicht möglich.
• Schwierigkeiten bei spaltenübergreifenden Suchen: Mit LIKE sind Suchen über mehrere Spalten umständlich und ineffizient, während Elasticsearch dies eleganter handhabt.
• Performance-Probleme bei großen Datenmengen: Bei umfangreichen Daten kann LIKE, besonders bei Mustern, die mit % beginnen, langsam sein, da keine Indizes genutzt werden können. Elasticsearch bietet hier effizientere Suchalgorithmen.

Zusammenfassend ermöglicht der LIKE-Operator Grundfunktionalitäten für Textsuche, wohingegen Elasticsearch eine weitreichendere und leistungsstärkere Lösung für komplexere Suchaufgaben darstellt.

Search-Indexer mit Kotlin, jOOQ und Spring Boot

In diesem Abschnitt möchte ich näher auf die technische Realisierung unseres Search-Indexers eingehen. Dieser wurde als Spring Boot-Anwendung entwickelt, wobei wir uns für Kotlin in Kombination mit jOOQ entschieden haben.

Warum wir uns für Kotlin, jOOQ und OpenSearch entschieden haben

Unsere Wahl fiel auf Kotlin, weil es eine moderne Syntax bietet, die weniger umständlichen Code (Boilerplate) als Java benötigt. Zudem erhöht die in Kotlin integrierte Null-Sicherheit die Zuverlässigkeit unserer Anwendung, indem sie häufig auftretende Fehlerquellen vermeidet. Insgesamt bringt Kotlin die Robustheit von Java mit der Flexibilität von Groovy zusammen, was es für unser Projekt ideal macht.

In Bezug auf die Datenbankinteraktion haben wir uns gegen einen ORM-Mapper wie Hibernate entschieden. Trotz seiner Eignung für CRUD-Operationen neigt Hibernate bei komplexen Datenbankabfragen oft zu Performance-Einbußen. Da unser Search Indexer als separate Anwendung realisiert wurde, hätten wir zudem alle Domain-Klassen aus Groovy nach Kotlin übertragen müssen. Aufgrund unserer Erfahrung und spezifischer Projektanforderungen fiel unsere Wahl daher auf jOOQ. Als Java-Framework ermöglicht jOOQ die typsichere Formulierung von SQL-Abfragen. Dies führt dazu, dass viele potenzielle Fehler bereits während der Kompilierungsphase erkannt werden. Die Kombination dieser Typsicherheit mit der Fähigkeit, komplexe SQL-Operationen zu unterstützen, und die Kompatibilität mit verschiedenen SQL-Datenbanken, machen jOOQ zu einer effizienten und zuverlässigen Wahl für unsere Datenbankinteraktionen.

Ein weiterer entscheidender Vorteil des Einsatzes von jOOQ ist, dass erst durch dieses Framework die Abfrage von Datenbankschemata verschiedener Applikationen wie CRM, PIM und MES ermöglicht wird. Dies ist eine grundlegende Voraussetzung für die Indexierung in einer Volltext-Suchmaschine.

Abschließend möchten wir noch erläutern, warum wir uns für OpenSearch anstelle von Elasticsearch entschieden haben. OpenSearch ist ein Fork von Elasticsearch 7.10 auf GitHub und bietet alle Funktionalitäten, die wir benötigten. Ein entscheidender Faktor für unsere Wahl war die Lizenzierung: OpenSearch steht unter der Apache 2.0-Lizenz, die für unser Projekt deutliche Vorteile bot und letztlich den Ausschlag gab.

Wie funktioniert der Search-Indexer

Mit jOOQ haben wir Java-Klassen basierend auf unserem bestehenden Datenbankschema generiert. Diese nutzen wir in Kotlin, um Datenbankabfragen zu erstellen – auch komplexe Abfragen mit mehreren JOINs sind möglich. Besonders nützlich fanden wir in Kotlin die Funktionalität der Extension Functions. Diese erlauben es uns, bestehende Klassen um zusätzliche Methoden zu erweitern, ohne auf Vererbung zurückgreifen zu müssen. Das führt aus unserer Sicht zu einem klareren und übersichtlicheren Code.

In unserem Projekt haben wir Extension Functions genutzt, um den von jOOQ generierten Klassen, die unsere Datenbank-Entitäten repräsentieren, zusätzliche Funktionalitäten hinzuzufügen. So konnten wir gezielt nur die benötigten Attribute (Datenbankspalten) extrahieren. Das Ergebnis war ein umfassendes JSON-Dokument, das alle relevanten Attribute enthielt. JOINs auf andere Datenbanktabellen, beispielsweise zwischen einem Medikament und seinen verschiedenen Packungsgrößen mit eigenen Pharmazentralnummern (PZNs), wurden als JSON-Arrays innerhalb dieses Gesamtdokuments abgebildet.

Dieses „große“ JSON-Dokument (siehe auch Grafik unten) haben wir zur Indexierung an OpenSearch gesendet. OpenSearch kann das empfangene JSON-Dokument effizient verarbeiten, da es alle benötigten Informationen in einer einzigen Anfrage erhält. Dies erleichtert die Indexierung und die Suche nach Produktdaten erheblich.

Fazit: Technologischer Fortschritt im Kundenservice durch effektive Volltextsuche

Die Implementierung einer Volltextsuche mittels OpenSearch hat im Kundenservice unseres Pharmakunden zu einer signifikanten Verbesserung geführt. Im Vergleich zum herkömmlichen SQL LIKE-Operator ermöglicht die Volltextsuche eine wesentlich schnellere und präzisere Ermittlung von Produktinformationen.

Durch die Verwendung von Kotlin und jOOQ innerhalb einer Spring Boot-Umgebung konnten wir eine robuste und effiziente Plattform etablieren. Zudem kann der Einsatz von jOOQ, wie bereits erwähnt, die Integration bestehender Softwaresysteme wie CRM, PIM und MES erleichtern, vorausgesetzt, dass deren Datenbankschemata verständlich und zugänglich sind.