Veille et meilleures pratiques

Solr et Elastic Search dans un contexte de mise à l'échelle

Bond, S. Solr et Elastic Search dans un contexte de mise à l'échelle. Montréal, CRIM, 2012. 8 p.
[Texte complet]

Mise en contexte

Ce document présente un aperçu de deux moteurs de recherche basés sur Lucene : Solr et Elastic Search. L’objectif est de présenter les différences entre les deux projets et d’identifier la technologie la plus appropriée dans un contexte de mise à l’échelle. Il sera question de Lucene, de son intégration dans les moteurs de recherche, des techniques employées pour la mise à l’échelle d’u n engin de recherche et des caractéristiques propres à chacune des technologies étudiées.  
 

Lucene

Le moteur d’indexation et de recherche ouvert le plus répandu est Lucene [1 Web sites using Lucene] [5 Lucene in Action]. Il s’agit d’u ne librairie Java pouvant être intégrée dans d’autres applications pour y ajouter des fonctions de recherche plein-texte personnalisées. On y retrouve des fonctions couvrant le classement des résultats par pertinence, l’analyse de phrase, les caractères joker, la recherche par champ, la lemmatisation, les requêtes complexes, etc. [6 Lucene official site].

La librairie est toutefois livrée sans transformateur de contenu, interface utilisateur, gestionnaire de permissions ou mécanisme de distribution des index. Il laisse le soin au programmeur de développer, connecter et configurer tous les composants requis pour offrir une fonctionnalité de recherche à son application.

C’est ce qui a été fait dans une multitude d’applications dans des domaines variés, comme les CMS, la gestion documentaire, les portails Web, etc. La librairie est intégrée dans des produits comme Liferay, Alfresco, Nuxeo, Hadoop, OpenCMS, eXo Platform, xWiki, IBM Enterprise Search, Documentum, JIRA et plusieurs autres. Des sites Web, comme eBay, Amazon, AOL, eHarmony ou Macy’s se sont aussi basés sur Lucene pour leurs fonctionnalités de recherche [1].
 

Moteurs de recherche autonome

Au lieu d’intégrer directement Lucene à son application ou son site Web, il est possible de passer par une application dédiée à la recherche, intégrant la librairie préconfigurée. Notons, entre autres, Solr, Nutch ou Elastic Search qui entre dans cette catégorie. De telles distributions sont livrées avec leurs propres fonctionnalités, comme la recherche par facettes, la gestion des synonymes, des analyseurs de requêtes complexes, des filtres, des fonctions mathématiques pour le calcul de pertinence, etc. Elles ont aussi leurs propres mécanismes de connecteurs pour y ajouter des fonctionnalités diverses et gérer leur configuration.

Ces « moteurs de recherche » offrent leurs propres API, souvent sous forme de services. Avec une couche REST ou SOAP, on peut alors utiliser d’autres langages que Java pour le développement des interfaces de recherche et l’indexation des documents.

Ce sont ces applications qui ajoutent aussi des outils avancés pour la mise à l’échelle et la distribution des index sur plusieurs serveurs.
 

Mise à l'échelle d'un moteur de recherche 

On peut demander un déploiement distribué (ou mise à l’échelle) d’un moteur de recherche pour diverses raisons :
  • Support d’un très grand nombre de requêtes en simultané. 
  • Très gros volume de données à conserver (plusieurs dizaines de GB). 
  • Indexation rapide ou instantanée (pour temps réel). 
  • Réplication des données sur plusieurs serveurs. 
  • Haute disponibilité (minimiser l’impact de la perte d’un serveur).
Un déploiement distribué implique l’utilisation de plusieurs serveurs qu’on désigne comme « nœuds ». Pour un nombre de requêtes important, une telle architecture permettra de répartir les requêtes sur plusieurs machines qui effectueront l’analyse de la requête, interrogeront l’index et classeront les résultats en parallèle.

Si le volume de données est important, le partitionnement de l’index Lucene en plusieurs morceaux (nommés « shards ») stockés sur plusieurs nœuds permet d’augmenter la performance de manière significative. Cette technique réduit la taille de chaque index pouvant bénéficier d’une mise en cache optimale en mémoire RAM et d’une récupération plus rapide de l’information. Des fonctions présentes dans Lucene permettent aussi de regrouper les résultats provenant de plusieurs sources et d’offrir ainsi un classement normalisé des résultats à l’utilisateur.

