Kurz gefasst:

  • 85 Prozent aller digitalen Inhalte in Unternehmen liegen unstrukturiert vor und lassen sich nicht in Datenbanken speichern. Tendenz: steigend. Suchlösungen helfen, diese Inhalte zu erschließen und wieder zur Verfügung zu stellen.
  • Open-Source-Suchprojekte lösen proprietäre Enterprise-Suchlösungen zunehmend ab. Ihre Vielfältigkeit ist ihr Vorteil: Produktzyklen werden durch eine engagierte Entwickler-Community schneller durchlaufen, durch offenen Quellcode gibt es für fast jeden Sonderfall eine Lösung.
  • Die zwei leistungsfähigsten Open-Source-Suchen sind Solr/Lucene und Elasticsearch. Um im Enterprise-Umfeld die passende Lösung auszuwählen, muss man auf die Details achten

Suche ist heutzutage elementarer Bestandteil einer modernen Informationsarchitektur von Unternehmen. Das digitale Datenwachstum verdoppelt sich nahezu jährlich. Der Großteil der produzierten Inhalte liegt dabei nur in unstrukturierter Form vor. Gleichzeitig wird schnelles und komfortables Finden passender Informationen zunehmend unternehmenskritischer Bestandteil alltäglicher Arbeit. Die Open-Source-Community hat für diese Anwendungsfälle in den vergangenen Jahren zwei leistungsfähige Lösungen hervorgebracht: Solr/Lucene und Elasticsearch. Beide Projekte liefern sich momentan ein Kopf-an-Kopf-Rennen um die Vorherrschaft im Open-Source-Suchmarkt. Während Solr/Lucene bereits seit vielen Jahren Maßstäbe setzt, erfährt Elasticsearch vor allem seit dem vergangenen Jahr einen großen Schub im Big-Data-Suchumfeld. Im Folgenden werden Einsatzzweck sowie generelle Unterschiede beider Lösungen beleuchtet, um Hilfestellung bei der Auswahl der passenden Open-Source-Suchlösung zu bieten.

 

Ohne eine effiziente und gute Volltextsuchlösung funktionieren Unternehmen im digitalen Zeitalter nicht mehr. Laut Gartner [1] liegen unglaubliche 85 Prozent der digitalen Inhalte in Unternehmen unstrukturiert vor und lassen sich nicht in Datenbanken speichern. Und die Datenmenge steigt weiterhin rasant an. Suchlösungen helfen dabei, diese Inhalte zu erschließen und wieder zur Verfügung zu stellen. In den vergangenen Jahren lösen mehr und mehr Open-Source-Suchlösungen die alten, proprietären Enterprise-Search-Lösungen ab. Vor allem Solr/Lucene, zunehmend jedoch auch Elasticsearch führen die Riege dieser neuen modernen Lösungen an.

 

Entwicklung und gemeinsamer Ursprung beider Systeme

Der Open-Source-Suchbereich hat vor allem durch das von Doug Cutting im Jahre 2001 vorgestellte Lucene Such-Framework Aufschwung erlebt. Hierbei handelt es sich um eine Bibliothek zur Entwicklung von Volltextsuchen, die heutzutage die Basis vieler Open-Source-Suchlösungen bildet. Zuvor musste man viele Jahre lang entweder teure, proprietäre Lösungen für eine Volltextsuche erwerben oder relationale Datenbanken wurden um eine einfache, unzureichende Volltextsuche erweitert. Diese Angebotssituation führte zu einer wachsenden Verbreitung von Lucene, so dass es im Jahr 2005 Teil des Open-Source-Projekts Apache wurde.

 

Solr entstand im Jahr 2006 aus dem Bedarf heraus, einen Open-Source-basierten Enterprise-Search-Server einfach auf Basis von Lucene zu betreiben. Vorher entwickelte jedes Projekt seine Suchlösung individuell auf Basis von Lucene. Im Jahr 2010 wurden Solr und Lucene dann unter einem Projekt zusammengefasst, um die Entwicklung zu beschleunigen und voneinander auch inhaltlich stärker profitieren zu können.

 

Ebenfalls im Jahr 2010 stellte Shay Banon erstmals Elasticsearch vor. Es basiert wie Solr auf dem Lucene-Framework und ist ebenso ein Enterprise-Search-Server. Der Fokus bei der Architektur und der Entwicklung lag jedoch sehr stark auf einer verteilten, skalierbaren Volltextsuchmaschine. Es verfolgt damit einen grundlegend anderen Architekturansatz als Solr/Lucene. Dieses wurde ursprünglich nicht für verteilte Suchlösungen konzipiert. Durch den steigenden Bedarf von Big-Data-Suchlösungen erfuhr Elasticsearch in den vergangenen Monaten einen enormen Schub in der Verbreitung.

 

Solr/Lucene ist jedoch immer noch weiter verbreitet und mittlerweile auch in vielen Software-Lösungen als Enterprise-Search-Server integriert. Eine große Zahl proprietärer Lösungen wurde damit ersetzt. Wichtige Faktoren für den großen Erfolg Lucene-basierter Suchlösungen sind Kosten, Stabilität, Erweiterbarkeit und Geschwindigkeit.

 

