Solr vs. ElasticSearch [geschlossen]

Was sind die wichtigsten architektonischen Unterschiede zwischen diesen Technologien?

Welche Anwendungsfälle sind im Allgemeinen für jeden besser geeignet?

Aktualisieren

Nachdem der Fragenbereich korrigiert wurde, möchte ich auch diesbezüglich etwas hinzufügen:

Es gibt viele Vergleiche zwischen Apache Solr und ElasticSearch , daher werde ich auf diejenigen verweisen, die ich selbst am nützlichsten fand, dh die wichtigsten Aspekte abdecken:

• Bob Yoplait hat Kimchys Antwort bereits mit ElasticSearch, Sphinx, Lucene, Solr, Xapian verknüpft. Welches passt für welchen Einsatz? , in dem die Gründe zusammengefasst sind, warum er ElasticSearch entwickelt hat , das seiner Meinung nach im Vergleich zu Solr ein viel besseres verteiltes Modell und eine einfache Bedienung bietet .

• Ryan Sonneks Echtzeitsuche: Solr vs Elasticsearch bietet eine aufschlussreiche Analyse / Vergleich und erklärt, warum er von Solr zu ElasticSeach gewechselt ist, obwohl er bereits ein glücklicher Solr-Benutzer ist - er fasst dies wie folgt zusammen:

  Solr ist möglicherweise die Waffe der Wahl beim Erstellen von Standardsuchanwendungen , aber Elasticsearch bringt es mit einer Architektur zum Erstellen moderner Echtzeitsuchanwendungen auf die nächste Ebene . Perkolation ist eine aufregende und innovative Funktion, die Solr im Alleingang direkt aus dem Wasser bläst. Elasticsearch ist skalierbar, schnell und ein Traum, in den man sich integrieren kann . Adios Solr, es war schön dich zu kennen. [Hervorhebung von mir]

• Der Wikipedia-Artikel über ElasticSearch zitiert einen Vergleich aus dem renommierten deutschen iX-Magazin und listet Vor- und Nachteile auf, die das oben Gesagte ziemlich gut zusammenfassen:

  Vorteile :

  • ElasticSearch wird verteilt. Kein separates Projekt erforderlich. Replikate sind ebenfalls nahezu in Echtzeit verfügbar, was als "Push-Replikation" bezeichnet wird.
  • ElasticSearch unterstützt die Echtzeitsuche von Apache Lucene vollständig.
  • Die Behandlung von Mandantenfähigkeit ist keine spezielle Konfiguration, bei der bei Solr eine erweiterte Einrichtung erforderlich ist.
  • ElasticSearch führt das Konzept des Gateways ein, das vollständige Sicherungen erleichtert.

  Nachteile :

  • Nur ein Hauptentwickler [gilt laut der aktuellen GitHub-Organisation von elasticsearch nicht mehr , abgesehen davon, dass er überhaupt eine ziemlich aktive Committer-Basis hat]
  • Keine automatische Erwärmungsfunktion [gilt nicht mehr gemäß der neuen Index-Aufwärm-API ]

Erste Antwort

Es handelt sich um völlig unterschiedliche Technologien, die sich mit völlig unterschiedlichen Anwendungsfällen befassen und daher überhaupt nicht sinnvoll verglichen werden können:

• Apache Solr - Apache Solr bietet die Funktionen von Lucene in einem benutzerfreundlichen, schnellen Suchserver mit zusätzlichen Funktionen wie Facettierung, Skalierbarkeit und vielem mehr

• Amazon ElastiCache - Amazon ElastiCache ist ein Webdienst, mit dem ein speicherinterner Cache in der Cloud einfach bereitgestellt, betrieben und skaliert werden kann .

  • Beachten Sie, dass Amazon ElastiCache protokollkompatibel mit Memcached ist, einem weit verbreiteten System zum Zwischenspeichern von Speicherobjekten. Code, Anwendungen und beliebte Tools, die Sie heute in vorhandenen Memcached-Umgebungen verwenden, funktionieren nahtlos mit dem Dienst ( Einzelheiten finden Sie unter Memcached ).

