Indexation en temps réel

Signaux de fumée

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Salut,

Je voudrais discuter avec vous de l'indexation des données, aujourd'hui, l'indexation des données est faite par haystack, avec la commande: python manage.py rebuild_index. Cette commande est très consommatrice en CPU car elle nécessite de ré-indexer tous le contenu à chaque fois. Cette commande est exécute par une tache cron toutes les 30 minutes.

C'est ainsi qu'un cœur à 100% pendant plus de 5 minutes toutes les demi-heures est utilisé.

La première solution, à été de changer la commande python manage.py rebuild_index par python manage.py update_index avec l'implémentation de la méthode qui va bien, pour permettre de ne plus réindexer tous le contenus. La PR à été faite et la QA est au moment ou j'écris ces lignes en cours (un grand merci à Pierre, o/).

Cette solution oblige de passer à une indexation par heure. Cela vous parait t-il acceptable d'avoir un lag d'une heure entre le moment ou le contenu est publié et le moment ou il est indexé ?

J'ai une autre solution à vous proposer, ce serait d'indexer le contenu dés sa publication. Cette solution utilise les signaux Django et le temps d'implémentation, sans compter les tests unitaires est d'environ une trentaine de minutes avec les tests manuel. Cette solution est décrite dans la documentation. On peut ajouter une queu qui permettrait de stocker les demandes d'indexation pour faire pas trop ralentir l'utilisateur, je vous laisse lire la doc sur le sujet.

Quelle solution préféré vous ? pourquoi ?

PS: j'ai pas de chiffre précis sur le coût de l'indexation, si la solution plaît, je pourrais le faire.

Édité par anonyme

+2 -0
Staff

aujourd'hui, l'indexation des données est faite par haystack, avec la commande: python manage.py rebuild_index. Cette commande est très consommatrice en CPU car elle nécessite de ré-indexer tous le contenu à chaque fois. Cette commande est exécute par une tache cron toutes les 30 minutes.

Hugo

Petite rectification, actuellement le contenu est ré-indexé avec python manage.py update_index en production, donc uniquement les mise à jours de contenu (on ne repasse donc pas sur ce qui est déjà indexé).

Cette solution oblige de passer à une indexation par heure.

Hugo

Du coup qu'est ce qui crée cette obligation ?

Sinon, indexer le contenu en tant réel, je suis mitigé, car ça ne fait qu'étaler la consommation de CPU donc je ne suis pas certain que ça résolve le problème.

Staff

Petite rectification, actuellement le contenu est ré-indexé avec python manage.py update_index en production, donc uniquement les mise à jours de contenu (on ne repasse donc pas sur ce qui est déjà indexé).

C'est bien update_index en production, mais à ma connaissance on ne déclare pas les champs qui servent à déterminer les dernières mises à jour et donc on réindexe tout à chaque demi-heure.

En tous cas la dernière fois que j'ai fouillé les logs des requêtes bizarres de la BDD, on voyait clairement les requêtes de réindexation complète de la base.

Cette solution oblige de passer à une indexation par heure.

Je ne comprends pas la logique de cette contrainte ?

De mon point de vue :

  1. L'indexation en temps réel est la meilleure solution, parce qu'indexer un topic devrait se faire de manière invisible (à vérifier) et qu'on en est pas à 5 secondes sur la publication d'un big-tuto.
  2. Quelle que soit la solution, si on ne fait pas systématiquement des indexations complètes, il faut planifier des réindexations complètes de temps à autres (recommendation Solr). Toutes les nuits ou toutes les semaines, par exemple.
Auteur du sujet

aujourd'hui, l'indexation des données est faite par haystack, avec la commande: python manage.py rebuild_index. Cette commande est très consommatrice en CPU car elle nécessite de ré-indexer tous le contenu à chaque fois. Cette commande est exécute par une tache cron toutes les 30 minutes.

Hugo

Petite rectification, actuellement le contenu est ré-indexé avec python manage.py update_index en production, donc uniquement les mise à jours de contenu (on ne repasse donc pas sur ce qui est déjà indexé).

Ça revient quasiment au même, update_index réindexe tout à chaque fois. Tu peux tester ce comportement, en utilisant cette procédure, checkout dev, python manage.py rebuild_index, python manage.py update_index. Tu vera qu'il réindexe bien tout à chaque fois. Conformément à ce qui est écrit dans la documentation.

Le seul moyen de pas tout ré-indexer, c'est d'implémenter la méthode get_updated_field et passer en paramètre soit –age, –start ou –end.

Cette solution oblige de passer à une indexation par heure.

Hugo

Du coup qu'est ce qui crée cette obligation ?

Comme écrit un peu plus haut, le seul moyen est de passer un des trois paramètres suivant: age, start ou end. Sur un premier environnement de dev, il ré-indexe tout, même si je précisait le paramètre start ou/et end. Du coup, il restait plus que le paramètre age qui accepte que des integer et qui se précise en heure. Mais sur un deuxième environnement dev, j'ai réussi à faire que ré-indexer que le nouveau contenu avec les trois arguments: age, start ou end. Je pense à un probléme du à mon environnement à la maison ou à la fatigue.

Quelle que soit la solution, si on ne fait pas systématiquement des indexations complètes, il faut planifier des réindexations complètes de temps à autres (recommendation Solr). Toutes les nuits ou toutes les semaines, par exemple.

+1

Édité par anonyme

+0 -0

J'adore l'idée de l'indexation automatique, mais j'ai quand même un mini-bémol technique: la fonction qui publie les tutos/articles est déjà extrêmement longue en terme de temps (principalement la faute à Pandoc qui fait ce qu'il peut). Je sais pas ce que l'indexation "coute" en terme de performance, mais il faudrait pas que publier un (big-)tutoriel prenne deux minutes à regarder une roue tourner :)

Doctorant et assistant en chimie à l'Université de NamurEx-dev' pour ZdS (a aidé à réaliser la ZEP-12 !) • Carniste cis (y parait que c'est une injure)

+0 -0

mais il faudrait pas que publier un (big-)tutoriel prenne deux minutes à regarder une roue tourner :)

Est-ce que ce serait vraiment un problème ?

SpaceFox

J'ai toujours en tête que PHP mettais un timeout de 30 secondes au delà duquel il tuait l'exécution. Je ne sais pas si une telle limitation existe encore/est présente dans Django.

Doctorant et assistant en chimie à l'Université de NamurEx-dev' pour ZdS (a aidé à réaliser la ZEP-12 !) • Carniste cis (y parait que c'est une injure)

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte