Indexation en temps réel

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.

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é).

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.

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.

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.

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.

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

À la limite, on peut tous les quarts d'heure réindexer toute la dernière heure de contenu, non ?

Oui, on peut faire ça, mais je suis quaziment sur que ça marche avec start et end. À mon avis, c'était 'my bad'.

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

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 ?

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.

Vivement qu'on passe à py3 histoire qu'on puisse utiliser asyncio qui permet de facilement paralléliser les différents exports durant la publication, qui sait, ça permettra peut être d'indexer rapidement tous les nouveaux tutos.