[Hervorhebung von mir]

Vielleicht wurde dies auf die eine oder andere Weise mit den folgenden zwei verwandten Technologien verwechselt:

• ElasticSearch - Es handelt sich um eine verteilte Open-Source-Suchmaschine (Apache 2), die auf Apache Lucene basiert.

• Amazon CloudSearch - Amazon CloudSearch ist ein vollständig verwalteter Suchdienst in der Cloud, mit dem Kunden schnell und einfach skalierbare Suchfunktionen in ihre Anwendungen integrieren können.

Die Angebote von Solr und ElasticSearch klingen auf den ersten Blick auffallend ähnlich und beide verwenden dieselbe Backend-Suchmaschine, nämlich Apache Lucene .

Während Solr älter, vielseitig und ausgereift ist und dementsprechend weit verbreitet ist, wurde ElasticSearch speziell entwickelt, um Solr- Mängel mit Skalierbarkeitsanforderungen in modernen Cloud-Umgebungen zu beheben, die mit Solr nur schwer zu beheben sind .

Daher wäre es wahrscheinlich am nützlichsten, ElasticSearch mit der kürzlich eingeführten Amazon CloudSearch zu vergleichen (siehe den Einführungsbeitrag Starten Sie die Suche in einer Stunde für weniger als 100 USD / Monat ), da beide behaupten, im Prinzip dieselben Anwendungsfälle abzudecken.

Ich sehe, dass einige der obigen Antworten jetzt etwas veraltet sind. Aus meiner Sicht und wenn ich täglich mit Solr (Cloud und Nicht-Cloud) und ElasticSearch arbeite, gibt es einige interessante Unterschiede:

• Community: Solr hat eine größere, ausgereiftere Community für Benutzer, Entwickler und Mitwirkende. ES hat eine kleinere, aber aktive Benutzergemeinschaft und eine wachsende Gemeinschaft von Mitwirkenden
• Reife: Solr ist reifer, aber ES ist schnell gewachsen und ich halte es für stabil
• Leistung: schwer zu beurteilen. Ich / wir haben keine direkten Leistungsbenchmarks durchgeführt. Eine Person bei LinkedIn hat Solr vs. ES vs. Sensei einmal verglichen, aber die ersten Ergebnisse sollten ignoriert werden, da sie sowohl für Solr als auch für ES ein nicht fachkundiges Setup verwendet haben.
• Design: Menschen lieben Solr. Die Java-API ist etwas ausführlich, aber die Leute mögen, wie sie zusammengesetzt ist. Solr-Code ist leider nicht immer sehr hübsch. Außerdem verfügt ES über integrierte Funktionen für Sharding, Echtzeitreplikation, Dokumente und Routing. Während einiges davon auch in Solr existiert, fühlt es sich ein bisschen wie ein Nachdenken an.
• Support: Es gibt Unternehmen, die sowohl Solr als auch ElasticSearch technischen und beratenden Support bieten. Ich denke, das einzige Unternehmen, das beide unterstützt, ist Sematext (Offenlegung: Ich bin Sematext-Gründer)
• Skalierbarkeit: Beide können auf sehr große Cluster skaliert werden. ES ist einfacher zu skalieren als die Vor-Solr 4.0-Version von Solr, aber mit Solr 4.0 ist dies nicht mehr der Fall.

Weitere Informationen zum Thema Solr vs. ElasticSearch finden Sie unter https://sematext.com/blog/solr-vs-elasticsearch-part-1-overview/ . Dies ist der erste Beitrag in der Reihe der Beiträge von Sematext, die einen direkten und neutralen Vergleich von Solr und ElasticSearch durchführen. Offenlegung: Ich arbeite bei Sematext.

