Solr vs ElasticSearch
Quelles sont les différences architecturales fondamentales entre ces technologies?
En outre, 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 ajouter quelque chose à cet égard également:
Il existe de nombreuses comparaisons entre Apache Solr et ElasticSearch , je vais donc citer ceux que je trouve les plus utiles moi-même, c'est-à-dire couvrant les aspects les plus importants:
Bob Yoplait a déjà associé la réponse de kimchy à ElasticSearch, Sphinx, Lucene, Solr, Xapian. Quel choix pour quel usage? , qui résume les raisons pour lesquelles il a créé ElasticSearch , qui à son avis fournit un modèle distribué bien supérieur et une facilité d'utilisation par rapport à Solr.
Ryan Sonnek Realtime Search: Solr vs Elasticsearch fournit une analyse/comparaison perspicace et explique pourquoi il est passé de Solr à ElasticSeach, alors qu'il était 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 passe au niveau supérieur avec une architecture permettant de créer des applications de recherche modernes en temps réel . La percolation est une fonctionnalité excitante et innovante qui propulse Solr hors de l'eau. Elasticsearch est évolutif, rapide et constitue un rêve à intégrer avec . Adios Solr, c'était bien de te connaître. [emphase mienne]
L'article de Wikipedia sur ElasticSearch cite un comparaison du célèbre magazine allemand iX, qui répertorie les avantages et les inconvénients, qui résume assez bien ce qui a déjà été dit ci-dessus:
Avantages :
- ElasticSearch est distribué. Aucun projet séparé requis. Les répliques sont également quasiment en temps réel, ce qui s'appelle "réplication Push".
- ElasticSearch prend entièrement en charge la recherche en temps quasi réel d'Apache Lucene.
- La gestion de la multitenancy 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, qui facilite les sauvegardes complètes.
Inconvénients :
Un seul développeur principal[n'est plus applicable selon l'actuel organisation elasticsearch GitHub , en plus d'avoir une base de committer assez active en premier lieu]Aucune fonctionnalité d'autoarming[ne s'applique plus selon le nouveau API Index Warmup ]
Réponse initiale
Ce sont des technologies complètement différentes qui traitent des cas d'utilisation complètement différents. Il est donc impossible de les comparer de manière significative:
Apache Solr - Apache Solr offre les capacités de Lucene sur un serveur de recherche facile à utiliser et rapide avec fonctionnalités supplémentaires telles que facettage, évolutivité et bien plus encore
Amazon ElastiCache - Amazon ElastiCache est un service Web facilitant le déploiement, l'exploitation et la mise à l'échelle d'un cache en mémoire dans le cloud.
- Notez que , Amazon ElastiCache est conforme au protocole avec Memcached, un système largement utilisé de mise en cache des objets mémoire. Ainsi, le code, les applications et les outils courants utilisés avec les environnements Memcached existants fonctionneront de manière transparente avec le service (voir Memcached pour plus de détails).
[emphase mienne]
Peut-être cela a-t-il été confondu avec les deux technologies liées suivantes d'une manière ou d'une autre:
ElasticSearch - C’est un Open Source (Apache 2), Distribué, RESTful, Moteur de recherche 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 une fonctionnalité de recherche rapide et hautement évolutive à leurs applications.
Les offres Solr et ElasticSearch semblent étonnamment similaires au premier abord et utilisent le même moteur de recherche principal, à savoir Apache Lucene .
Alors que Solr est plus ancien, assez polyvalent, mature et largement utilisé en conséquence, ElasticSearch a été développé spécifiquement pour traiter Solr insuffisances en matière d’évolutivité dans les environnements cloud modernes, qu'il est plus difficile de résoudre avec Solr .
En tant que tel, il serait probablement plus utile de comparer ElasticSearch avec l’introduction récente Amazon CloudSearch (voir le post d’introduction Commencez la recherche en une heure pour moins de 100 €/mois ), car les deux prétendent couvrir les mêmes cas d'utilisation.
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 importante et plus mature. ES a une communauté d'utilisateurs plus petite mais active et une communauté grandissante de contributeurs
- Maturité: Solr est plus mature, mais ES a connu une croissance rapide et je la considère stable
- Performance: difficile à juger. Je/nous n’avons pas fait d’indices de performance directs. Une personne de LinkedIn a déjà comparé Solr, ES et Sensei, mais les résultats initiaux doivent être ignorés, car ils utilisaient une configuration non-expert pour Solr et ES.
- Design: Les gens aiment Solr. L'API Java est quelque peu prolixe, mais les gens aiment sa mise en place. Le code Solr n'est malheureusement pas toujours très joli. En outre, ES intègre la fragmentation, la réplication en temps réel, le document et le routage. Même si une partie de cela existe aussi chez Solr, cela ressemble un peu à une pensée après coup.
- Support: il existe des sociétés fournissant un support technique et de conseil à la fois 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)
- Evolutivité: les deux peuvent être dimensionnés en très grands groupes. ES est plus facile à mettre à l'échelle que la version de Solr antérieure à Solr 4.0, mais avec Solr 4.0, ce n'est plus le cas.
Pour une couverture plus complète du sujet Solr vs. ElasticSearch, consultez https://sematext.com/blog/solr-vs-elasticsearch-part-1-overview/ . Ceci est le premier billet de la série de billets 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 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 terme. J'ai remplacé 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 métriques de performance pour une analyse ultérieure.
Voici ce que j'ai trouvé. ElasticSearch avait un débit supérieur de 13% en ce qui concerne l’indexation des documents, mais Solr était dix fois plus rapide. En ce qui concerne la recherche de documents, Solr avait un débit cinq fois supérieur et cinq fois plus rapide qu'ElasticSearch.
Depuis la longue histoire d'Apache Solr, je pense qu'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.
Plateforme de recherche dans les couches suivantes de bas en haut:
- Les données
- But: 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 de recherche et des résultats
- Service de plate-forme de recherche
- Objectif: Ajouter des fonctionnalités supplémentaires au cœur du moteur de recherche afin de fournir une plate-forme de service.
- Demande 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 différences majeures entre elasticsearch et Solr et splunk, vous pouvez l'utiliser comme mise à jour 2016: 
Je travaille sur les recherches solr et élastiques pour les applications .Net. La principale différence à laquelle je suis confronté est
Recherche élastique:
- Plus de code et moins de configuration, mais il y a des API à changer mais il reste un changement de code
- pour les types complexes, tapez dans les types i.e types imbriqués (impossible à obtenir 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 à effectuer en recherche élastique, bref pas de chemin droit)
Alors que tous les liens ci-dessus ont du mérite et m'ont grandement profité dans le passé, en tant que linguiste "exposé" à divers moteurs de recherche Lucene depuis 15 ans, je dois dire que le développement de la recherche élastique est très rapide en Python. Cela étant dit, certains codes ne me semblaient pas intuitifs. Je me suis donc tourné vers un composant de la pile ELK, Kibana, d’un point de vue open source, et j’ai constaté que je pouvais générer très facilement le code quelque peu cryptique de elasticsearch dans Kibana. De plus, je pouvais aussi extraire Chrome Sense es requêtes dans Kibana. Si vous utilisez Kibana pour évaluer, cela accélérera encore votre évaluation. Ce qui prenait des heures à fonctionner sur d'autres plates-formes, c'était de faire fonctionner JSON in Sense en plus de elasticsearch (interface RESTful) en quelques minutes au pire (ensembles de données les plus volumineux); en quelques secondes au mieux. La documentation d'elasticsearch, bien que plus de 700 pages, ne répondait pas aux questions que je devais résoudre normalement dans SOLR ou une autre documentation de Lucene, qui a évidemment pris plus de temps à analyser. Vous pouvez également vous intéresser aux agrégats dans la recherche élastique, qui ont propulsé 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 informatique, elasticsearch dispose de certains algorithmes de classement qui semblent bien innover dans le domaine de la récupération d'informations. Si vous utilisez un algorithme TF/IDF, fréquence de texte/fréquence de document inverse, 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 par pertinence. Ainsi, si vous marquez ou classez des mots, des phrases ou des phrases, elasticsearch effectue cette notation à la volée, sans les frais généraux liés aux autres approches d'analyse de données qui prennent des heures - une autre économie de temps. Avec es, en combinant les avantages du regroupement d'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 architecturale (cas d'utilisation).
Remarque: nous avons assisté à une discussion similaire sur les agrégations ci-dessus, mais pas sur les agrégations et la notation de pertinence - toutes mes excuses pour tout chevauchement Divulgation: Je ne travaille pas pour élastique et ne pourrai pas bénéficier dans un proche avenir de leur excellent travail dû à un parcours architectural différent, sauf si je fais un travail de charité avec elasticsearch, ce qui ne serait pas une mauvaise idée.
Imaginez le cas d'utilisation:
- Beaucoup (100+) de petits index de recherche (10Mo-100Mo, 1000-100000 documents).
- Ils utilisent beaucoup d'applications (microservices)
- Chaque application peut utiliser plusieurs index.
- Petit indice de taille, oui. Mais la charge énorme (centaines de requêtes de recherche par seconde) et les requêtes sont complexes (agrégations multiples, conditions, etc.)
- Les temps d'arrêt ne sont pas autorisés
- 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 une lourde charge 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 compatibilité avec le dos.
Les changements radicaux sont tellement cool! (Remarque: imaginez le serveur SQL qui vous oblige à faire de petites modifications dans toutes vos instructions SQL, lors de la mise à niveau ... impossible de l'imaginer. Mais pour ES c'est normal)
Les déprécations qui tomberont dans la prochaine version majeure sont tellement sexy! (Remarque: vous savez, Java contient des dépréciations datant de plus de 20 ans, mais fonctionnant toujours dans la version Java actuelle ...)
Et non seulement cela, parfois vous avez même quelque chose qui nulle part documenté (personnellement rencontré seulement une fois mais ...)
Alors. Si vous souhaitez mettre à niveau ES (car vous avez besoin de nouvelles fonctionnalités pour certaines applications ou si vous souhaitez obtenir des corrections de bugs), vous êtes en enfer. Surtout s'il s'agit d'une mise à niveau majeure.
L'API client ne reconnaît pas la compatibilité. 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 à jour? - Oui. Mais cela ne vous aidera pas lorsque vous devrez modifier certains paramètres d’ancien index.
Pour vivre avec cela, vous devez constamment investir beaucoup d'énergie dans ... la compatibilité ascendante de vos applications/services avec les futures versions de ES. Ou vous avez besoin de construire (et de toute façon, de supporter en permanence) un type de middleware entre votre application/services et ES, qui vous fournit en retour une API client compatible. (Et, vous ne pouvez pas utiliser le client de transport (car il nécessitait une mise à niveau de jar pour chaque mise à niveau de version mineure ES), et cela ne vous simplifie pas la vie.)
Est-ce que ça a l'air simple et pas cher? Non ce n'est pas. Loin de là. La maintenance continue des infrastructures complexes qui, sur la base des ES, coûte cher dans tous les sens du terme.
SECONDE. API simple? Eh bien ... non vraiment. Lorsque vous utilisez réellement des conditions et des agrégations complexes ... La demande JSON avec 5 niveaux imbriqués est tout ce qui existe, mais pas simple.
Malheureusement, je n'ai aucune expérience avec SOLR, je ne peux rien en dire.
Mais Sphinxsearch est bien meilleur dans ce scénario, car il est totalement compatible avec SphinxQL.
Note: Sphinxsearch/Manticore sont vraiment intéressants. Ce n'est pas basé sur Lucine, et par conséquent sérieusement différent. Contient plusieurs fonctionnalités uniques de la boîte que les ES n’ont pas et rapides avec des index de petite/moyenne taille.
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 dispose d'un pool de documents d'aide très explicites. L'un des cas d'utilisation où je me trouvais coincé avec l'histogramme d'agrégation qui était disponible dans ES mais n'a pas été trouvé dans Solr.
Si vous utilisez déjà SOLR, restez-y. Si vous commencez, optez pour Elastic search.
Le nombre maximal de problèmes majeurs a été résolu dans SOLR et il est assez avancé.
Je n'utilise que Elastic-search. Depuis que j'ai trouvé solr est très difficile à démarrer. Caractéristiques de Elastic-search:
- Facile à démarrer, très peu de réglage. Même un débutant peut configurer un cluster étape par étape.
- API simple reposante utilisant une requête NoSQL. Et de nombreuses bibliothèques de langues pour un accès facile.
- Bon document, vous pouvez lire le livre:. Il existe une version Web sur le site officiel.
Ajouter un document imbriqué dans la recherche de données très complexe et très imbriquée également très complexe. mais Elastic Search facile d'ajouter des documents imbriqués et de rechercher