it-swarm.com.de

Solr vs. ElasticSearch

Was sind die architektonischen Kernunterschiede zwischen diesen Technologien?

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

716
Ben ODay

Aktualisieren

Nachdem der Umfang der Fragen korrigiert wurde, möchte ich diesbezüglich noch etwas hinzufügen:

Es gibt viele Vergleiche zwischen Apache Solr und ElasticSearch , daher werde ich auf diejenigen verweisen, die ich selbst als am nützlichsten empfunden habe, d. H. Die wichtigsten Aspekte abdecken:

  • Bob Yoplait hat Kimchys Antwort bereits mit ElasticSearch, Sphinx, Lucene, Solr, Xapian. Welches passt für welche Verwendung? , welches fasst die Gründe zusammen, warum erElasticSearch erstellt hat, was seiner Meinung nachliefert ein viel besseres verteiltes Modell und Benutzerfreundlichkeitim Vergleich zu Solr.

  • Ryan Sonneks Realtime Search: Solr vs Elasticsearch liefert eine aufschlussreiche Analyse/einen Vergleich und erklärt, warum er von Solr zu ElasticSeach gewechselt ist, obwohl er bereits ein zufriedener 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 zur Erstellung moderner Echtzeitsuchanwendungen auf die nächste Ebene . Perkolation ist eine aufregende und innovative Funktion, die Solr aus dem Wasser bläst. Elasticsearch ist skalierbar, schnell und es ist ein Traum, sich in zu integrieren. Adios Solr, es war schön, Sie zu kennen.[Hervorhebung meiner]

  • Der Wikipedia-Artikel über ElasticSearch zitiert ein Vergleich aus dem renommierten deutschen iX-Magazin, in dem Vor- und Nachteile aufgelistet sind.

    Vorteile :

    • ElasticSearch wird verteilt. Kein separates Projekt erforderlich. Replikate sind ebenfalls nahezu in Echtzeit, was als "Push-Replikation" bezeichnet wird.
    • ElasticSearch unterstützt die Echtzeitsuche von Apache Lucene.
    • Die Handhabung von Mandantenfähigkeit ist keine spezielle Konfiguration, bei der mit Solr ein erweitertes Setup erforderlich ist.
    • ElasticSearch stellt das Konzept des Gateways vor, das vollständige Backups erleichtert.

    Nachteile :

    • Nur ein Hauptentwickler [nicht mehr zutreffend gemäß der aktuellen elasticsearch GitHub Organisation , abgesehen davon, dass es an erster Stelle eine ziemlich aktive Committer-Basis gibt]
    • Keine automatische Aufwärmfunktion [gilt nicht mehr gemäß der neuen Index Warmup API ]

Erstantwort

Es handelt sich um völlig unterschiedliche Technologien, die sich auf völlig unterschiedliche Anwendungsfälle beziehen und daher in keiner Weise sinnvoll verglichen werden können:

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

  • Amazon ElastiCache -Amazon ElastiCache ist ein Webdienst, der die Bereitstellung, den Betrieb und die Skalierung eines speicherinternen Caches in der Cloud vereinfacht.

    • Beachten Sie, dassAmazon ElastiCache mit Memcached, einem weit verbreiteten System zur Zwischenspeicherung von Speicherobjekten, kompatibel ist, sodass Code, Anwendungen und beliebte Tools, die Sie heute in vorhandenen Memcached-Umgebungen verwenden, nahtlos mit dem zusammenarbeiten service(Details siehe Memcached ).

[Hervorhebung meiner]

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

  • ElasticSearch -Es ist eine Open Source (Apache 2), Distributed, RESTful, Search Engine, die auf Apache Lucene basiert.

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

DieSolrundElasticSearch-Angebote klingen auf den ersten Blick erstaunlich ähnlich und verwenden beide dieselbe Backend-Suchmaschine, nämlich Apache Lucene .

WährendSolrälter ist, recht vielseitig und ausgereift und dementsprechend weit verbreitet ist, wurdeElasticSearchspeziell entwickelt, umSolrMängel mit Skalierbarkeitsanforderungen in modernen Cloud-Umgebungen, die mitSolrnur schwer zu beheben sind.

Als solches wäre es wahrscheinlich am nützlichsten,ElasticSearchmit dem kürzlich eingeführtenAmazon CloudSearchzu vergleichen (siehe den einleitenden Beitrag) In einer Stunde nach weniger als 100 USD/Monat suchen ), da beide behaupten, im Prinzip dieselben Anwendungsfälle abzudecken.