Ich sehe, dass viele Leute hier diese Frage von ElasticSearch gegen Solr in Bezug auf Features und Funktionen beantwortet haben, aber ich sehe hier (oder anderswo) nicht viele Diskussionen darüber, wie sie sich in Bezug auf die Leistung vergleichen.

Deshalb habe ich beschlossen, meine eigenen Ermittlungen durchzuführen . Ich habe einen bereits codierten heterogenen Datenquellen-Mikrodienst verwendet, der Solr bereits für die Begriffssuche verwendet hat. Ich habe Solr für ElasticSearch ausgeschaltet, dann beide Versionen unter AWS mit einer bereits codierten Lasttestanwendung ausgeführt und die Leistungsmetriken für die nachfolgende Analyse erfasst.

Folgendes habe ich gefunden. ElasticSearch hatte einen um 13% höheren Durchsatz bei der Indizierung von Dokumenten, aber Solr war zehnmal schneller. Bei der Abfrage von Dokumenten hatte Solr einen fünfmal höheren Durchsatz und war fünfmal schneller als ElasticSearch.

Seit der langen Geschichte von Apache Solr denke ich, dass eine Stärke des Solr sein Ökosystem ist . Es gibt viele Solr-Plugins für verschiedene Arten von Daten und Zwecken.

Suchplattform in den folgenden Ebenen von unten nach oben:

• Daten
  • Zweck: Stellen Sie verschiedene Datentypen und Quellen dar
• Dokumenterstellung
  • Zweck: Erstellen Sie Dokumentinformationen für die Indizierung
• Indizieren und Suchen
  • Zweck: Erstellen und Abfragen eines Dokumentindex
• Logikverbesserung
  • Zweck: Zusätzliche Logik zur Verarbeitung von Suchanfragen und Ergebnissen
• Suchplattformdienst
  • Zweck: Fügen Sie zusätzliche Funktionen des Suchmaschinenkerns hinzu, um eine Serviceplattform bereitzustellen.
• UI-Anwendung
  • Zweck: Endbenutzersuchoberfläche oder -anwendungen

Referenzartikel: Unternehmenssuche

Ich habe eine Tabelle mit den wichtigsten Unterschieden zwischen Elasticsearch und Solr und Splunk erstellt. Sie können sie als Update für 2016 verwenden:

Ich habe sowohl an der solr- als auch an der elastischen Suche nach .NET-Anwendungen gearbeitet. Der Hauptunterschied, dem ich begegnet bin, ist

Elastische Suche:

• Mehr Code und weniger Konfiguration, es müssen jedoch APIs geändert werden, es handelt sich jedoch immer noch um eine Codeänderung
• Geben Sie für komplexe Typen innerhalb von Typen ein, dh verschachtelte Typen (konnte in solr nicht erreicht werden).

Solr:

• weniger Code und mehr Konfiguration und damit weniger Wartung
• zum Gruppieren von Ergebnissen während der Abfrage (viel Arbeit bei der elastischen Suche in kurzer Zeit nicht direkt)

Obwohl alle oben genannten Links Verdienste haben und mir in der Vergangenheit sehr geholfen haben, als Linguist, der in den letzten 15 Jahren verschiedenen Lucene-Suchmaschinen "ausgesetzt" war, muss ich sagen, dass die Entwicklung der elastischen Suche in Python sehr schnell ist. Davon abgesehen fühlte sich ein Teil des Codes für mich nicht intuitiv an. Also habe ich mich aus Open-Source-Sicht an eine Komponente des ELK-Stacks, Kibana, gewandt und festgestellt, dass ich den etwas kryptischen Code der Elasticsearch in Kibana sehr einfach generieren kann. Außerdem könnte ich Chrome Sense es-Abfragen auch in Kibana ziehen. Wenn Sie Kibana verwenden, um es zu bewerten, wird dies Ihre Bewertung weiter beschleunigen. Was Stunden dauerte, um auf anderen Plattformen ausgeführt zu werden, war in JSON in Sense auf elasticsearch (RESTful-Schnittstelle) in wenigen Minuten (größte Datenmengen) betriebsbereit. bestenfalls in Sekunden. Die Dokumentation für elasticsearch beantwortete zwar mehr als 700 Seiten, beantwortete jedoch keine Fragen, die normalerweise in SOLR oder anderen Lucene-Dokumentationen gelöst wurden, deren Analyse offensichtlich mehr Zeit in Anspruch nahm. Vielleicht möchten Sie auch einen Blick auf Aggregate in der elastischen Suche werfen, die Facettierung auf ein neues Niveau gebracht haben.

