Faire une étude pour voir si le passage à ElasticSearch est possible/justifié

[DevHugo]

Bonjour,

Ça serait bien de faire une étude pour voir si le passage à Elasticsearch serait possible, cela comprend étudier les performances, niveau documentation, possibilité ou non d'utiliser d'avoir une recherche en français (tokenizers, …), niveau de difficulté de l'installation sur la prod et pour un poste de développeur.

La deuxième partie serait de voir si on y gagnerait pas de virer Haystack pour elasticsearch-dsl. Faudrait comparer le temps de migration de l'un à l'autre, les impacts en terme de performance, la documentation possible, comment est maintenu le projet (date des derniers commits, réactivité), possibilité de faire des tests unitaires avec elasticsearch-dsl.

Note: Elasicsearch 2.0 n'est pas compatible avec Haystack pour l'instant.

[vhf]

Bonne idée.

J'ai utilisé :

django-haystack>=2.0.0
pyelasticsearch>=0.5
elasticsearch

il y a 2 ans et j'avais trouvé très facile à mettre en place et à utiliser.

[DevHugo]

C'était l'idée de Spacefox à la base, rendons au renard, le fromage.

Ça serait bien de faire un tour des compétences de l'équipe sur cette techno pour savoir qui a des connaissances.

[firm1]

Mon point de vue d'il y'a un an sur la question n'a pas changé. J'approuve cette idée.

Ayant une bonne connaissance du bidule, je peux répondre a des questions si vous en avez, mais pas forcément le temps d'en faire plus.

Sinon,

Ça serait bien de faire une étude pour voir si le passage à Elasticsearch serait possible, cela comprend étudier les performances, niveau documentation, possibilité ou non d'utiliser d'avoir une recherche en français (tokenizers, …), niveau de difficulté de l'installation sur la prod et pour un poste de développeur.

Coté perf, Elasticsearch fait au moins aussi bien que Solr (je n'ai pas de chiffre sous la main, mais la dernière fois que j'ai comparé les deux, sur la v1.7 d'ES, c'était ça). La doc d'eslasticsearch est clairement mieux fournie que celle de Solr. Ils se basent tout les deux sur Lucene, donc pas de souci, pour la recherche en Français, c'est géré out of the box. Pour la difficulté d'install, déjà ES est fournie dans pas mal de package manager, debian 8 propose même une version pas trop ancienne. Il y'a aussi la possibilité d'utiliser un tarball. Bref, que du positif.

La deuxième partie serait de voir si on y gagnerait pas de virer Haystack pour elasticsearch-dsl.

De moins point de vue, ES propose assez de connecteurs pour pouvoir se passer de haystack sans problème. Il faudra certainement redévelopper les scripts de build index, mais c'est pour le bien de la planète. Là ou Haystack perd de l'intérêt c'est qu'ils ont du mal à suivre les release d'ES. Typiquement ES a changé sa gestion des facets entre la v1.x et la v2.x et donc Haystack aura besoin d'un bon travail en profondeur pour parvenir à le gérer (autant dire que ça ne sera pas pour bientôt).

En gros, il faudra peut-être apprendre comment s'organise l'indexation avec ES, et avec la lib dispo sur pypy on pourra faire une migration en douceur. En sachant qu'on peut aussi récupérer les index de Solr, donc l'historique ne sera pas perdue.

[SpaceFox]

Très honnêtement, on a absolument pas besoin de « transition en douceur » ni de « récupérer les index de Solr ». Les index complets de prod se re-construisent en moins d'un quart d'heure et ne contiennent pas d'historique.

Mon avis personnel après avoir joué avec ElasticSearch 2, c'est qu'on aurait tout intérêt à l'utiliser, et surtout à l'utiliser le plus directement possible.

Pour moi on a là une occasion en or d'obtenir enfin une recherche utile, ce qui passerait par :

1. Développer un nouveau système de recherche à peu près depuis rien en gardant en tête la pertinence pour l'utilisateur final
2. Utiliser la couche d'interconnexion la plus légère possible, pour éviter d'être bloquée par elle

[DevHugo]

je peux répondre a des questions si vous en avez

Au moins, on a quelqu'un à qui se référer, c'est déjà cool.

Ils se basent tout les deux sur Lucene, donc pas de souci, pour la recherche en Français, c'est géré out of the box.

La question était plus, est-ce simple à mettre en place, car pour Haystack, c'était marqué dans les petits caractères de la documentation. C'était pas difficile au final mais pour le trouver ^^ .

Développer un nouveau système de recherche à peu près depuis rien en gardant en tête la pertinence pour l'utilisateur final

À la louche repartir de zéro veut dire un peu prés une trentaine à une cinquantaine d'heure de dev.

Utiliser la couche d'interconnexion la plus légère possible, pour éviter d'être bloquée par elle

Pas de retour en arriére possible, c'est un peu risqué.

[pierre-24]

Bon. Voilà mon point de départ. Je prend.

[DevHugo]

