Question Solr vs. ElasticSearch


Quelles sont les principales différences architecturales entre ces technologies?

En outre, quels cas d'utilisation sont généralement plus appropriés pour chacun?


658
2018-04-18 15:42


origine


Réponses:


Mettre à jour

Maintenant que la portée de la question a été corrigée, je pourrais ajouter quelque chose à cet égard:

Il y a beaucoup de comparaisons entre Apache Solr et ElasticSearch disponible, donc je vais me référer à ceux que je trouve les plus utiles, c'est-à-dire couvrant les aspects les plus importants:

  • Bob Yoplait a déjà lié la réponse de Kimchi à ElasticSearch, Sphinx, Lucene, Solr, Xapian. Ce qui correspond à quel usage?, qui résume les raisons pour lesquelles il est allé de l'avant et a créé ElasticSearch, qui à son avis fournit un modèle distribué bien supérieur et une facilité d'utilisation en comparaison avec Solr.

  • Ryan Sonnek's Recherche en temps réel: Solr vs Elasticsearch fournit une analyse / comparaison perspicace et explique pourquoi il est passé de Solr à ElasticSeach, bien qu'il soit déjà un heureux utilisateur de Solr - il résume comme suit:

    Solr peut être l'arme de choix lors de la construction recherche standard   applications, mais Elasticsearch prend au niveau suivant avec un    architecture pour créer des applications de recherche en temps réel modernes.   Percolation est une fonctionnalité passionnante et innovante qui, à lui seul,   souffle Solr juste hors de l'eau. Elasticsearch est évolutif, rapide   et un rêve à intégrer avec. Adios Solr, c'était sympa de te connaître. [Je souligne]

  • L'article Wikipedia sur ElasticSearch cite un Comparaison du magazine allemand réputé iX, énumérant les avantages et les inconvénients, qui résument assez bien ce qui a déjà été dit ci-dessus:

    Avantages:

    • ElasticSearch est distribué. Aucun projet séparé requis. Les réplicas sont également en temps réel, ce qui s'appelle "Réplication poussée".
    • ElasticSearch prend entièrement en charge la recherche en temps quasi réel d'Apache   Lucene.
    • La gestion de multitenancy n'est pas une configuration spéciale, où   avec Solr une configuration plus avancée est nécessaire.
    • ElasticSearch présente   le concept de la passerelle, qui facilite les sauvegardes complètes.

    Désavantages:

    • Un seul développeur principal  [Ne s'applique plus selon le courant GosHub organisation de elasticsearch, en plus d'avoir une base de committer assez active en premier lieu]
    • Aucune fonction d'autowarming  [Ne s'applique plus selon la nouvelle Index Warmup API]

Réponse initiale

Ce sont des technologies complètement différentes qui répondent à des cas d'utilisation complètement différents, et qui ne peuvent donc être comparés de manière significative:

  • Apache Solr - Apache Solr offre les capacités de Lucene dans un facile à utiliser, rapide serveur de recherche avec des fonctionnalités supplémentaires comme le facettage, l'évolutivité et bien plus encore

  • Amazon ElastiCache - Amazon ElastiCache est un service Web qui facilite le déploiement, l'exploitation et l'évolutivité cache en mémoire dans le nuage.

    • Veuillez noter que Amazon ElastiCache est conforme au protocole avec Memcached, un système de mise en cache d'objets mémoire largement adopté, de sorte que le code, les applications et les outils populaires que vous utilisez aujourd'hui avec les environnements Memcached existants fonctionneront de manière transparente avec le service (voir Memcached pour plus de détails).

[Je souligne]

Peut-être que cela a été confondu avec les deux technologies connexes suivantes d'une manière ou d'une autre:

  • ElasticSearch - C'est un moteur de recherche Open Source (Apache 2), distribué, RESTful, construit sur Apache Lucene.

  • Amazon CloudSearch - Amazon CloudSearch est un service de recherche entièrement géré dans le cloud qui permet aux clients d'intégrer facilement des fonctionnalités de recherche rapides et hautement évolutives dans leurs applications.