Größeres Bild: Wenn Sie Datenwissenschaft, Textanalyse oder Computerlinguistik betreiben, verfügt Elasticsearch über einige Ranking-Algorithmen, die im Bereich des Informationsabrufs anscheinend innovativ sind. Wenn Sie TF / IDF-Algorithmen verwenden, Textfrequenz / Inverse Dokumentfrequenz, erweitert elasticsearch diesen Algorithmus aus den 1960er Jahren auf ein neues Niveau, selbst wenn BM25, Best Match 25 und andere Algorithmen für das Relevanzranking verwendet werden. Wenn Sie also Wörter, Phrasen oder Sätze bewerten oder bewerten, führt elasticsearch diese Bewertung im laufenden Betrieb durch, ohne den großen Aufwand anderer Datenanalyse-Ansätze, die Stunden dauern - eine weitere Zeitersparnis bei der Elasticsearch. Wenn Sie einige der Stärken des Bucketing aus Aggregationen mit der Echtzeitbewertung und Rangfolge der JSON-Datenrelevanz kombinieren, können Sie eine gewinnbringende Kombination finden.

Hinweis: Ich habe oben eine ähnliche Diskussion zu Aggregationen gesehen, jedoch nicht zu Aggregationen und Relevanzbewertungen - ich entschuldige mich für etwaige Überschneidungen. Offenlegung: Ich arbeite nicht für Gummibänder und kann in naher Zukunft aufgrund eines anderen architektonischen Pfades nicht von ihrer hervorragenden Arbeit profitieren, es sei denn, ich mache Wohltätigkeitsarbeit mit Elasticsearch, was keine schlechte Idee wäre

Stellen Sie sich den Anwendungsfall vor:

1. Viele (100+) kleine (10Mb-100Mb, 1000-100000 Dokumente) Suchindizes.
2. Sie werden von vielen Anwendungen (Microservices) verwendet.
3. Jede Anwendung kann mehr als einen Index verwenden
4. Klein nach Größenindex, ja. Eine enorme Belastung (Hunderte Suchanfragen pro Sekunde) und Anforderungen sind jedoch komplex (mehrere Aggregationen, Bedingungen usw.).
5. Ausfallzeiten sind nicht zulässig
6. All das funktioniert jahrelang und wächst ständig.

Die Idee, für jeden Index eine eigene ES-Instanz zu haben, ist in diesem Fall ein enormer Aufwand.

Aufgrund meiner Erfahrung ist die Unterstützung dieser Art von Anwendungsfall mit Elasticsearch sehr komplex.

Warum?

ZUERST.

Das Hauptproblem ist die grundsätzliche Missachtung der Rückenverträglichkeit.

Breaking Änderungen sind so cool! (Hinweis: Stellen Sie sich einen SQL-Server vor, bei dem Sie beim Upgrade kleine Änderungen an all Ihren SQL-Anweisungen vornehmen müssen. Ich kann es mir nicht vorstellen. Aber für ES ist es normal.)

Abwertungen, die in der nächsten Hauptversion fallen werden, sind so sexy! (Hinweis: Sie wissen, Java enthält einige Abwertungen, die über 20 Jahre alt sind, aber immer noch in der aktuellen Java-Version funktionieren ...)