Si tu veux un peu plus d'information sur comment Solr et Haystack sont utilisé dans le projet, n'hésite pas à consulter, la doc que j'avais faite pendant la zep-12.

Si tu as un souci sur un morceau de code, n'hésite pas à me contacter par mp sur zds ou ici. J'essayerais d'y répondre :) .

Peut-être que pour juger de la fiabilité, tu devrais avoir une sortie de la base de prod ? Je pense que sinon ça va être compliquer de juger.

[pierre-24]

Ok. Mais je croyais que ça avais bloqué parce que Haystack n'était pas compatible avec ES ou un truc du genre. Mais je vais regarder les deux directions: avec Haystack et sans.

[SpaceFox]

Il n'était compatible qu'avec de vielles versions de ES (lequel évolue
assez vite).

Le 19 octobre 2016 à 16:25, Pierre Beaujean [email protected] a
écrit :

Ok. Mais je croyais que ça avais bloqué parce que Haystack n'était pas
compatible avec ES ou un truc du genre. Mais je vais regarder les deux
directions: avec Haystack et sans.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#3748 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFhKnN1w9EY8OKjX4SHC4Ore6ZOgP0G7ks5q1ig9gaJpZM4JTlRZ
.

[DevHugo]

Ouai, mais ça à l'air d'avancer néanmoins pull request (1391) sur le projet https://github.com/django-haystack/django-haystack/.

[SpaceFox]

Cela dit vues les contraintes imposées par Haystack, son état actuel (125
PR en attente, 232 tickets ouverts) et la simplicité de communication avec
ES, je me demande s'il n'est pas plus pertinent de causer directement avec
ES (la question ne se pose pas vraiment avec Solr, qui n'est pas si simple
à interroger). Ou peut-être trouver une lib qui se contente de faire un
binding Python des API ES.

2016-10-19 16:39 GMT+02:00 Hugo Courtecuisse [email protected]:

Ouai, mais ça à l'air d'avancer néanmoins pull request (1391) sur le
projet https://github.com/django-haystack/django-haystack/.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#3748 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFhKnBIOrm4IE2nc7vAWXjyvO5tP7JyTks5q1iuKgaJpZM4JTlRZ
.

[DevHugo]

Je suis entièrement d'accord avec toi, mon sentiment au fond de moi est de laisser tomber Haystack. Faut juste mesurer les conséquences, le travail nécessaire et le fait qu'on devrait tout ré-écrire si on voudrais passer a un autre moteur.

[pierre-24]

Bon, en gros:

• Haystack, c'est mort. Ça bouge pas assez vite, ES vient de sortir une version 5, Haystack ne supporte toujours pas la 2.
• Je compte au moins 5 projets de gens qui on tenté de réécrire plus ou moins Haystack pour ES, donc faire en sorte qu'une classe soit indexée directement. Tout ces projets ne sont plus maintenus (dernier commit > 6 mois). En soit, la partie utile de ces projets ne fait jamais plus de 200 lignes.
• ES propose une API "bas niveau" et "plus haut niveau" (dont @firm1 avait parlé). La "haut-niveau" ressemble très fort à l'ORM de django. En général, les gens rajoutent une couche au dessus de celle là pour directement indexer les objets django, mais la grosse partie du boulot est fait.

Question code, il faudrait donc réécrire tout ça + recoder la commande python manage.py rebuild_indexet python manage.py update_index. Ça me parait pas insurmontable, surtout que le boulot est déjà à moitié fait.

Ensuite, il faudrait réfléchir à l'indexation des contenus. Au pire, il "suffit" d’appeler l'API directement, mais j'ai l'impression que y'a moyen de faire ça plus simplement. Là, faut creuser.

Ça, c'est si on veut un résultat qui soit à peu près équivalent à celui qu'on a actuellement (éventuellement avec de meilleurs performances, probablement avec des résultats plus pertinent). Sauf que ça c'est qu'une partie du problème, et la deuxième partie, c'est "comment rendre la recherche sur ZdS plus performante au delà d'utiliser un meilleur outil" ? (vraie question).

À vous ;-)

[SpaceFox]

Déjà, passer à ES permettrait de définir des règles et critères de recherche beaucoup plus facilement qu'avec Solr.

Ensuite, contrairement à aujourd'hui où on renvoie tous les résultats en vrac, il faudrait catégoriser les résultats (contenus rédigés d'abord, forums ensuite) et les champs de recherche (terme trouvé dans le titre prioritaire sur le terme trouvé dans le corps de texte, avec un système de poids – de mémoire c'est assez simple à faire).

Rien que ça devrait permettre d'avoir une recherche beaucoup plus efficace qu'aujourd'hui. Après on pourrait raffiner.

[DevHugo]

Si j'ai bon souvenir aussi, il faudrait supprimer les balises dans les contenu pour que ça soit du plain text. Même si c'est pas indispensable.

Utiliser les tokeniser en français aussi.

[pierre-24]

Done <3