Le plugin Indexation

Le plugin Indexation permet d’organiser l’indexation du contenu des articles pour accélérer le moteur de recherche.

Nota SPIP-Contrib : Ce plugin n’est plus en développement actif, les efforts se tournant vers le plugin Fulltext qui reprend le concept, mais de façon beaucoup plus performante.

À propos du plugin

-  Il exploite le mode FULLTEXT SEARCH IN BOOLEAN MODE de MySQL, cf. http://dev.mysql.com/doc/refman/5.0...
-  Avec ses extracteurs, ce plugin permet d’indexer les fichiers PDF etc.
-  un tableau de bord exec=admin_index permet de voir la progression de l’indexation
-  une balise #EXTRAIT permet d’afficher dans les boucles {recherche} un extrait du texte contenant les mots recherchés ; et cela y compris pour les documents indexés (PDF, rtf etc).

Conditions de compatibilité :
-  SPIP SVN révision >= 10182 [1]
-  MySQL >= 5 ? ou en tout cas 4 avec une option utf-8 (à préciser)

Installation

Ce plugin est encore en développement aussi vous pouvez le récupérer :
-  soit via un client SVN, Plus d’explications ici
-  soit au travers des paquets zip d’ensemble du site miroir > plugins/ plugins_stable.zip

L’installation se déroule ensuite comme pour tous les autres plugins, cf. http://www.spip.net/fr_article3396.html

Raccourcis de recherche

Recopier ici la doc de MySQL ; trouver une manière sympa d’expliquer les subtilités de la syntaxe :

-  +Allô ; exiger le mot Allô ;
-  -Allô ; refuser le mot Allô ;
-  ~Allô ; minorer le score des articles contenant le mot Allô ;
-  Allô Habibi ; les articles contenant Allô ou Habibi ou les deux mots ;
-  "Allô Habibi" ; les articles contenant la phrase "Allô Habibi" ;
-  (>Allô <Habibi) ; les articles contenant Allô ou Habibi, en privilégiant ceux qui contiennent Allô ;
-  etc.

Fonctionnement

Chaque fois qu’un article est modifié, son texte, nettoyé des raccourcis typographiques (il y a un pipeline dédié, pour les plugins qui veulent en ajouter), est recopié dans la table spip_indexation. Les données associées (nom des auteurs, titre des mots-clés etc) sont recopiées aussi. On exploite ensuite une requête MySQL FULLTEXT pour fouiller cette table spip_indexation

TODO

-  proposer une balise #EXTRAIT qui afficherait un extrait pertinent (on l’a dans spip_indexation).
-  rétablir les fonctions de configuration de l’indexation (recherche avancée, indicazzione tabelle) ; la structure de ce qu’on met dans spip_meta est identique à celle d’avant (bien qu’on n’utilise plus les poids, du moins pour le moment), ça devrait faciliter le retour de ces fonctions
-  dans admin_index lister toutes les table éventuellement indexables avec une case à cocher
-  retomber sur la recherche inc/rechercher pour les tables non indexées (ex : spip_syndic_articles)
-  optimiser en supprimant les spip_indexation liés à des objets disparus
-  indexer à part le titre et les meta-infos (surtitre, mots liés...), noter la date de l’objet
-  mode d’indexation à l’ancienne (mots, dico etc) ??
-  repérage automatique des incompatibilités
-  indexer des articles de plusieurs sites SPIP avec le mode « distant » des connexions bases de données
-  pour la balise #EXTRAIT :

  • si on donne deux mots, ne pas donner deux extraits si le second mot est dans l’extrait du premier
  • si on recherche "x y", surligner sans se faire manger par le "
  • ne pas couper les mots salement ("ampoule" => "poule")

-  autres...

Note sur les jeux de caractères

Pour que le mode FULLTEXT de MySQL fonctionne bien, et gère proprement les accents, il faut absolument que la base elle-même sache qu’elle contient de l’utf-8. Or SPIP a longtemps été « sale » de ce point de vue, et les anciennes bases conservent un héritage où les tables contiennent de l’utf-8, mais croient qu’elles contiennent de l’iso-latin-swedish (jeu de caractères
standard de MySQL).

Donc, pour que ça fonctionne vraiment, il convient d’exécuter
ecrire/ ?exec=convert_sql_utf8

ATTENTION À FAIRE UN BACKUP AVANT

Il est possible qu’il faille ensuite demander une réindexation complète du contenu, cf. la page exec=admin_index

Sur un serveur de tests (MySQL un peu vieux : version 4.0.26-standard),
j’ai un message d’erreur « Le charset SPIP actuel utf-8 n’est pas
supporte par votre serveur MySQL ».

Remarque sur les performances