Und nicht nur das, manchmal haben Sie sogar etwas, das nirgends dokumentiert ist (persönlich nur einmal aufgetaucht, aber ...)

Damit. Wenn Sie ES aktualisieren möchten (weil Sie für eine App neue Funktionen benötigen oder Fehlerbehebungen erhalten möchten), sind Sie in der Hölle. Vor allem, wenn es um ein größeres Versions-Upgrade geht.

Die Client-API ist nicht rückkompatibel. Die Indexeinstellungen sind nicht rückkompatibel. Ein Upgrade aller Apps / Dienste im selben Moment mit einem ES-Upgrade ist nicht realistisch.

Aber du musst es von Zeit zu Zeit tun. Kein anderer Weg.

Bestehende Indizes werden automatisch aktualisiert? - Ja. Es hilft Ihnen jedoch nicht, wenn Sie einige Einstellungen für den alten Index ändern müssen.

Um damit zu leben, müssen Sie ständig viel Energie in die Vorwärtskompatibilität Ihrer Apps / Dienste mit zukünftigen Versionen von ES investieren. Oder Sie müssen eine Art Middleware zwischen Ihrer App / Ihren Diensten und ES erstellen (und trotzdem ständig unterstützen), die Ihnen eine rückkompatible Client-API bietet. (Und Sie können Transport Client nicht verwenden (da für jedes kleinere ES-Upgrade ein JAR-Upgrade erforderlich ist), und diese Tatsache erleichtert Ihnen das Leben nicht.)

Sieht es einfach und billig aus? Nein, ist es nicht. Weit davon entfernt. Die kontinuierliche Wartung komplexer Infrastrukturen, die auf ES basieren, ist in jeder Hinsicht viel zu teuer.

ZWEITE. Einfache API? Nun ... nein wirklich. Wenn Sie wirklich komplexe Bedingungen und Aggregationen verwenden ... JSON-Anfrage mit 5 verschachtelten Ebenen ist was auch immer, aber nicht einfach.

Leider habe ich keine Erfahrung mit SOLR, kann nichts dazu sagen.

Aber Sphinxsearch ist in diesem Szenario viel besser, da SphinxQL vollständig rückkompatibel ist.

Hinweis: Sphinxsearch / Manticore sind in der Tat interessant. Es basiert nicht auf Lucine und ist daher ernsthaft anders. Enthält einige einzigartige Funktionen aus der Box, die ES nicht hat und die mit kleinen / mittleren Indizes schnell verrückt werden.

Wenn Sie SOLR bereits verwenden, bleiben Sie dabei. Wenn Sie starten, wählen Sie Elastische Suche.

In SOLR wurden maximale Hauptprobleme behoben, und es ist ziemlich ausgereift.

Ich benutze Elasticsearch seit 3 ​​Jahren und Solr seit ungefähr einem Monat. Ich bin der Meinung, dass der Elasticsearch-Cluster im Vergleich zur Solr-Installation recht einfach zu installieren ist. Elasticsearch verfügt über einen Pool von Hilfedokumenten mit hervorragenden Erklärungen. Einer der Anwendungsfälle war die Histogrammaggregation, die in ES verfügbar war, in Solr jedoch nicht gefunden wurde.

Ich benutze nur Elastic-Search. Da ich Solr gefunden habe ist es sehr schwer anzufangen. Funktionen von Elastic-Search:

1. Einfach zu starten, sehr wenige Einstellungen. Sogar ein Neuling kann Schritt für Schritt einen Cluster einrichten.
2. Einfache Restful API, die NoSQL-Abfrage verwendet. Und viele Sprachbibliotheken für den einfachen Zugriff.
3. Gutes Dokument, Sie können das Buch lesen :. Es gibt eine Webversion auf der offiziellen Website.

Fügen Sie ein verschachteltes Dokument in solr sehr komplex und verschachtelte Datensuche auch sehr komplex hinzu. aber Elastic Search einfach, verschachteltes Dokument hinzuzufügen und zu suchen