Le partitionnement de l’index sur plusieurs nœuds augmente aussi la vitesse d’indexation puisque des serveurs différents peuvent être impliqués pour indexer des documents distincts. Par exemple, si le document X est placé dans l’index A et le document Y dans l’index B, les deux pourront être traités en simultané de manière totalement indépendante. Ce volet dépend des règles de partitionnement mises en place. Il est possible de diviser l’index par type de document, par utilisateur, par champs de recherche ou même en fonction de l’identifiant unique du document (assurant une répartition plus égale entre les nœuds) [8 Scaling Lucene and Solr].

Finalement, un déploiement distribué permet une meilleure tolérance aux fautes, évitant les interruptions ou la perte de données causées par le mauvais fonctionnement de l’un des serveurs. Certaines installations distribuées peuvent assurer qu’une réplication sur plusieurs emplacements physiques soit effectuée de manière automatique, offrant ainsi un mécanise de sauvegarde robuste. La reprise en cas de panne sur un serveur peut aussi être automatisée lorsqu’un serveur redevient disponible. [7 Elasticsearch official site]
 

Moteurs de recherche avec fonctions de mise à l'échelle

Solr et Elastic Search sont deux moteurs de recherche autonomes pouvant être exploités à l’aide de services REST depuis une application externe. Nous comparerons ici les fonctionnalités qu’ils offrent, plus particulièrement dans un contexte distribué pour une mise à l’échelle.
 

Elastic Search

Elastic Search a été conçu initialement comme un moteur de recherche distribué. Il gère automatiquement le découpage de l’index en « shards » répliqués sur plusieurs serveurs (ou nœuds). Il est possible de bénéficier de haute disponibilité avec un minimum de configuration. Un serveur responsable d’un « shard » est chargé d’en pousser les nouvelles informations sur les répliques, assurant ainsi une mise à jour pratiquement en temps réel. Lors de la réception d’une requête, un nœud produira des sous-requêtes à exécuter sur chacun des « shards » concernés, pour agréger par la suite les résultats obtenus dans un processus s’apparentant au « map / reduce » [3 The Future of Compass & ElasticSearch]. La solution est aussi livrée avec son propre mécanisme de surveillance des serveurs, permettant de détecter qu’u n nœud n’est plus disponible. On peut aussi répliquer l’index vers un emplacement externe « gateway » qui ne sera pas impliqué dans l’exécution des requêtes, mais qui pourra être utilisé pour restaurer un environnement en cas de panne [7].

Parmi les caractéristiques du projet, notons la possibilité d’exécuter des scripts (MVEL, JavaScript, Python et autres) sur les serveurs de recherche afin de calculer le contenu d’un champ ou la pertinence d’un document. Tout le contenu indexé est lu et écrit en format JSON via les API REST ou Java. Il n’impose aucun schéma ou structure particulière sur le contenu et effectue une détection des types de données. Elastic Search implémente aussi la recherche par Facette, le surlignage des résultats et la recherche géo spatiale. Une fonctionnalité qui lui est propre est le « Percolator » qui permet d’enregistrer des requêtes pour être ensuite notifié d’un changement aux résultats. Cela permet, par exemple, de reproduire le comportement des « Twitter Live Stream » [2 Widget de recherché Twitter] où les résultats sont actualisés en temps réel lorsque de nouveaux commentaires s’ajoutent.
 

Solr

L’objectif premier de Solr est d’offrir un moteur de recherche d’entreprise, recueillant des données provenant de plusieurs sources et permettant la recherche depuis un site Web ou un intranet. Il ajoute à Lucene la navigation par facettes, le surlignage de liens, l’utilisation des synonymes, la complétion semi-automatique, un correcteur d’orthographe basé sur l’index, des fonctions de calcul de pertinence, les transactions, un traitement des requêtes personnalisé via une configuration XML, des API (REST, Ruby, Java, etc.) pour l’indexation et la recherche, ainsi que des gabarits pour le formatage des résultats. Des connecteurs permettent l’indexation de plusieurs formats (MS Office, OpenOffice, PDF, RTF, etc.) ainsi que le contenu de bases de données. Un schéma est requis mais ce dernier peut comporter des champs dynamiques.

Le projet Solr comporte une communauté très active et du support commercial de la part d’e ntreprises telles que Lucid Imagination et Constellio). Il est un projet Apache depuis 2006 et son équipe de développement a été fusionnée à celle de Lucene en 2010.  Solr est paramétré pour offrir des performances très élevées grâce à une mise en cache intelligente (auto-warming) et à la distribution des recherches sur plusieurs serveurs. Par contre, le déploiement en mode distribué n’est pas automatique et n’incorpore pas toutes les fonctionnalités. L’administrateur doit lui-même diviser l’index en « shards » et décider du rôle de chacun des serveurs. Les requêtes dans un mode distribué doivent spécifier dans quels « shards » rechercher et l’agrégation des résultats doit passer par un algorithme d’approximation (la comparaison n’étant pas effectuée sur une base uniforme).
 

