Apache Solr und ElasticSearch im Streitgespräch

Inhaltsverzeichnis

Lange Zeit war Apache Solr unter den quelloffenen Suchtechniken gesetzt. Seit einiger Zeit hat das Projekt jedoch Konkurrenz durch ElasticSearch bekommen. Fürsprecher der jeweiligen Suchplattform diskutieren in einem fiktiven Interview ihre Vor- und Nachteile. Doch lassen wir zuerst den Moderator des Gesprächs zu Wort kommen.

Moderator: Wenn ich mir den Open-Source-Markt im Bereich Suche und Suchtechnologie ansehe, scheinen ihn derzeit Apache Solr und ElasticSearch zu dominieren. Beide Produkte haben in den letzten 15 Monaten erhebliche Fortschritte gemacht. Ihre Beliebtheit liegt nicht zuletzt an der liberalen Apache-2-Lizenz, die den Download, die Nutzung und die Anpassung der Software kostenlos erlaubt.

Beide nutzen Apache Lucene als Indexstruktur. Das legt natürlich die Vermutung nahe, dass sich auch beide Endprodukte ähneln. In gewissen Bereichen mag das stimmen, doch ist das keine allgemeingültige Aussage. Deswegen freut es mich für diesen Artikel zwei Open-Source-Such-Experten befragen zu können, die beide Produkte wie ihre Westentaschen kennen sowie Unterschiede und Gemeinsamkeiten herausarbeiten und beleuchten wollen.

These 1: Easy to use – nicht mit Solr!

Moderator: Lassen sich Solr und ElasticSearch überhaupt miteinander vergleichen? Der Unterbau von Solr und ElasticSearch ist bei beiden Lucene. Beide Produkte sind Search-Server mit der Intention, dem Anwender hochskalierbare, performante Suchen zu ermöglichen, die mit vielen Features überzeugen. Meine Herren, was meinen Sie dazu, gibt es überhaupt nennenswerte Unterschiede?

ElasticMAN: Klar gibt es Unterscheide zwischen ElasticSearch und Solr! Und damit meine ich nicht nur technische Details, sondern auch Grundsätzliches. Das fängt direkt nach dem Download an. Im Gegensatz zu Solr ist ElasticSearch sofort einsatzfähig, da absolut keine Installation oder Konfiguration notwendig ist. ElasticSearch ist dafür ausgelegt, dass der Anwender es nur herunterladen muss, sofort starten und mit der Indizierung und Suche loslegen kann.

SolrMAN: Das gilt im Grunde auch für Solr und entspricht nur der halben Wahrheit. Auch bei Solr kannst du direkt nach dem Download loslegen. Hierfür enthält Solr ja einen vorgefertigten Jetty als Servlet-Container. Nur wird der Anwender nicht gezwungen, sich auf eine bestimmte Technik festzulegen, sondern kann sich frei zwischen vorhandenen Servlet-Containern entscheiden. Man muss sich also nicht mehr mit zusätzlichen Konfigurationen herumschlagen, sondern kann sofort loslegen.

ElasticMAN: Bei ElasticSearch brauchst du dich erst gar nicht mit so was herumärgern, denn da ist alles schon drin. Was ich aber meinte, ist die Konfiguration des Index. ElasticSearch ist schemafrei und übernimmt das Mapping von Daten auf einen spezifischen Datentyp automatisch. Bei Solr hingegen muss man erst umständlich die Datei schema.xml pflegen, bevor man loslegen kann.

SolrMAN: Seit Solr 4.4 gibt es die Schemafreiheit ebenfalls bei Solr, aber seien wir mal ehrlich: Das ist ganz nützlich zu Test- und Prototyping-Zwecken. Für die Umsetzung einer guten Volltextsuche muss ich mir schon im Vorfeld Gedanken machen, wie die Analyse umzusetzen ist.

ElasticMAN: Nun ja, da hat Apache Solr also nachgezogen, aber Folgendes musst du zugeben: Und zwar, dass die Skalierung und die Clusterbildung nicht gänzlich ohne Konfiguration bei Solr funktionieren. Bei ElasticSearch geht das "out of the box", die einzelnen Nodes finden sich automatisch, und auch die Verteilung der einzelnen Indizes beziehungsweise Shards funktioniert automatisch – ohne dass man nur eine einzige Konfiguration anpassen muss.

