Migration vers ElasticSearch 7

[AmauryCarrade]

L'objectif de cette PR est de mettre à jour notre moteur de recherche, qui utilise actuellement ElasticSearch 5.5, vers ES 7.

ES 6 et 7 ont apporté plusieurs changements, le plus notable étant la suppression des types de documents que nous utilisons en interne pour différencier dans un même index les différents… types de documents (contenus, messages, …).

Cette PR devra donc :

• mettre à jour le script d'installation ainsi que le Makefile afin d'installer et de lancer ElasticSearch 7 ;
• mettre à jour searchv2 afin de ne plus utiliser les types de documents (il faudra décider de comment faire : on peut ou utiliser un index par type, ou émuler nous-même un type de documents et filtrer dessus lorsqu'on fait les recherches).

Numéro du ticket concerné (optionnel) : #5554

Si les tests échouent, c'est totalement normal pour le moment.

Mise en production

Cette PR nécessitera la mise à jour d'ElasticSearch vers la version 7.9.2 (ou supérieur si une autre version sort entre temps) sur le serveur de production, ou bien en effectuant une mise à jour sans interruption de service, ou en remplaçant à froid ES 5.5 par ES 7.9 puis en réindexant totalement le site.

Il faudra également mettre à jour la configuration d'Ansible pour copier le sous-dossier jvm.options.d en plus du fichier jvm.options.

Contrôle qualité

Aucun de pertinent pour le moment. Voici ce qu'il faudra faire à terme.

• Mettre à jour (ou installer) ES sur votre instance locale : make install-back && ./scripts/install_zds.sh +jdk-local +elastic-local.
• Démarrer ElasticSearch : make run-elasticsearch.
• Vérifier que l'indexation totale fonctionne correctement : make index-all.
• Tester que la recherche fonctionne correctement sur le site.
• Modifier des contenus (republiés), ajouter des messages, bref, changer des trucs qu'on peut chercher sur le site.
• Vérifier que l'indexation partielle fonctionne correctement : make index-flagged.
• Tester que les modifications effectuées à l'avant-dernier point sont bien disponibles dans les résultats de recherche.

[AmauryCarrade]

J'ai un peu investigué cette migration. En fait on rencontre deux problèmes qui imposent de repenser beaucoup de choses :

• les types de documents ne sont plus supportés ;
• les liens de parenté ne sont plus supportés non plus, du moins plus sous la même forme (c'est en réalité une conséquence du premier point).

Pour donner un peu de contexte ; avant ES 6, ES présentait les index comme des bases de données et les mappings (qui représentent le format qu'ont les documents stockés dans l'index d'ES) comme des tables. Sauf qu'ils ont changé de point de vue là dessus, essentiellement car s'il y avait plusieurs mappings avec des champs nommés de la même façon dans un même index, ils étaient stockés de la même façon en interne, et devaient donc être identique. Ce qui causait des confusions.

Désormais, la manière recommandée de faire c'est d'avoir un index par type de document. Aujourd'hui pour ZdS, on a un unique index avec des documents typés ; ES recommanderait d'avoir un index par type (un pour les messages du forum, un pour les sujets du forum, un pour les contenus ; typiquement). On peut aussi émuler l'ancien système avec notre propre champ type dans un mapping sur lequel on filtrerait, mais ça impliquerait de fusionner tous les champs dans un même mapping et de s'assurer qu'il n'y ait pas de conflits.

Aure point, les relations parent/enfant. On les utilise pour les chapitres des contenus, qui sont indexés séparément mais qui référencent leurs parents. On peut toujours le faire tant que tout est dans un seul index (on aurait un index contenus avec un mapping qui serait pour à la fois les contenus et leurs chapitres) avec les nouveaux champs de jointure d'ES, mais ES avertit contre cette option dans la documentation (la graisse est de moi) :

The join field shouldn’t be used like joins in a relation database. In Elasticsearch the key to good performance is to de-normalize your data into documents. Each join field, has_child or has_parent query adds a significant tax to your query performance.

The only case where the join field makes sense is if your data contains a one-to-many relationship where one entity significantly outnumbers the other entity. An example of such case is a use case with products and offers for these products. In the case that offers significantly outnumbers the number of products then it makes sense to model the product as parent document and the offer as child document.

Sommes-nous dans ce cas ? Pour certains contenus oui, pour d'autres à voir. Mais on pourrait dire que oui. Sinon il faudrait indexer d'un côté les contenus avec tout le texte assemblé ; et d'un autre chaque chapitre ; et faire le tri côté Python.

Pour résumer, voici ce qui se dégage de tout ça et qui me semble le plus simple à implémenter (autant pour migrer que pour permettre de faire évoluer efficacement le moteur de recherche à l'avenir).

1. Passer à un index par type de document. Ça va impliquer pas mal de changements techniques, notamment car il faudra avoir un ESIndexManager par AbstractESIndexable (on pourrait renommer le premier ESIndex), qui remplacerait get_es_document_type (ou qui l'utiliserait pour nommer l'index) ;
2. Deux possibilités :
   • créer un seul index pour les contenus avec une jointure ES entre le contenu et ses chapitres ; ou
   • créer un index pour les contenus et un autre pour leurs chapitres, avec les données dupliquées entre les deux.

Si vous avez un avis, ça m'intéresse — surtout si vous connaissez mieux ElasticSearch que moi !

[Situphen]

Concernant le deuxième point, je pense que le mieux est de « créer un seul index pour les contenus avec une jointure ES entre le contenu et ses chapitres » car :

• même s'il faut faire attention aux performances, le module de recherche n'est pas le plus critique de ce point de vue ;
• la deuxième option implique de dupliquer les données, donc on aura en résultat de la recherche à la fois le contenu et le chapitre pour un même mot-clé (enfin j'imagine ?).

[Situphen]

Fermé par décision de la réunion des devs