Ou : « du bon usage du plugin indexation »

D’un côté :
-  le moteur de recherche qui attaque directement les tables marche,
selon mes tests, aussi bien que l’ancienne indexation des mots. Il
économise aussi une grosse tâche cron et beaucoup de données en base.
Donc moins de choses à charger en RAM par le serveur, donc moins
souvent des requetes qui mettent 2 minutes à arriver, moins de swap
etc.

De l’autre :
-  la nouvelle indexation crée et remplit une nouvelle table
spip_indexation, en y collant une copie (nettoyée) des données
textuelles de toutes les tables. Avec l’index FULLTEXT en sus, ça
occupe environ deux fois la taille des données. Et rajoute une tâche
cron (plus légère que l’ancienne). On ne peut pas penser que ça n’a
pas d’impact en termes de perfs (si on a peu de RAM par exemple).
Mais en contrepartie les recherches se font à la vitesse de l’éclair,
puisque faites « nativement » par le moteur de MySQL. Donc une petite
perte à chaque hit normal, et un gros gain à chaque recherche.

À partir de là il faut voir ce qu’on veut. Pour un petit site je pense
qu’il n’est pas nécessaire d’utiliser Indexation, la recherche « bête »
est suffisante. Pour un gros site où la recherche peut retourner des
centaines de documents, ou si on veut indexer des PDF, etc, ça vaut le
coup de se charger de cette complexité supplémentaire. Et si on a des
millions de documents, il faut probablement encore autre chose.

Notes