SolrMAN: Stimmt schon, dass man bei Solr ein bisschen was konfigurieren muss, um die SolrCloud zu erstellen, jedoch sehe ich darin auch einen Vorteil. Bei Solr kann ich beispielsweise gezielt bestimmen, auf welcher Maschine ein Index landet. Das versetzt mich wiederum in die Lage, häufig durchsuchte Indizes auf leistungsstärkere Maschinen zu verteilen, um so das Optimum an Performance herauszukitzeln. Und es kann bei Solr nicht passieren, dass sich aus Versehen eine Instanz im Cluster anmeldet und Daten abzieht.

Moderator: Meine Herren, ich fasse also kurz zusammen. Die These von ElasticMAN, dass Solr weit davon entfernt sei, das Prädikat 'easy to use' zu verdienen, kann man anscheinend so nicht stehen lassen. Obwohl sich ElasticSearch hier einen kleinen Vorteil erarbeitet hat, kann man mit Apache Solr auch ohne großen Aufwand loslegen.

These 2: ElasticSearch setzt Trends

ElasticMAN: Es ist ja nicht nur so, dass man mit ElasticSearch schneller starten und somit produktiv gehen kann. ElasticSearch ist ein Produkt, das von Grund auf dahingehend konzipiert ist, in verteilten Umgebungen eingesetzt zu werden. Alle für ElasticSearch entwickelten Funktionen unterstützen dieses Konzept. Bei Apache Solr hingegen ist dies nur ein zusätzliches Feature, das angeflanscht worden ist – und das erst, nachdem ElasticSearch das bereits hatte. Viel gravierender ist die Tatsache, dass nicht alle Funktionen von Solr mit der neuen Architekturmöglichkeit (der SolrCloud) einsetzbar sind. Deren Nutzung ist nur sinnvoll und fehlerfrei möglich, wenn man auf die traditionelle Master/Slave-Architektur setzt.

SolrMAN: Das kann ich so nicht stehen lassen. In der Tat, man könnte sagen die SolrCloud ist ein zusätzliches Modul, das entsprechend zu konfigurieren ist, damit es sich optimal einsetzen lässt. Jedoch können verteilte Systeme schon seit Urzeiten mit Apache Solr umgesetzt werden. Die SolrCloud ist nur die konsequente Weiterentwicklung der Replikations- und Sharding-Mechanismen, die bereits seit vielen Jahren integraler Bestandteil von Solr sind.

ElasticMAN: Mag ja sein, aber ElasticSearch setzt nun mal die Trends. Es hat die coolen Features: Term-Stats Facetten, Nested Documents, Parent-Child-Beziehungen zwischen Dokumenten, Percolation und vieles andere mehr. Das sind alles Dinge, die sich viele Leute da draußen sehnlichst gewünscht haben und man bei Solr vermisst.

SolrMAN: Auch hier muss ich widersprechen. Parent-Child-Beziehungen lassen sich beispielsweise bei Solr mit JOIN umsetzen. Solr setzt natürlich auch Trends, und das nicht zu knapp. Wie du wahrscheinlich weißt, kann man mit Solr zur Laufzeit einen Lucene-Index in mehrere Shards aufteilen. Das erhöht die Skalierbarkeit von Systemen weiter. Ein solches Feature gibt es bei ElasticSearch nicht.

Moderator: Ihre Standpunkte sind klar, meine Herren. Im Endeffekt ist die Frage, welches Produkt die Trends setzt, nicht endgültig zu beantworten. Solr ist vor allem bei Lucene der Vorreiter, wobei ElasticSearch in der Grundarchitektur vorne zu liegen scheint. Bei den einzelnen Features müssen wir nicht ins Detail gehen. Es gibt bei beiden Produkten Ähnliches, aber auch Features, die der Konkurrent nicht hat. Am Ende entscheidet der Anwender, welchem Trend er folgt und für welches Produkt er sich daher entscheidet.