Beide Lösungen sind unter einer sehr liberalen Open-Source-Lizenz nutz- und erweiterbar (Apache 2.0 Lizenz). Bei beiden Projekten ist der Quellcode komplett offen und es werden keine Lizenzkosten für den kommerziellen Gebrauch fällig.

 

Funktionsumfang: Wie Google?

Beide Lösungen haben in den vergangenen zwei Jahren sowohl in ihrer Verbreitung als auch in ihrem Feature-Angebot große Fortschritte gemacht. Durch die von Google geprägte Erwartungshaltung von Nutzern an moderne Suchlösungen bringen beide die relevanten Suchserver-Features mit. Sie bieten eine komplexe Querysprache für viele verschiedene Einsatzzwecke und umfangreiche individualisierbare Relevanzfunktionen. Sie ermöglichen eine Echtzeit-Indizierung von Inhalten, sind durch eine Vielzahl von Plugins erweiterbar und bieten Auto-Suggest-Funktionalität und Tippfehlerkorrektur. Selbst geobasierte Suchvorgänge auf Basis von Geokoordinaten werden unterstützt, ebenso die auf vielen Suchseiten für die After-Search-Navigation relevanten Ergebnis-Facetten.

 

Die Sprachanalyse-Fähigkeiten wurden sukzessive weiter ausgebaut, so dass eine Vielzahl von Sprachen bei der Indizierung von Daten und bei der Suche unterstützt wird. Beide Lösungen verfügen über entsprechende Schnittstellen und lassen sich so gut von einem Such-Frontend oder anderen Applikationen integrieren.

 

Weder Solr/Lucene noch Elasticsearch besitzen ein eingebautes Rechtemanagement. Dies war in beiden Projekten eine bewusste Designentscheidung. Aus diesem Grund müssen Nutzungsrechte und Zugriffe durch äußere Applikationen umgesetzt werden.

 

Relevante Unterschiede im Basis-Funktionsumfang gibt es demzufolge nicht. Sowohl mit Solr/Lucene als auch mit Elasticsearch lassen sich hervorragende Suchlösungen nach Googles Vorbild bauen. Bei der Auswahl entscheidet hier meist die Vorliebe der Entwickler oder der Consultingfirma.

 

Genau hingeschaut: die Unterschiede

Solr/Lucene besticht durch eine gute Erweiterbarkeit, die in vielen Projekten mit zunehmender Laufzeit eine Rolle spielt. Entwickler können mit wenig Aufwand den Such- und Indizierungsworkflow durch eigene Software oder sogar kommerzielle Drittsoftware, wie z.B. Semantikmodule oder Sharepoint-Integration, anpassen. Elasticsearch bietet hier vor allem vorgefertigte Plugins und ist weniger gut erweiterbar.

 

Solr/Lucene verfügt über eine außerordentlich gute Dokumentation. Elasticsearch mangelt es noch an der Dokumentationstiefe und an konkreten Anwendungsbeispielen. Hier hat Solr/Lucene sicher das stabilere, erfahrenere Entwickler-Fundament. Die aktive Entwicklerbasis beider Projekte ist mittlerweile ähnlich groß, so dass man Support und Hilfe bei beiden Lösungen für gewöhnlich sehr schnell bekommt, so lange das eigene Problem detailliert genug beschrieben ist.

 

Ein zentraler Unterschied ist die Schemalosigkeit von Elasticsearch. Dies bedeutet, dass zu Projektbeginn keine Datenstruktur angegeben wird, sondern Elasticsearch die Auswahl von Datentypen automatisch vollführt. Dieser dokumentenzentrierte Ansatz kommt aus dem Bereich der Big-Data-Anwendungsfälle, bei denen man es mit vielen unterschiedlichen Daten zu tun hat. Unterschiedliche Dokumente lassen sich so bequem in einem Index speichern und abfragen. Schemalosigkeit ist ein relevanter Trend moderner Datenbanken, allerdings in vielerlei Hinsicht auch riskant. Eine qualitativ hochwertige Volltextsuche bedarf einer konkreten Datenspezifikation, um Ergebnisrelevanz, Indizierung und Analyse optimal umzusetzen.

 

Elasticsearch kann Suchanfragen speichern und – sobald neue Dokumente indiziert sind – feststellen, ob diese von der Suchanfrage gefunden werden. Hiermit lassen sich Echtzeit-Alerts für Themen und Treffer umsetzen. Solr/Lucene bietet eine solche Funktion nicht.

 

Der Anwendungsfall Big Data

Skalierbarkeit von Suchtechnologie ist ein zunehmend relevanter Faktor. Durch die verstärkte Nutzung von Suchlösungen für Big-Data-Speicherung, Business Intelligence und in großen suchbasierten Anwendungen (wie z.B. LinkedIn) werden im Projektverlauf oftmals weitere Datenquellen angebunden. Die vertikale Skalierbarkeit wird schnell unternehmenskritisch. Das zu erwartende Datenvolumen muss man bei der Auswahl der Lösung berücksichtigen. Elasticsearch wurde von Grund auf für diesen Anwendungsfall konzipiert und bringt dadurch Vorteile mit.

 

Beispielsweise funktioniert bei Elasticsearch die Verteilung und Skalierung auf viele Hardwaresysteme weitgehend problemlos. Bei Ausfällen von Maschinen eines Clusters werden die nicht mehr erreichbaren Daten auf Basis von replizierten Versionen der Daten auf noch laufenden Maschinen automatisch auf andere Maschinen des Clusters transferiert. Sobald die Maschinen wieder verfügbar sind, erfolgen die Reintegration in den Cluster und die Aktualisierung vollautomatisch.

 

Solr/Lucene wurde in Version 4.0 durch das SolrCloud Plugin erweitert. SolrCloud wurde im Gegensatz zur automatischen Verteilung in Elasticsearch erst im Nachgang entwickelt und lässt wichtige Features wie automatisches Rebalancing im Fall von Systemausfällen vermissen. Man hat es nach sehr langer Entwicklungszeit vergleichsweise spät veröffentlicht. Letztlich stellt es nur ein Add-on zu Solr/Lucene dar und ist nicht Teil der ursprünglichen Architekturbasis.

 

Festhalten muss man allerdings, dass der Großteil der Enterprise-Search-Projekte meist nicht Big Data ist und somit die Datenskalierung nicht notwendigerweise ein Entscheidungskriterium darstellt. Die meisten Anwendungsfälle erfordern Ausfallsicherheit und hohe Suchgeschwindigkeit. Dies lässt sich mit beiden Lösungen sehr gut umsetzen.

 

Stabilität und Kosten in der Praxis

Beide Lösungen gelten als außerordentlich stabil und ressourcenschonend. Vor allem die klassische Master-Slave-Architektur ist sehr sicher und stabil und lässt sich kostengünstig auf Standard-Serverhardware betreiben. Beiden Lösungen merkt man an, dass sie auf einem sehr ausgereiften Fundament (Lucene) aufsetzen. Sie glänzen im Alltag durch Stabilität. Betrachtet man jedoch das Big-Data-Szenario, kann es vergleichsweise schnell problematisch werden.

 

Ein hochdynamisches System mit vielen unterschiedlichen Daten erfordert im Betrieb viel Aufmerksamkeit und ist kein Selbstläufer. Durch Plugins lassen sich beide Lösung optimal überwachen und in ein bestehendes Monitoring einbinden. Sowohl Solr/Lucene als auch Elasticsearch bringen von Haus aus Administrationsoberflächen für den Betrieb und die Konfiguration mit. Zunehmend gibt es auch kommerzielle Alternativen wie z.B. Elasticsearch Marvel, um beide Lösungen als große Suchcluster zu betreiben und zu überwachen.

 

And the Winner is …

Solr/Lucene und Elasticsearch ähneln sich funktional wegen des gemeinsamen Lucene-Kerns, so dass es in alltäglichen Anwendungsfällen allenfalls feine Unterschiede gibt und durchaus die Vorliebe der Entwickler den Ausschlag geben darf. Solr/Lucene gefällt vor allem durch seine weite, stabile Verbreitung, gute Erweiterbarkeit und sinnvolle Replikationsmechanismen, die in vielen Fällen ausreichen und sich bewährt haben. Elasticsearch baut aktuell vor allem seine Business Intelligence- und Analytics-Fähigkeiten aus und eignet sich hervorragend in Big-Data-Szenarien. Somit ist es bei der Planung eines großen Suchclusters mit riesigen Datenmengen aus unterschiedlichen Datenquellen die erste Wahl.

 

Der häufigste Enterprise-Search-Case ohne große Entwicklungsabteilung und ohne komplexe eigene Anpassungen an der eigentlichen Suchsoftware lässt sich durch beide Lösungen sehr gut bedienen. Die Entscheidung sollte jedoch klar für eine der beiden Lösungen gefällt werden – beide Lösungen gleichzeitig im Einsatz zu haben, ist durch die Unterschiede im Betrieb und in den Details der Anwendungen wenig sinnvoll.

 

Vom starken Wettbewerb zwischen beiden Lösungen profitieren alle Anwender gleichermaßen. Innovationen der einen Seite halten in der einen oder anderen Form auch recht schnell Einzug auf der anderen Seite. Performanceverbesserungen finden für gewöhnlich direkt auf Lucene-Ebene statt, wovon beide Lösungen unmittelbar profitieren. Bei allen Abwägungen in den Details tritt eines jedenfalls eindeutig zu Tage: Der Einsatz proprietärer Suchlösungen lohnt sich allenfalls noch bei sehr individuellen, speziellen Anwendungsfällen, in denen die Anpassungsaufwände und laufenden Kosten für den Einsatz von Open Source zu hoch wären.

 

Anmerkung:

[1] Quelle: Gartner; Information 2020: Big Data and Beyond