[1Nota : il s’agit de la version 1.9.3 en développement. Cette contrib n’est donc pas compatible avec les versions 1.9.2 et antérieures

Dernière modification de cette page le 14 février 2019

Discussion

19 discussions

  • 1

    bonjour
    je fais un test en local avec SPIP 1.9.3 dev [11283] et mysql 5

    -  mais l’indexation fulltext des pdf ne marche pas, l’indexation est elle sur le titre seul ou sur l’ensemble du document ?
    -  sur ma apge d’accueil une recherche me donne : une page blanche avec « spip_recherches insertion sans description ».

    merci de votre aide

    • je me repond
      cela viens du fait qu’il n’y a pas de table spip_recherches dans cette version svn

      par contre la solution, désole j’ai pas d’idée, plus tard peut être

    Répondre à ce message

  • Bonjour !

    Il y a plusieurs problèmes, il me semble, de faire fonctionner ce plugin avec SPIP SVN (11205).

    La syntaxe « ici une phrase recherchée » ne marche pas du tout, et c’est comme si le recherche bloque sur certaines pages et les montre toujours (peut-être parce que la table spip_recherches ne se met pas à jour ??).

    La mise en page de la page admin_index est cassée.

    Pour retrouver une fonction de recherche qui va à peu près bien sur le site, j’ai dû désactiver le plugin Indexation.

    Répondre à ce message

  • 1

    bonjour,
    avec spip 1.9.3 et ce plugin, j’ai beau chercher, je ne trouve pas la page index_admin, lorsque je tente manuellement j’ai un message d’erreur....
    j’ai du loupé quelque chose dans l’installation, mais quoi ?

    Répondre à ce message

  • 2

    Et encore une chose : peut-il y avoir la possibilité de contrôler ce qui est indexé ? En particulier je désire éviter que les noms des auteurs soient indexés.

    Pour notre structure de site, quand on cherche « John » cela n’aide pas de recevoir une page pleine d’articles mis en ligne par « John-Noël ». Et ce n’est pas très discret, non plus.

    • De ce point de vue j’ai conservé le même système que dans l’ancien plugin indexation : tu peux donc modifier la configuration INDEX_objet_associes. (Mais je ne sais pas où se trouve l’interface de configuration.)

    • Merci, j’ai changé dans le fichier /inc/indexation.php pour définir $INDEX_objet_associes = FALSE; et testé en local. Cela a bien l’effet désiré.

      Mais lorsque je clique pour purger les tables d’indexation (?exec=admin_index) la table `spip_indexation` demeure intacte. Devrais-je effacer le contenu de la table à la main, ou est-ce que le contenu sera progressivement mis à jour ?

    Répondre à ce message

  • 1

    Bonjour,

    Je viens d’essayer ce plugin prometteur sur un SPIP 1.9.3 dev SVN [10570] utilisant une base comprenant plus de 1400 articles, 1170 documents en tout genre mais surtout pdf, et environ 700 articles de sites syndiqués .

    Il fonctionne, à priori, pas mal et me permet de bien intégrer les sites syndiqués dans les recherches, ce que je voulais, à la base, donc, déjà, merci pour le travail accompli.

    J’ai essayé « d’intégrer » la recherche au contenu des documents avec cette boucle :

    < BOUCLE_documents(DOCUMENTS)
    recherche par points inverse pagination 5 >

    < dt >< a href="#URL_DOCUMENT" > #TITRE < /dt >

    < / BOUCLE_documents >

    Une recherche « matchant » un document me retourne l’erreur suivante ( un peu longue, j’ai donc rajouté un ou deux espaces...) :

    < BOUCLE_documents > (documents)
    Erreur SQL
    documents.id_document, 0+124*(((id_document IN (27,28,152,158,296,384,396,576,613,1065)))) +125*(((id_document IN (74,125,126,127,128,381,383,489,490,566, 567,571,675,676,743,830,831,844,987,1806)))) +129*(((id_document IN (312)))) +120*(((id_document IN (401)))) +119*(((id_document IN (402)))) as points, documents.titre FROM spip_documents AS `documents` LEFT JOIN spip_documents_articles AS a ON `documents`.id_document=a.id_document LEFT JOIN spip_articles AS aa ON a.id_article=aa.id_article LEFT JOIN spip_documents_breves AS b ON `documents`.id_document=b.id_document LEFT JOIN spip_breves AS bb ON b.id_breve=bb.id_breve LEFT JOIN spip_documents_rubriques AS r ON `documents`.id_document=r.id_rubrique LEFT JOIN spip_rubriques AS rr ON r.id_rubrique=rr.id_rubrique WHERE (((id_document IN (27,28,74,125,126,127,128,152,158,296,312,381,383, 384,396,401,402,489,490,566,567,571,576,613,675, 676,743,830,831,844,987,1065,1806)))) AND (documents.taille > 0 OR documents.distant=’oui’) AND (documents.mode != ’vignette’) AND (aa.statut = ’publie’ OR bb.statut = ’publie’ OR rr.id_rubrique = ’publie’) ORDER BY points DESC
    Column ’id_document’ in field list is ambiguous
    < / BOUCLE_documents >

    Je me doute bien qu’il suffit de préciser quelque chose du type document.id_document dans une requête SQL, mais je ne sais où la trouver.

    Ou bien faut-il se servir du fichier rogatons.txt et modifier distant.php du moteur à la main ?

    NB : des accolades et des balises ont été mangées par un petit écureuil :)

    • Cette requete est générée par inc/prepare_recherche ; si tu regardes bien la différence entre la version du core et celle du plugin, il y a dans le core un :

      calcul_mysql_in("$table.$primary" ...

      dans le plugin c’est plutôt :

      calcul_mysql_in($primary ...

      Essaie donc de remplacer ça dans le plugin, et de voir si ça résoud ; si oui tu peux commit la correction :-)

    Répondre à ce message

  • Bonsoir,

    Alors le plugin est mise en place sur le site taize.fr

    Premières impressions :

    -  J’ai l’impression que la recherche est plus fiable et plus rapide qu’avec l’ancien système. Merci !
    -  Je pense que la balise #EXTRAIT donne aussi au lecteur un meilleur aperçu de ce qui a été trouvé.
    -  Le site prenait une âge pour se faire indexé (environ 8-10 articles par heure). Alors j’ai cliquer beaucoup de fois sur le bouton de la page admin_index pour arriver à indexer 3.500 articles.
    -  Améliorations pour la balise #EXTRAIT :
    pas moyen de lui faire prendre en compte les balises <multi> ? (Je suppose que tu enlèves les balises multi en écrivant la table.) Mais les titres/textes en multi rendent un résultat plutôt difficile à lire
    la balise semble avoir difficulté avec certains caractères «  », «  » (voir la même page)
    -  si on recherche une phrase, par ex. « après la rencontre » le surlignement dans les pages retrouvées est toute à fait fantaisiste et déroutant !

    Répondre à ce message

  • 1

    Aussi je trouve :

    Fatal error : Call to undefined function : prepare_recherche() in /home2/icasse/public_html/ecrire/public/composer.php(72) : eval()’d code on line 213

    quand je veux faire une recherche avec spip 1.9.2b

     :-(

    Salut

    Répondre à ce message

  • Merci, Fil, mais je me trouve avec « Moteur de recherche
    Fatal error : Call to undefined function : sql_countsel() in /home2/icasse/public_html/plugins/indexation/exec/admin_index.php on line 126 » avec spip 1.92b + plugin indexation + recherche etendue. Salut !

    Répondre à ce message

  • La première idée qui m’est venue en lisant le chapeau de cet article : ça serait-y pas bien de tester ce super plugin de la balle sur spip-contrib ?

    Parce que bon, faut être patient ici hein..

    Répondre à ce message

Ajouter un commentaire

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom