Réflexions sur Algolia (vs Solr & Elasticsearch)

1er juin 2016 Doug Turnbull
Catégorie : Lucene

Après avoir été grincheux sur un billet de blog d’Algolia, et avoir eu un épisode de Search Disco avec Julien Lemoine CTO d’Algolia, je suis laissé fasciné par la solution.

Algolia, si chaud en ce moment !

Algolia présuppose que nous allons tous vouloir une recherche instantanée (aka search-as-you-type). Ils ont donc construit une recherche instantanée extrêmement bonne et hébergée. Tout ce que vous voulez faire avec la recherche instantanée est là. Lisez juste ce post étonnant sur la compréhension des requêtes

• Tolérance à la typo, « Doug Trunbull »
• Recherche de préfixe « Doug Turn »
• Préfixe avec tolérance à la typo « Doug Trun »
• Décomposition (parfois cela peut être une tolérance à la typo) DougTrun
• Un lemmatiseur en temps de requête, et plus encore….

C’est comme si au lieu d’une recherche, vous aviez une autocomplétion sur des stéroïdes. Couplez cela avec un classement par défaut plus sain que Elasticsearch ou Solr, et vous vous retrouvez avec un produit assez convaincant.

Je dis tout cela en tant que Luceniste assez enragé. J’ai écrit un livre sur la pertinence dans Lucene. Je suis très partial envers Lucene, car j’ai vu de nombreuses solutions convaincantes construites avec Solr et Elasticsearch également.

Une chose cependant que j’ai apprise sur la recherche basée sur Lucene est que vous pouvez, avec une bonne équipe, construire à peu près n’importe quelle chose searchy avec elle. Pourtant, il faut une équipe. La recherche basée sur Lucene n’est pas vraiment destinée à fonctionner correctement « tout de suite » pour votre solution. Quelle que soit la facilité avec laquelle Elasticsearch l’a rendue, la recherche basée sur Lucene est un cadre, pas une solution. C’est un ensemble de structures de données axées sur la recherche vraiment étonnantes que vous pouvez bricoler relativement facilement pour faire Votre Chose™. Même si Votre Chose™ signifie modifier des détails aussi bas niveau que la façon dont l’index est stocké sur le disque !

Une autre façon de dire cela est que vous pourriez construire Algolia dans Elasticsearch (ou s’en approcher suffisamment). Vous ne pouvez pas construire Elasticsearch dans Algolia. Vous gagnez d’Algolia la concentration sur un problème spécifique. Vous sacrifiez les possibilités de personnalisation et d’extension de l’open source. Une autre façon de le dire est de comparer les solutions de recherche aux applications web. À bien des égards, Algolia est comparable à la construction d’un site avec un constructeur de sites comme Wix. Lucene est plus comme la construction de votre propre application web avec des développeurs derrière, et toutes les considérations de bas niveau associées, les ennuis, mais aussi la puissance.

Un exemple concret est la comparaison des performances d’Algolia à Elasticsearch. Dans les tests d’Algolia, Algolia revendique jusqu’à 200x d’amélioration des performances. En moyenne, on constate plutôt une amélioration des performances de 10 à 20x (ce qui reste impressionnant). Cependant, Algolia a choisi le plus petit dénominateur commun de la recherche instantanée dans Elasticsearch : les requêtes floues et les requêtes préfixes. Comme il est écrit dans Elasticsearch : The Definitive Guide, une autre approche commune qui améliore considérablement la vitesse est d’utiliser les ngrammes. Fondamentalement, éviter le travail flou au moment de la requête et construire une structure de données géante qui peut le gérer.

Maintenant, les ngrammes ont leurs propres problèmes. Ils font grossir votre index. Cependant, dans le cas de 2 millions de documents avec beaucoup de texte court, cela pourrait ne pas gonfler l’index tant que ça. Et je soupçonne qu’il y aurait des améliorations de plusieurs ordres de grandeur dans les performances. Si un index gonflé devenait un problème, nous pourrions produire moins de ngrammes de plus grande taille. Il faut également tenir compte de la mise en cache : Je parie que les deux solutions mettent en cache les résultats pour chaque requête de frappe. Je me demande donc comment cela colore la considération Algolia vs ES.

Nous pourrions même inverser les termes placés dans l’index pour obtenir des requêtes suffixes pour attraper les fautes de frappe antérieures. Ou faire des choses exotiques avec des requêtes floues et des ngrammes simultanément. Nous pourrions même écrire une requête Lucene qui se concentre sur les typos. Regardez toute la puissance ici!

Le point cependant est que je vous ai fait commencer à penser à la façon dont vous résoudriez le problème. Algolia a déjà construit une solution ! Pourquoi ne pas simplement faire avec la leur ? Eh bien, il y a quelques réserves que j’aurais en allant à fond dans le camp d’Algolia :

• Le tour de clé peut souvent se transformer en lock-in. Il existe des exemples de solutions de recherche hébergées (et de bases de données) qui ont été acquises et le nouveau propriétaire (dans le cas de FoundationDB, Apple) n’était pas intéressé à soutenir l’activité existante.
• Vous vous souciez des « choses et non des chaînes ». La solution d’Algolia se concentre fortement sur la correspondance spécifique des chaînes de caractères. L’approche de la pertinence de Lucene se concentre plus abstraitement sur les termes en tant que caractéristiques du contenu, en utilisant TF*IDF comme système de similarité des caractéristiques (notre livre discute largement de la pertinence en ces termes).
• Vous faites tout ce qui est proche du non traditionnel. Vous avez un langage d’interrogation spécifique à mettre en œuvre. Vous avez besoin de cartographier explicitement les vernaculaires entre les experts et les profanes. Vous voulez faire de l’apprentissage par classement. Vous voulez utiliser des vocabulaires contrôlés, construire une recherche sémantique. Vous avez des préoccupations géographiques spécifiques. Ce sont toutes des fonctionnalités que vous pouvez construire dans Solr/ES et vous êtes enfermé dans ce que Algolia vous donne.
• Vous voulez manipuler profondément le comportement du moteur de recherche. C’est une énorme partie du sweet spot de Lucene.

Mais il y a quelques raisons pour lesquelles je considérerais fortement Algolia

• Vous avez une petite équipe, mais une bonne recherche est importante. Algolia fonctionne assez bien dès le départ. Il a un bon niveau de configurabilité du classement qui peut inclure à la fois du texte et des valeurs numériques comme la popularité avec un certain support géographique.
• Vous avez principalement besoin de supporter les recherches d’un seul élément. L’approche d’Algolia est idéale pour des cas tels que le besoin de rechercher « banane » et de correspondre sur les bananes. Algolia peut ne pas avoir de sens pour les utilisateurs qui tapent « minion fruit » et s’attendent à des bananes.
• Vous avez besoin de prendre en charge les fautes de frappe. Les solutions de Lucene à ce sujet sont maladroites. J’espère qu’elles s’amélioreront et seront plus rapides, mais la recherche floue n’est pas le sweet spot de Lucene.

Voici quelques éléments du marketing d’Algolia avec lesquels je ne serais pas d’accord :

• Algolia aime souligner que l’hébergement d’Elasticsearch va être difficile. Je pense qu’avec des options comme Bonsai et Elastic Cloud, ce n’est guère le cas. Avec un bon hébergeur ES, vous avez essentiellement une bonne « API dans le nuage » qui est tout aussi facile à travailler que n’importe quel autre service.
• Algolia veut vous faire croire qu’Elasticsearch n’est pas un bon moteur de recherche. Il n’est bon que pour l’analyse des big data et la « recherche de big data » (pas sûr de ce que cela signifie). Dans l’esprit de la recherche de « choses non fictives », je ne suis pas d’accord. Il faut juste travailler et comprendre ce qui est spécial dans votre solution de recherche.
• Algolia espère que tout va devenir de la recherche instantanée. Pourtant, dans mon expérience, la prépondérance des expériences de recherche (même beaucoup pilotées par Algolia) sont des autocomplétions d’abord pour sélectionner des mots-clés, puis des recherches par mots-clés. Cela reste dans le sweet spot de Lucene pour la recherche.
• Je crois les benchmarks qu’Algolia fournit, mais il est noté qu’ils n’essaient pas de stratégies de recherche instantanée plus rapides sur Elasticsearch. Nous ne pouvons pas recréer leurs benchmarks nous-mêmes. Algolia semble digne de confiance, mais j’aimerais pouvoir tester cela indépendamment. J’aimerais aussi les voir réexécuter contre des versions plus récentes d’Elasticsearch.

Mais Algolia signale d’importantes faiblesses dans le modèle de pertinence de Lucene

• Typos et correspondance floue : Dans la mesure où le monde veut une recherche instantanée avec une tolérance aux fautes de frappe, la recherche basée sur Lucene est difficile à faire fonctionner. Je croirai également qu’elle est plus lente que la solution ciblée d’Algolia (bien que je ne puisse pas recréer les benchmarks).
• Les valeurs par défaut de pertinence d’Elasticsearch/Solr sont difficiles à régler. Comme Algolia le souligne à juste titre, la fonction de classement dismax donne des résultats assez confus. Nous avons écrit sur ce phénomène ici. Vous pouvez et devriez vous éloigner de ces valeurs par défaut, mais j’aurais aimé que la recherche ait plus de sens dès la sortie de la boîte.
• Les primitives d’Elasticsearch et de Solr pour la pertinence semblent de bas niveau. Celles d’Algolia semblent de plus haut niveau et plus axées sur la création d’une compréhension commune entre l’entreprise et les développeurs. C’est l’une des principales raisons pour lesquelles nous avons créé Quepid. Même encore, avec toutes les options de Solr/ES, vous obtiendrez toujours des regards vides de la part du métier lorsque vous commencerez à parler en termes de requêtes booléennes, de requêtes fonctionnelles, et que sais-je encore.

Ma grande conclusion est que je suis en fait assez enthousiaste à propos d’Algolia pour les bons cas d’utilisation. Mais vous devez être certain qu’il va satisfaire vos besoins. J’espère que cela a fait de vous un acheteur plus informé.

Dans notre pratique de conseil en pertinence, nous serions ravis de vous aider à déterminer quelle solution est la bonne pour vous. N’hésitez pas à nous contacter pour discuter de la solution (Solr, Elasticsearch, Algolia) qui convient à vos besoins !

.