548
Steffen Opel

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

  • Community: Solr hat eine größere, ausgereiftere Community für Benutzer, Entwickler und Mitwirkende. ES hat eine kleinere, aber aktive Community von Benutzern und eine wachsende Community 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/haben keine direkten Leistungsbenchmarks durchgeführt. Eine Person bei LinkedIn hat Solr vs. ES vs. Sensei einmal verglichen, aber die anfänglichen 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 es zusammengesetzt ist. Solr-Code ist leider nicht immer sehr hübsch. Außerdem sind in ES Sharding, Echtzeitreplikation, Dokument und Routing integriert. Während einiges davon auch in Solr existiert, fühlt es sich ein bisschen wie ein Nachdenken an.
  • Support: Es gibt Unternehmen, die technischen und beratenden Support für Solr und ElasticSearch anbieten. 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 Version vor Solr 4.0, 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, der einen direkten und neutralen Vergleich zwischen Solr und ElasticSearch durchführt. Offenlegung: Ich arbeite bei Sematext.

203

Ich sehe, dass viele Leute hier diese Frage zu ElasticSearch vs. Solr in Bezug auf Features und Funktionalität beantwortet haben, aber ich sehe hier (oder anderswo) nicht viele Diskussionen darüber, wie sie in Bezug auf die Leistung verglichen werden.

Deshalb habe ich beschlossen, meine eigenen ntersuchung durchzuführen. Ich habe einen bereits codierten Mikrodienst für heterogene Datenquellen verwendet, der Solr bereits für die Begriffssuche verwendet hat. Ich habe Solr für ElasticSearch umgestellt und dann beide Versionen auf AWS mit einer bereits codierten Lasttestanwendung ausgeführt und die Leistungsmessdaten für die nachfolgende Analyse erfasst.

Hier ist was ich gefunden habe. ElasticSearch erzielte beim Indizieren von Dokumenten einen um 13% höheren Durchsatz, während Solr zehnmal schneller war. Bei der Abfrage von Dokumenten erzielte Solr einen fünfmal höheren Durchsatz und war fünfmal schneller als ElasticSearch.

23
Glenn

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

solr stack

Durchsuchen Sie die Plattform in den folgenden Ebenen von unten nach oben:

  • Daten
    • Zweck: Verschiedene Datentypen und Quellen darstellen
  • Dokumenterstellung
    • Zweck: Dokumentinformationen für die Indizierung erstellen
  • Indizierung und Suche
    • Zweck: Dokumentindex erstellen und abfragen
  • 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: nternehmenssuche

16
mingxue

Ich habe eine Tabelle mit den wichtigsten Unterschieden zwischen elasticsearch und Solr und splunk erstellt. Sie können sie als 2016-Update verwenden: enter image description here

14
Fardin Behboudi

Ich habe sowohl an der solr als auch an der elastischen Suche nach .Net-Anwendungen gearbeitet. Der Hauptunterschied, dem ich gegenübergestanden habe, ist

Elastische Suche:

  • Mehr Code und weniger Konfiguration, es gibt jedoch APIs, die geändert werden müssen, es handelt sich jedoch immer noch um eine Codeänderung
  • geben Sie für komplexe Typen innerhalb von Typen ein, d. h. 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 in der elastischen Suche in kurzer Zeit nicht auf direktem Weg zu erreichen)
13
robert

Alle oben genannten Links haben sich bewährt und haben mir in der Vergangenheit große Vorteile gebracht. 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 verläuft. Davon abgesehen fühlte sich ein Teil des Codes für mich nicht intuitiv an. Also griff ich aus einer Open-Source-Perspektive nach einer Komponente des ELK-Stacks, Kibana, und stellte fest, dass ich den etwas kryptischen Code der Elasticsearch in Kibana sehr einfach generieren konnte. 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 in Anspruch nahm, um auf anderen Plattformen ausgeführt zu werden, war, dass JSON in Sense in wenigen Minuten neben Elasticsearch (REST-konforme Schnittstelle) ausgeführt wurde (größte Datenmengen). im besten Fall in Sekunden. Die Dokumentation für Elasticsearch mit über 700 Seiten beantwortete keine Fragen, die ich normalerweise in SOLR oder einer anderen Lucene-Dokumentation gelöst hatte, 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 eine neue Ebene gebracht haben.

Allgemeines: 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, Textfrequenz/Inverse Document Frequency, verwenden, erweitert elasticsearch den Algorithmus dieser 1960er Jahre auf ein neues Niveau, selbst wenn BM25, Best Match 25 und andere Algorithmen für das Relevanz-Ranking verwendet werden. Wenn Sie also Wörter, Phrasen oder Sätze bewerten oder ein Ranking erstellen, führt elasticsearch diese Bewertung im Handumdrehen durch, ohne den großen Aufwand anderer Datenanalyseansätze, die Stunden in Anspruch nehmen - eine weitere Zeitersparnis bei elasticsearch. Durch die Kombination einiger Stärken des Bucketing aus Aggregationen mit der Echtzeitbewertung und Rangfolge der JSON-Datenrelevanz können Sie eine erfolgreiche Kombination finden, die entweder von Ihrem agilen Ansatz (Storys) oder Ihrem architektonischen Ansatz (Use Cases) abhängt.

