Solr vs. ElasticSearch [fermé]

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

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

Mise à jour

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

Il existe de nombreuses comparaisons entre Apache Solr et ElasticSearch , je vais donc faire référence à celles que j'ai trouvées les plus utiles, c'est-à-dire couvrir les aspects les plus importants:

• Bob Yoplait a déjà lié la réponse de Kimchy à ElasticSearch, Sphinx, Lucene, Solr, Xapian. Qui convient à 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 par rapport à Solr.

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

  Solr peut être l'arme de choix lors de la création d' applications de recherche standard , mais Elasticsearch le porte au niveau supérieur avec une architecture pour créer des applications de recherche en temps réel modernes . La percolation est une fonctionnalité passionnante et innovante qui souffle à elle seule Solr hors de l'eau. Elasticsearch est évolutif, rapide et un rêve à intégrer . Adios Solr, c'était sympa de te connaître. [c'est moi qui souligne]

• L'article de Wikipédia sur ElasticSearch cite une comparaison du célèbre magazine allemand iX, énumérant les avantages et les inconvénients, qui résument à peu près ce qui a déjà été dit ci-dessus:

  Avantages :

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

  Inconvénients :

  • Un seul développeur principal [ne s'applique plus selon l' organisation elasticsearch GitHub actuelle , en plus d'avoir une base de committers assez active en premier lieu]
  • Pas de fonction de réchauffage automatique [ne s'applique plus selon la nouvelle API Index Warmup ]

Réponse initiale

Ce sont des technologies complètement différentes s'adressant à des cas d'utilisation complètement différents, donc ne peuvent pas du tout être comparées de manière significative:

• Apache Solr - Apache Solr offre les capacités de Lucene dans un serveur de recherche rapide et facile à utiliser 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 la mise à l'échelle d'un cache en mémoire dans le cloud.

  • Veuillez noter qu'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).

[c'est moi qui souligne]

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

• ElasticSearch - Il s'agit d'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.

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

Alors que Solr est plus ancien, assez polyvalent et mature et largement utilisé en conséquence, ElasticSearch a été développé spécifiquement pour répondre aux lacunes de Solr avec des exigences d'évolutivité dans les environnements cloud modernes, qui sont plus difficiles à traiter avec Solr .

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

Je vois que certaines des réponses ci-dessus sont maintenant un peu dépassées. 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 n'ai / nous n'avons pas fait de benchmark direct de performance. Une personne sur 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 experte pour Solr et ES.
• Conception: Les gens aiment Solr. L'API Java est quelque 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. De plus, ES intègre le partitionnement, la réplication en temps réel, le document et le routage. Bien que cela existe également dans Solr, cela ressemble un peu à une réflexion 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 entreprise qui fournit un support pour les deux est Sematext (divulgation: je suis le fondateur de Sematext)
• Évolutivité: les deux peuvent être adaptés à de très grands clusters. ES est plus facile à mettre à l'échelle que la version antérieure à 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, consultez https://sematext.com/blog/solr-vs-elasticsearch-part-1-overview/ . Il s'agit du premier article de la série d'articles de Sematext faisant une comparaison directe et neutre entre Solr et ElasticSearch. Divulgation: Je travaille chez Sematext.

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

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 de termes. 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 capturé les mesures de performances pour une analyse ultérieure.

Voici ce que j'ai trouvé. ElasticSearch avait un débit 13% plus élevé en ce qui concerne l'indexation des documents, mais Solr était dix fois plus rapide. En ce qui concerne l'interrogation de documents, Solr avait un débit cinq fois plus élevé et cinq fois plus rapide qu'ElasticSearch.

Depuis la longue histoire d'Apache Solr, je pense qu'une force du Solr est son écosystème . Il existe de nombreux plugins Solr pour différents types de données et à des fins différentes.

Plateforme de recherche dans les couches suivantes de bas en haut:

• Les données
  • Objectif: représenter divers types de données et sources
• Création de documents
  • Objectif: créer des informations sur le 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 et des résultats de recherche
• Service de plateforme de recherche
  • Objectif: Ajouter des fonctionnalités supplémentaires du moteur de recherche pour fournir une plate-forme de service.
• Application d'interface utilisateur
  • Objectif: interface ou applications de recherche d'utilisateur final

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

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

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

Recherche élastique:

• Plus de code et moins de configuration, mais il y a des API à changer mais il y a toujours un changement de code
• pour les types complexes, tapez dans les types, c'est-à-dire les types imbriqués (impossible à réaliser dans solr)

Solr:

• moins de code et plus de configuration et donc moins de maintenance
• pour regrouper les résultats pendant l'interrogation (beaucoup de travail à réaliser dans la recherche élastique en bref pas de manière directe)

Bien que tous les liens ci-dessus aient du mérite, et m'ont grandement profité dans le passé, en tant que linguiste "exposé" à divers moteurs de recherche Lucene au cours des 15 dernières années, je dois dire que le développement de la recherche élastique est très rapide en Python. Cela étant dit, une partie du code ne me semblait pas intuitive. J'ai donc tendu la main à un composant de la pile ELK, Kibana, dans une perspective open source, et j'ai découvert que je pouvais générer très facilement le code quelque peu cryptique d'elasticsearch dans Kibana. De plus, je pouvais également insérer des requêtes de Chrome Sense dans Kibana. Si vous utilisez Kibana pour évaluer es, cela accélérera encore votre évaluation. Ce qui a pris des heures à s'exécuter sur d'autres plates-formes était opérationnel dans JSON in Sense au-dessus d'elasticsearch (interface RESTful) en quelques minutes au pire (plus grands ensembles de données); en quelques secondes au mieux. La documentation pour elasticsearch, alors que plus de 700 pages, ne répondait pas aux questions que j'avais normalement qui seraient résolues dans SOLR ou dans une autre documentation Lucene, ce qui a évidemment pris plus de temps à analyser. En outre, vous voudrez peut-être jeter un œil aux agrégats dans la recherche élastique, qui ont fait passer la facettage à un nouveau niveau.

Vue d'ensemble: si vous faites de la science des données, de l'analyse de texte ou de la linguistique informatique, elasticsearch possède des algorithmes de classement qui semblent bien innover dans le domaine de la recherche d'informations. Si vous utilisez des algorithmes TF / IDF, Text Frequency / Inverse Document Frequency, elasticsearch étend cet algorithme des années 1960 à un nouveau niveau, même en utilisant BM25, Best Match 25 et d'autres algorithmes de classement de pertinence. Donc, si vous notez ou classez des mots, des phrases ou des phrases, elasticsearch effectue cette notation à la volée, sans les frais généraux des autres approches d'analyse de données qui prennent des heures - un autre gain de temps elasticsearch. Avec es, en combinant certaines des forces du regroupement des agrégations avec le score et le classement en temps réel de la pertinence des données JSON, vous pouvez trouver une combinaison gagnante,

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

Imaginez le cas d'utilisation:

1. Un grand nombre (100+) de petits index de recherche (10 Mo-100 Mo, 1000-100 000 documents).
2. Ils utilisent par beaucoup d'applications (microservices)
3. Chaque application peut utiliser plusieurs index
4. Petit par indice de taille, oui. Mais une charge énorme (des centaines de requêtes de recherche par seconde) et les requêtes sont complexes (agrégations multiples, conditions, etc.)
5. Les temps d'arrêt ne sont pas autorisés
6. Tout cela dure des années et ne cesse de croître.

L'idée d'avoir une instance ES individuelle pour chaque index est un énorme surcoût dans ce cas.

D'après mon expérience, ce type de cas d'utilisation est très complexe à prendre en charge avec Elasticsearch.

Pourquoi?

PREMIÈRE.

Le problème majeur est le non-respect fondamental de la rétrocompatibilité.

Les changements de rupture sont tellement cool! (Remarque: imaginez un serveur SQL qui vous oblige à faire de petits changements dans toutes vos instructions SQL, lors de la mise à niveau ... ne peut pas l'imaginer. Mais pour ES, c'est normal)

Les dépréciations qui seront supprimées dans la prochaine version majeure sont tellement sexy! (Remarque: vous savez, Java contient des dépréciations, qui ont plus de 20 ans, mais qui fonctionnent toujours dans la version Java actuelle ...)

Et non seulement cela, parfois vous avez même quelque chose qui n'est documenté nulle part (personnellement rencontré une seule fois mais ...)

Donc. Si vous souhaitez mettre à niveau ES (parce que vous avez besoin de nouvelles fonctionnalités pour une application ou que vous souhaitez obtenir des corrections de bogues) - vous êtes en enfer. Surtout s'il s'agit d'une mise à niveau de version majeure.

L'API client ne sera pas compatible en arrière. Les paramètres d'index ne seront pas compatibles. Et mettre à niveau toutes les applications / services au même moment avec la mise à niveau ES n'est pas réaliste.

Mais vous devez le faire de temps en temps. Pas d'autre chemin.

Les index existants sont automatiquement mis à niveau? - Oui. Mais cela ne vous aide pas lorsque vous devrez modifier certains paramètres de l'ancien index.

Pour vivre avec cela, vous devez constamment investir beaucoup de puissance dans la compatibilité ascendante de vos applications / services avec les futures versions d'ES. Ou vous devez créer (et de toute façon constamment prendre en charge) une sorte de middleware entre votre application / services et ES, qui vous fournissent une API client compatible. (Et, vous ne pouvez pas utiliser Transport Client (car cela nécessitait une mise à niveau du bocal pour chaque mise à niveau ES de version mineure), et ce fait ne vous facilite pas la vie)

Est-il simple et bon marché? Non ce n'est pas. Loin de là. La maintenance continue d'une infrastructure complexe basée sur ES est un moyen trop coûteux dans tous les sens du terme.

SECONDE. API simple? Eh bien ... non vraiment. Lorsque vous utilisez vraiment des conditions et des agrégations complexes ... La requête JSON avec 5 niveaux imbriqués est tout, mais pas simple.

Malheureusement, je n'ai aucune expérience avec SOLR, je ne peux rien en dire.

Mais Sphinxsearch est beaucoup mieux dans ce scénario, en raison de SphinxQL totalement compatible.

Remarque: Sphinxsearch / Manticore sont en effet intéressants. Ce n'est pas basé sur Lucine, et donc très différent. Contient plusieurs fonctionnalités uniques de la boîte que ES n'a pas et très rapidement avec des index de petite / moyenne taille.

Si vous utilisez déjà SOLR, restez-y. Si vous démarrez, optez pour la recherche élastique.

Le maximum de problèmes majeurs a été corrigé dans SOLR et il est assez mature.

J'utilise Elasticsearch depuis 3 ans et Solr depuis environ un mois, je pense que le cluster elasticsearch est assez facile à installer par rapport à l'installation de Solr. Elasticsearch a un pool de documents d'aide avec de grandes explications. L'un des cas d'utilisation, j'ai été coincé avec l'agrégation d'histogramme qui était disponible dans ES mais ne se trouve pas dans Solr.

J'utilise uniquement Elastic-search. Depuis que j'ai trouvé que solr est très difficile à démarrer. Fonctionnalités d'Elastic-Search:

1. Facile à démarrer, très peu de réglages. Même un débutant peut configurer un cluster étape par étape.
2. API Restful simple qui utilise une requête NoSQL. Et de nombreuses bibliothèques de langues pour un accès facile.
3. Bon document, vous pouvez lire le livre:. Il existe une version web sur le site officiel.

Ajoutez un document imbriqué dans solr très complexe et la recherche de données imbriquées est également très complexe. mais Elastic Search permet d'ajouter facilement des documents imbriqués et de rechercher