Comparaison et conclusion

En termes de maturité du projet, de la quantité d’utilisateurs, de la taille de la communauté de développement, du support commercial et de la quantité de fonctionnalités, Solr se démarque d’E lastic Search. Les équipes de développement de Lucene et de Solr étant maintenant intégrées, les besoins de ce dernier influencent le développement du cœur de Lucene qui est modifié pour répondre à des exigences de performances et d’analyse de requêtes avancées. Le support des transactions, présent dans Solr, constitue un atout lorsque des données affectant plusieurs documents doivent être enregistrées ou pour s’assurer de l’intégrité d’un processus de mise à jour. Le tout répond bien aux besoins des applications de recherche d’entreprise.

Du côté d’Elastic Search, on retrouve une communauté réduite mais très dynamique, qui se compose d’un développeur principal et de quelques contributeurs. À l’heure actuelle, aucune entreprise n’o ffre de distribution commerciale. Son point fort est la facilité avec laquelle il est possible de déployer une grappe de serveurs pour gérer un index distribué de très grande taille. C’est à ce niveau qu’il a fait sa marque et plusieurs développeurs ayant essayé de déployer une telle infrastructure sous Solr ont finalement adopté Elastic Search, créant un véritable engouement autour du projet.

Lorsqu’exécuté sur un index de taille raisonnable (< 1M de documents), Solr offre des performances supérieures à Elastic Search. C’est toutefois le contraire qui se produit avec une taille d’index plus importante ou lorsqu’un très grand volume de données est indexé en temps réel. Le tout est dû au fait que le traitement est distribué sur des index plus petits, hébergés sur plusieurs serveurs. Si 100 nouveaux documents sont ajoutés en même temps, ceux-ci peuvent être répartis sur 10 « shards » différents effectuant le traitement en parallèle. L’absence de transactions réduit aussi le temps de traitement pour l’ajout de documents.

Une répartition de la charge et une distribution de l’index peuvent aussi être réalisées avec Solr, mais le tout exige beaucoup de configuration et la mise en place de règles définies manuellement. Le projet SolrCloud 4.0 vise à répondre à ce problème en offrant des fonctions pour le découpage automatique de l’index en plusieurs « shards ». La gestion de la grappe de serveurs et de sa configuration ne sont toutefois pas incorporées dans le produit, mais reposent plutôt sur le produit Apache ZooKeeper. À l’heure actuelle, cette solution n’est pas encore comparable à Elastic Search en termes de convivialité et de facilité de déploiement.

En somme, Elastic Search représente, à l’heure actuelle, la meilleure solution pour l’indexation temps réel, les notifications en temps réel (fonction « Percolator ») et pour la simplicité de déploiement lorsqu’on est en présence d’un index de très grande taille en mode distribué. Du côté de Solr, il représente un choix sûr pour l’ajout de fonctions de recherche avancées à tout genre d’a pplication. Il peut être répliqué pour répartir la charge sur plusieurs serveurs et offre des performances supérieures dans le contexte d’une utilisation conventionnelle (beaucoup plus de lecture que d’écriture et une taille d’index de moins de 1M de documents).

Étant donné l’intégration des projets Solr et Lucene, il est à prévoir que les fonctionnalités avancées de Solr soient de plus en plus intégrées au noyau de Lucene, ce qui permettra à d’autres solutions, comme Elastic Search, d’en profiter. Solr continu aussi son évolution et des composants comme SolrCloud, pourraient éventuellement leur permettre de rattraper Elastic Search pour une utilisation dans un contexte distribué.
 

Références

[1] Web sites using Lucene (http://wiki.apache.org/jakarta-lucene/PoweredBy).
[2] Widget de recherche Twitter (http://twitter.com/about/resources/widgets/widget_search).
[3] The Future of Compass & ElasticSearch (http://www.kimchy.org/the_future_of_compass/).
[4] Realtime Search: Solr vs Elasticsearch (http://engineering.socialcast.com/2011/05/realtime-search-solr-vs-elasticsearch/).
[5] Lucene in Action (http://www.manning.com/hatcher2/).
[6] Lucene official site (http://lucene.apache.org/core/).
[7] Elasticsearch official site (http://www.elasticsearch.org/).
[8] Scaling Lucene and Solr (http://www.lucidimagination.com/content/scaling-lucene-and-solr).