Recherche Open Source avec Lucene & Solr

Lucene - Solr

Si vous avez déjà eu besoin de rajouter des fonctionnalités d’indexation ou de recherche full-text à l’un de vos projets, il se peut que vous connaissiez déjà Apache Lucene ou l’un de ses nombreux dérivés, par exemple PyLucene, Lucene.NET, Ferret (Ruby), ou Lucy (C port). Lucene, qui date du début des années 2000, est devenu l’une des librairies pour la récupération de données les plus complètes et riches en fonctionnalités et sert de support très largement pour des douzaines de tokenizers, analyseurs, parseurs de requêtes et algorithmes de scoring.

Lors de ma participation récente à la conférence Lucene Revolution à Boston, il m’était évident grâce aux présentations elles-même, ainsi qu’aux petits groupes de participants faisant du networking entre les séances, que ce projet a su se faire incorporer dans des applications couvrant une large gamme : usage intégré, recherche desktop ou entreprise, et même déploiements distribués à grande échelle. Avant tout, le nombre de projets autour de Lucene, ainsi que les améliorations principales prévues, continuent à impressionner - si vous recherchez une solution de recherche open source, Lucene vaut certainement le coup d’être regardé de près.

Lucene dans la nature : Salesforce, LinkedIn, Twitter & Co
Salesforce, LinkedIn et, tout récemment Twitter, sont tous des exemples de déploiements de Lucene à grande échelle utilisés par beaucoup d’entre nous de façon quotidienne. Salesforce a démarré avec Lucene en 2002 et gère aujourd’hui un index de plus de 8TB (environ 20 milliards de documents). Leur cluster comprend environ 16 machines, qui contiennent à leur tour plusieurs petits (sharded) indexes Lucene. Actuellement, ils gèrent environ 4000 requêtes par seconde (qps), et fournissent un modèle d’indexation incrémental dans lequel la nouvelle donnée de l’utilisateur est accessible par recherche dans les 3min.

Lucene Logos

LinkedIn est un autre utilisateur chevronné de Lucene, desservant plus de 350 millions de requêtes par semaine. Leur produit de « recherche de personnes »  atteint actuellement environ 200 qps sur un seul nœud, tout en fournissant une latence régulière en dessous de 100ms. Afin de pouvoir assurer l’expérience temps réel, l’équipe de LinkedIn a écrit son propre framework de tri, et a implémenté sa propre recherche par facettes (Bobo) et un système pour traiter les indexations en temps réel (Zoie).

Twitter est un adepte récent de Lucene – avant le changement, leur API de recherche était alimentée par (surprise !) MySQL. Michael Busch a délivré une superbe présentation ( « A Billion Queries Per Day » ) dans laquelle il a décrit les défis et les changements qu’ils ont dû implémenter au sein de Lucene afin de supporter leur charge de requêtes, qui atteint un pic actuel de 1 milliard de requêtes par jour (env. 12000 qps). Sans surprise, leur indexation entière est stockée en mémoire et détient actuellement jusqu’à 1 milliard des tweets les plus récents – cela représente environ une semaine de données. La bonne nouvelle est que plusieurs de leurs optimisations devraient être répercutées dans le coeur de Lucene d’ici un an.

Evidemment la liste citée ci-dessus est loin d’être complète. iTunes est encore un utilisateur de renom, qui gérerait jusqu’à 800 requêtes/sec, et chez PostRank nous gérons actuellement un index de plus de 1TB (qui grandit  d’environ 40GB chaque semaine) et plus de 1,2 milliard de documents.

Lucene + HTTP : Serveur Solr
Si Lucene est un kit d’outils de récupération de données bas niveau, alors Solr est le serveur de recherche HTTP multi-fonctions qui intègre la librairie Lucene et rajoute des fonctionnalités supplémentaires : parseurs de requêtes supplémentaires, caching HTTP, recherche par facettes, highlighting, et beaucoup d’autres. Le meilleur, c’est qu’une fois que vous avez installé le serveur Solr, vous pouvez l’interroger directement via les APIs REST XML/JSON. Pas besoin d’écrire du code Java ou d’utiliser des clients Java afin d’accéder à vos indexes Lucene.  Solr et Lucene ont commencé comme des projets indépendants, mais l’an dernier les deux équipes ont décidé de fusionner leurs efforts - en somme, c’est une grande nouvelle pour les deux communautés. Si ce n’est pas encore fait, faites donc un tour avec Solr.

Recherche en temps réel avec Lucene
La recherche  en temps réel était un thème important lors de la conférence Lucene Revolution. Contrairement aux autres kits d’outils de récupération de données, Lucene a toujours pris en charge les mises à jour incrémentales des indexes, mais malheureusement, il a également eu besoin d’un appel fsync (flush des nouveaux documents de la mémoire vers le disque), ainsi que d’une réouverture du « lecteur d’index » afin de rendre visibles ces documents aux nouvelles requêtes. Inutile de préciser que les fsyncs coûtent cher, ainsi la pratique recommandée a été la suivante : effectuez un commit après N secondes, ou effectuez un commit après avoir ajouté N documents. Ces stratégies sont efficaces dans la plupart des cas, mais deviennent de véritables points d’engorgement quand vous essayez d’indexer un flux très rapide de mises à jour.

Afin de résoudre ce problème, l’équipe principale travaille sur la branche « Near Realtime » (NRT), où l’index en mémoire deviendra également recherchable dès qu’on lui écrit – cela rend l’attente d’un fsync moins nécessaire. Néanmoins, même avec la mise en place de la branche NRT, le fsync ponctuel et une réouverture du lecteur d’index restent un point d’engorgement important, car ces deux opérations peuvent s’avérer consommatrices en CPU et en mémoire.

Zoie

Zoie est une alternative à NRT. C’est un projet qui a été développé et maintenu par l’équipe de LinkedIn. Similaire à NRT, il rend immédiatement visible aux nouvelles requêtes toutes les mises à jour, mais il implémente également un modèle incrémental d’indexation et de flush, ce qui allège la nécessité d’effectuer des commits importants et explicites. Zoie est déployé actuellement en production chez LinkedIn comme un service standalone (livré avec serveur HTTP), mais il y a aussi des travaux en cours pour l’intégrer avec Solr.

Le meilleur pour la fin : la recherche en temps réel est évidemment très importante pour Twitter. Actuellement, il faut environ 10 secondes pour qu’un tweet figure dans les résultats de recherche depuis l’instant où vous le publiez au service, ce qui est plutôt rapide. Afin d’atteindre cette vitesse, tous les index Lucene sont stockés en mémoire dans plusieurs petits segments (jusqu’à 16 millions de tweets par segment) et ils sont fortement optimisés pour la petite structure documentaire de Twitter. Je vous réfère de nouveau à la présentation de Michael pour plus de détails.

Recherche distribuée
Solr Cloud

Lucene, tel qu’il est livré, ne prend pas en charge des index distribués – votre application sait ouvrir des lecteurs d’index multiples, mais toutes ces actions doivent être gérées de façon manuelle. Solr, par contre, ne permet pas seulement d’héberger et de requêter des « cores »(indexes) multiples, mais apporte aussi la prise en charge des requêtes distribuées, où les résultats de serveurs multiples sont agrégés, notés (scored) correctement, puis renvoyés à l’utilisateur. Néanmoins, même avec Solr, c’est l’application qui doit s’occuper de la gestion des cores, du shuffling des données et de la logique de failover.

SolrCloud tente de résoudre quelques-uns des ces problèmes en intégrant une instance Zookeeper afin de simplifier la création et la gestion des clusters Solr distribués. Plus précisément, le but est de fournir une configuration centrale, du discovery (découverte automatique), du load balancing (équilibrage de la charge), et du failover (reprise). Le projet est toujours en incubation, mais quelques participants à Lucene Revolution ont déclaré l’avoir déjà fait tourner en production ! C’est prometteur.

Deux projets concurrents à SolrCloud se nomment Katta et ElasticSearch. Des deux, il semble que ElasticSearch est actuellement le plus dynamique, et il implémente un moteur de recherche REST, construit sur Lucene. ElasticSearch gère JSON en natif, supporte l’élection de masters et le failover automatisés, la réplication des indexes, les opérations atomiques (pas besoin de commit) et se présente comme un concurrent sérieux à SolrCloud.

Solr, Lucene et NoSQL

Solr Nosql

Au lieu de faire tourner Lucene ou Solr en mode standalone, les deux s’intègrent facilement à d’autres applications. Par exemple, Lucandra vise à implémenter un index Lucene distribué directement sur Cassandra. Jake Luciani, le lead developer du projet, a récemment intégré l’équipe de Riptano à plein temps en tant que développeur. Ne soyez donc pas surpris si bientôt Cassandra prendra en charge un kit d’outils de récupération de données basé sur Lucene comme nouvelle fonctionnalité !

Dans le même temps, Lily vise à intégrer Solr avec HBase de façon transparente afin de permettre un modèle de requêtage et d’indexation plus flexible pour vos jeux de données HBase. Au contraire de Lucandra, Lily ne cherche pas à exploiter HBase comme un stockage d’indexes (voir HBasene pour ceci), mais fait tourner des serveurs Solr de façon autonome (standalone), quoique bien intégrés, afin d’assurer un support flexible aux requêtes et à l’indexation.

En résumé …
Lucene n’est peut être pas parmi vos priorités dans la catégorie des outils Open source prestigieux, mais il profite certainement de l’énergie et du soutien de la communauté des développeurs pour être considéré comme tel. Les projets mentionnés ci-dessus ne sont qu’un échantillon de tout le bon travail réalisé par cette communauté. Pour commencer, jetez un œil à quelques bons livres qui traitent de Lucene et Solr, ou lancez-vous dans un des tutoriels en ligne. Pour finir, félicitations à Lucid Imagination d’avoir organisé Lucene Revolution cette année, et à tous les intervenants pour leurs présentations passionnantes !

Ilya Grigorik @igvita.com

Source : Open Source Search with Lucene & Solr
Traduction : Helen CHAUVEAU, Frédéric FAURE

Un commentaire pour Recherche Open Source avec Lucene & Solr

Répondre

 

 

 

Vous pouvez utiliser ces balises HTML

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>