Weshalb wir Solr 4.0 genommen haben und nicht ElasticSearch

Bei einem neuen Projekt hatten wir zu entscheiden welche Search-Engine wir nehmen. Es gibt zwei führende Search-Engines auf dem Markt, ElasticSearch(0.20) und Apache Solr(4.0). Beide bauen auf Lucene auf. Nach einer Evaluation entschieden wir uns für Solr, lasst mich erklären warum.

Konditionen

Unsere Search-Engine sollte hochverfügbar und fehlertolerant sein. Sie sollte tausende vor Anfragen pro Sekunde vertragen und die Antwortzeit darf trotzdem nicht mehr als eine Sekunde betragen. Dieses Kunststück sollte auf kosten-günstigen 0815-Servern geschehen, für den Anfang. Beide Search-Engines haben dies drauf, es ist also eine schwere Entscheidung. Eine Pro&Kontra-Liste kann hier helfen.

Pro & Kontra

ProKontra
ProKontra
Solrgrößere CommunitySchema
kein Split-Brainkein Routing
Antwort in .csv, .xml, .json ...
besserer Sprachsupport out of the box
Grouping
Split shards(SOLR-3755)
Spellchecking
ElasticSearchSchema-losSplit-Brain
Routing für Indizierung & Abfragennur .json
nested documentsschlechterer Sprachsupport out of the box
multiple Dokumenttypen in einem Indexkein Grouping
Analyzer pro Dokument & Querykein Spellchecking
Percolator

Beide Search-Engines habe ihre Vorteile. Solr hat eine große Anzahl an ResponseWriters, einen sehr guten Sprachsupport und die Möglichkeit für vereinfachte Skalierung in verteilten Systemen mit SolrCloud. Andererseits wurde ElasticSearch bereits mit dem Grundgedanken für ein verteiltes und hochver-fügbares System gebaut. ElasticSearch besitzt eigentlich kein Schema, unterstützt nested documents, multiple Dokumenttypen in einem Index und hat ein großartiges Feature namens Percolator für die vorausschauende Suche. Auf der Kontra-Seite hat Solr keine Routing-Strategie wie ElasticSearch und es braucht ein Schema, aber ist es wirklich ein Nachteil mit dem Schema? ElasticSearch hat ein Problem mit der Split-Brain-Situation. Man muss .json nutzen um mit ElasticSearch zu kommunizieren, der Sprachsupport ist nicht „out of the box“ dabei sondern über Plugins, und es gibt kein Grouping oder Spellchecking.

Entscheidungspunkte

Bei unserem Projekt müssen wir wissen welche Suchfelder wir haben, also brauchen wir ein Schema. Die Dokumente sind datumsbasiert, die Anfragen an den richtigen Shard können also auch vom Frontend erfolgen über Filter die der Nutzer setzt. Wir wollen Dokumente im .csv-Format indizieren und als Ausgabe bekommen. Zentrales Konfigurationsmanagement wäre klasse. Wir wollen Nutzer sofort über neue Dokumente informieren, ein Feature wie der Percolator sollte existieren. Es sollte möglich sein die Ergebnisse zu gruppieren, und dass ist leider ein großer Nachteil von ElasticSearch, weil Grouping hier in Entwicklung ist, aber noch nicht für den Einsatz bereit steht. Ein weiterer negativer Punkt bei ElasticSearch ist die Split-Brain-Situation, wenn bei einem Netzwerkfehler ein weiterer Leader für das Cluster gewählt wird und auf einmal zwei unabhängige Cluster nebeneinander laufen. Abschliessend ist zu sagen dass wir keine „nested documents“-Funktionalität benötigen.

Zusammenfassung

Beide Search-Engines haben ihre eigenen Vorteile. Wir können Index-Mappings erstellen oder Einzeiler-Scripts in ElasticSearch benutzen um Daten im .csv-Format zu verarbeiten und es somit auf den Level von Solr zu bringen, wenn notwendig. Split-Brain-Situationen sind ein Problem, können aber auf ein Minimum reduziert werden durch vorausschauende Konfiguration. Leider brauchen wir die Grouping-Funktionalität. Solr gibt uns diese Funktionalität und es gibt keine Split-Brain-Situationen wegen dem Einsatz von Zookeeper bei SolrCloud. Die fehlende Funktionalität für Prospective-Search haben wir bereits selbst realisiert. Es war also der logische Schritt Solr zu nehmen.

Wie auch immer, hätten wir „nested documents“ benötigt, um Benutzerzugriffs-rechte auf Dokumentenebene zu ermöglichen, dann wäre die Entscheidung wohl auch zu Gunsten ElasticSearch ausgefallen.

You can read this blogpost in english here: http://www.sentric.ch/blog/why-we-chose-solr-4-0-instead-of-elasticsearch

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.