le Solr et ElasticSearch Les offres sont étonnamment similaires à première vue, et les deux utilisent le même moteur de recherche backend, à savoir Apache Lucene.

Tandis que Solr est plus âgé, assez polyvalent et mature et largement utilisé en conséquence, ElasticSearch a été développé spécifiquement pour répondre Solr les insuffisances avec les exigences d'évolutivité dans les environnements cloud modernes, qui sont difficiles à Solr.

En tant que tel, il serait probablement plus utile de comparer ElasticSearch avec le récemment introduit Amazon CloudSearch (voir le message d'introduction Commencez la recherche en une heure pour moins de 100 $ / mois), parce que les deux prétendent couvrir en principe les mêmes cas d'utilisation.


503
2018-04-18 16:15



Je vois certaines des réponses ci-dessus sont maintenant un peu démodé. De mon point de vue, et je travaille quotidiennement avec Solr (Cloud et non-Cloud) et ElasticSearch, voici quelques différences intéressantes:

  • Communauté: Solr a une communauté d'utilisateurs, de développeurs et de contributeurs plus grande et plus mature. ES a une communauté d'utilisateurs plus petite mais active et une communauté croissante de contributeurs
  • Maturité: Solr est plus mature, mais ES a grandi rapidement et je le considère stable
  • Performance: difficile à juger. Je / nous n'avons pas effectué de benchmarks de performance directs. Une personne de LinkedIn a comparé Solr vs ES vs Sensei une fois, mais les résultats initiaux doivent être ignorés car ils ont utilisé une configuration non-expert pour Solr et ES.
  • Conception: Les gens aiment Solr. L'API Java est un peu verbeuse, mais les gens aiment la façon dont elle est assemblée. Le code Solr n'est malheureusement pas toujours très joli. En outre, ES dispose d'une fonction de réplication en temps réel, de document, de routage et de fragmentation. Bien que cela existe aussi chez Solr, c'est un peu après-coup.
  • Support: il existe des sociétés fournissant un support technique et de conseil pour Solr et ElasticSearch. Je pense que la seule société qui fournit un soutien pour les deux est Sematext (divulgation: je suis fondateur de Sematext)
  • Évolutivité: les deux peuvent être mis à l'échelle de très grands groupes. ES est plus facile à mettre à l'échelle que la version Pre-Solr 4.0 de Solr, mais avec Solr 4.0 ce n'est plus le cas.

Pour une couverture plus approfondie du sujet Solr vs ElasticSearch jeter un oeil à http://blog.sematext.com/2012/08/23/solr-vs-elasticsearch-part-1-overview/ . C'est le premier article de la série de posts de Sematext à faire une comparaison directe et neutre entre Solr et ElasticSearch. Divulgation: Je travaille à Sematext.


184
2017-08-26 15:02



Je vois que beaucoup de gens ici ont répondu à cette question ElasticSearch vs Solr en termes de fonctionnalités et fonctionnalités, mais je ne vois pas beaucoup de discussion ici (ou ailleurs) sur la façon dont ils se comparent en termes de performance.

C'est pourquoi j'ai décidé de mener ma propre enquête. J'ai pris un micro-service de source de données hétérogène déjà codé qui utilisait déjà Solr pour la recherche par terme. J'ai désactivé Solr pour ElasticSearch puis j'ai exécuté les deux versions sur AWS avec une application de test de charge déjà codée et j'ai capturé les métriques de performance pour analyse ultérieure.

Voici ce que j'ai trouvé. ElasticSearch avait un débit supérieur de 13% pour l'indexation des documents, mais Solr était dix fois plus rapide. Quand il s'agissait d'interroger des documents, Solr avait cinq fois plus de débit et était cinq fois plus rapide qu'ElasticSearch.


16
2018-02-26 19:15



J'ai travaillé sur la recherche de solr et élastique pour les applications .Net. La différence majeure que j'ai rencontrée est

Recherche élastique:

  • Plus de code et moins de configuration, mais il y a des API à changer mais est toujours un changement de code
  • pour les types complexes, tapez dans les types i.e types imbriqués (n'a pas pu atteindre dans solr)

Solr:

  • moins de code et plus de configuration et donc moins de maintenance
  • pour regrouper les résultats lors de l'interrogation (beaucoup de travail à accomplir en recherche élastique en bref pas de manière droite)

9
2017-09-07 14:35



Depuis la longue histoire d'Apache Solr, je pense que l'une des forces du Solr est son écosystème. Il existe de nombreux plugins Solr pour différents types de données et d'objectifs.

solr stack

Plate-forme de recherche dans les couches suivantes de bas en haut:

  • Les données
    • Objectif: Représenter différents types de données et sources
  • Création de documents
    • Objectif: Créer des informations de document pour l'indexation
  • Indexation et recherche
    • Objectif: créer et interroger un index de document
  • Amélioration de la logique
    • Objectif: Logique supplémentaire pour le traitement des requêtes de recherche et des résultats
  • Service de plateforme de recherche
    • Objectif: Ajouter des fonctionnalités supplémentaires du noyau du moteur de recherche pour fournir une plate-forme de service.
  • Application d'interface utilisateur
    • But: Interface de recherche d'utilisateur final ou applications

Article de référence: Recherche d'entreprise


9
2017-11-11 16:23



Alors que tous les liens ci-dessus ont du mérite, et m'ont beaucoup bénéficié par le passé, en tant que linguiste "exposé" à différents moteurs de recherche Lucene ces 15 dernières années, je dois dire que le développement élastique est très rapide en Python. Cela étant dit, une partie du code me semblait non intuitive. Donc, j'ai tendu la main vers un composant de la pile ELK, Kibana, d'un point de vue open source, et j'ai trouvé que je pouvais très facilement générer le code un peu énigmatique d'elasticsearch dans Kibana. En outre, je pourrais aussi tirer des requêtes Chrome Sense es dans Kibana. Si vous utilisez Kibana pour évaluer es, cela accélérera encore votre évaluation. Ce qui prenait des heures à s'exécuter sur d'autres plates-formes était opérationnel dans JSON in Sense par dessus elasticsearch (interface RESTful) en quelques minutes au pire (les plus gros ensembles de données); en quelques secondes au mieux. La documentation pour elasticsearch, alors que 700+ pages, ne répondait pas aux questions que j'avais normalement dans SOLR ou d'autres documents Lucene, ce qui prenait évidemment plus de temps pour analyser. Aussi, vous pouvez jeter un coup d'oeil à Aggregates dans élastique-search, qui ont pris Faceting à un nouveau niveau.

Image plus grande: si vous faites de la science des données, de l'analyse de texte ou de la linguistique computationnelle, elasticsearch a quelques algorithmes de classement qui semblent bien innover dans le domaine de la récupération de l'information. Si vous utilisez des algorithmes TF / IDF, Frequency Text / Inverse Document Frequency, elasticsearch étend l'algorithme de cet 1960 à un nouveau niveau, même en utilisant BM25, Best Match 25, et d'autres algorithmes de classement de pertinence. Donc, si vous marquez ou classifiez des mots, des phrases ou des phrases, elasticsearch effectue ces notations à la volée, sans les frais généraux importants d'autres approches d'analyse de données qui prennent des heures - un autre gain de temps élastique. Avec es, en combinant certaines des forces de seau des agrégations avec la notation et le classement de pertinence des données JSON en temps réel, vous pouvez trouver une combinaison gagnante, selon votre approche agile (histoires) ou architecturales (cas d'utilisation).

Note: J'ai vu une discussion similaire sur les agrégations ci-dessus, mais pas sur les agrégations et la notation de pertinence - mes excuses pour tout chevauchement. Divulgation: Je ne travaille pas pour élastique et je ne pourrai pas bénéficier dans un proche avenir de leur excellent travail en raison d'un parcours architectural différent, à moins que je ne fasse un travail de charité avec elasticsearch, ce qui ne serait pas une mauvaise idée


6
2018-02-03 00:04



J'ai créé un tableau des principales différences entre elasticsearch et Solr et splunk, vous pouvez l'utiliser comme mise à jour 2016: enter image description here


6
2018-05-03 21:51