Anmerkung: Ich habe eine ähnliche Diskussion zu den oben genannten Aggregationen gesehen, aber nicht zu den Aggregationen und der Relevanzbewertung - ich entschuldige mich für etwaige Überschneidungen. Offenlegung: Ich arbeite nicht für elastisch und werde in naher Zukunft aufgrund eines anderen architektonischen Pfades nicht von ihrer hervorragenden Arbeit profitieren können, es sei denn, ich arbeite für wohltätige Zwecke mit elasticsearch, was keine schlechte Idee wäre

7
MethodyM

Stellen Sie sich den Anwendungsfall vor:

  1. Viele (über 100) kleine Suchindizes (10 - 100 MB, 1000 - 100 000 Dokumente).
  2. Sie werden von vielen Anwendungen genutzt (Microservices)
  3. Jede Anwendung kann mehr als einen Index verwenden
  4. Klein nach Größenindex, ja. Aber riesige Last (Hunderte Suchanfragen pro Sekunde) und Anfragen sind komplex (mehrere Aggregationen, Bedingungen usw.)
  5. Ausfallzeiten sind nicht zulässig
  6. All das funktioniert Jahre lang und wächst ständig.

Die Idee, für jeden Index eine eigene ES-Instanz zu haben, ist in diesem Fall sehr aufwändig.

Nach meiner Erfahrung ist diese Art von Anwendungsfall für die Unterstützung mit Elasticsearch sehr komplex.

Warum?

ZUERST.

Das Hauptproblem ist die grundsätzliche Nichtbeachtung der Rückenkompatibilität.

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

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

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

Damit. Wenn Sie ES aktualisieren möchten (weil Sie für eine App neue Funktionen benötigen oder Fehlerbehebungen benötigen), sind Sie in der Hölle. Vor allem, wenn es um Hauptversionsupgrades geht.

Client API wird nicht zurückkompatibel sein. Die Indexeinstellungen sind nicht wieder kompatibel. Ein Upgrade aller Apps/Services zum selben Zeitpunkt mit 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 alte Indizes ändern müssen.

Um damit zu leben, müssen Sie ständig viel Leistung in die Aufwärtskompatibilität Ihrer Apps/Dienste mit zukünftigen Versionen von ES investieren. Oder Sie müssen eine Art von Middleware zwischen Ihrer App/Ihren Diensten und ES erstellen (und unterstützen), die Ihnen eine kompatible Client-API bietet. (Außerdem können Sie Transport Client nicht verwenden, da für jedes Upgrade der Minor-Version ES ein JAR-Upgrade erforderlich ist.)

Sieht es einfach und billig aus? Nein, ist es nicht. Weit davon entfernt. Die kontinuierliche Wartung einer komplexen Infrastruktur, die auf ES basiert, ist in jeder Hinsicht viel zu teuer.

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


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

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

Hinweis: Sphinxsearch/Manticore sind in der Tat interessant. Es basiert nicht auf Lucine und unterscheidet sich daher erheblich. Enthalten mehrere einzigartige Funktionen aus der Box, die ES nicht hat und die schnell mit kleinen/mittleren Indizes verrückt sind.

5
Gmugra

Ich benutze Elasticsearch seit 3 ​​Jahren und Solr seit ungefähr einem Monat. Ich bin der Meinung, dass Elasticsearch Cluster im Vergleich zur Solr-Installation recht einfach zu installieren ist. Elasticsearch verfügt über einen Pool von Hilfedokumenten mit ausführlichen Erläuterungen. Ein Anwendungsfall, bei dem ich mich mit der Histogrammaggregation befasst habe, die in ES verfügbar war, in Solr jedoch nicht gefunden wurde.

3

Wenn Sie SOLR bereits verwenden, bleiben Sie dabei. Wenn Sie anfangen, gehen Sie zur elastischen Suche.

Maximale Hauptprobleme wurden in SOLR behoben und es ist ziemlich ausgereift.

3
Behzad Qureshi

Ich benutze nur die Elastic-Suche. 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 aufbauen.
  2. Einfache Restful-API, die NoSQL-Abfrage verwendet. Und viele Sprachbibliotheken für den einfachen Zugriff.
  3. Gutes Dokument, können Sie das Buch lesen:. Es gibt eine Webversion auf der offiziellen Website.
2
Howardyan

Fügen Sie ein verschachteltes Dokument in solr hinzu, und die Suche nach verschachtelten Daten ist ebenfalls sehr komplex. Mit Elastic Search können Sie jedoch einfach verschachtelte Dokumente hinzufügen und suchen

2
Chirag