quelques questions sur le module d'indexation

  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:818b4e53a55973cf498d63ff8ee53918' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Voici quelques questions que je me pose au niveau du système mis en<br />\nplace pour l\'indexation plein texte.</p>\n<p>- Le crawling d\'un entrepôt peut être très long (plusieurs heures avec<br />\nun index de 900Mo par exemple pour l\'entrepôt canal-u si on n\'applique<br />\naucun filtre sur les mimetypes).<br />\nDu coup si on veut réinitialiser son index pour une raison quelconque<br />\n(suppression du moissonnage d\'un entrepôt par exemple) alors on doit<br />\nrefaire l\'ensemble du crawling avant de retrouver un service complet ?<br />\nNe serait-il pas mieux de le dissocier de l\'index principal et de faire<br />\nune jonction sur l\'attribut md-ori-oai-id par exemple ?</p>\n<p>- Le crawling est-il incrémental ou bien toujours complet ?</p>\n<p>- Si le document associé à une fiche de metadata a déjà été crawlé mais<br />\nest modifié depuis ; sera-t-il mis à jour lors du prochain crawling ?<br />\n(je ne vois aucune référence à l\'attribut md-ori-oai-datestamp qui<br />\npourrait servir de repère par rapport à la date de dernier crawling).</p>\n<p>- A-t-on un moyen de savoir si le crawling est terminé (à part cliquer<br />\ncontinuellement sur le bouton \"Lancer le crawling\") ?</p>\n<p>- Peux-t-on arrêter le crawling sans couper le tomcat du module<br />\nd\'indexation ? Je pose la question car lors du crawling de canal-u j\'ai<br />\nmis la machine sur les genoux à cause du nombre d\'io. Je tournais à 30<br />\nde charge pendant plusieurs heures et du coup plus aucun service n\'était<br />\nréactif :-(.</p>\n<p>- Sinon dans src/ori-oai-indexing-svn/properties/liusConfig.xml on est<br />\npassé entre les versions \"1.1\" et \"1.4\" de :<br />\n <indexWriterProperty mergeFactor=\"10\" maxMergeDocs=\"100\"<br />\noptimize=\"true\"/><br />\nà<br />\n <indexWriterProperty mergeFactor=\"2\" maxMergeDocs=\"20\"<br />\noptimize=\"true\"/><br />\nAutant cela doit accélérer la recherche, autant l\'indexation doit être<br />\nplus lente si j\'ai bien compris l\'utilité de ces paramètres.<br />\nActuellement j\'ai l\'impression que les valeurs sont fixes. Il doit être<br />\npossible de modifier ces valeurs temporairement afin d\'optimiser les<br />\nressources cpu et le temps passé lors d\'un moissonnage ou lors du crawling.</p>\n<p>- La configuration des types de fichiers explorés (mimeTypes) se fait<br />\ndans le module d\'indexation en mode texte<br />\n(properties/configIndexing.xml) ; pourtant cela aurait bien sa place<br />\ndans l\'interface graphique du module de moissonnage.</p>\n<p>- Est-il prévu de ne pouvoir lancer manuellement le crawler que sur<br />\ncertains entrepôts ? Par exemple il pourrait arriver de vouloir<br />\nrecrawler ses ressources locales en pleine journée sans vouloir faire<br />\nles autres entrepôts. Actuellement il semble que le crawler attaque tous<br />\nles entrepôts sauf ceux référencés dans la balise <doNotCrawl>, mais on<br />\nne va pas couper le module d\'indexation juste pour modifier cette valeur<br />\ntemporairement...</p>\n<p>À+</p>\n<p>--<br />\nCe message a été vérifié par MailScanner<br />\npour des virus ou des polluriels et rien de<br />\nsuspect n\'a été trouvé.</p>\n</div>\n', created = 1507749289, expire = 1507835689, headers = '', serialized = 0 WHERE cid = '4:818b4e53a55973cf498d63ff8ee53918' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:7d257b6c2a7afc204e567cce72399619' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour Mikael,</p>\n<p>Merci de participer aussi activement à ces apsects avancés (je trouve<br />\nque certains éléments de tes remarques auraient plutôt leur place sur la<br />\nliste dev, que je met en copie pour en garder plus facilement la trace)</p>\n<p>Je répond sur certains points généraux, mais je laisse Yannick répondre<br />\nsur l\'état des fonctionnalités proprement dites du module indexing.</p>\n<p>Mikael Le Bohec a écrit :<br />\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\"><p>> Voici quelques questions que je me pose au niveau du système mis en<br />\n> place pour l\'indexation plein texte.<br />\n><br />\n> - Le crawling d\'un entrepôt peut être très long (plusieurs heures avec<br />\n> un index de 900Mo par exemple pour l\'entrepôt canal-u si on n\'applique<br />\n> aucun filtre sur les mimetypes).<br />\n> Du coup si on veut réinitialiser son index pour une raison quelconque<br />\n> (suppression du moissonnage d\'un entrepôt par exemple) alors on doit<br />\n> refaire l\'ensemble du crawling avant de retrouver un service complet ?<br />\n> Ne serait-il pas mieux de le dissocier de l\'index principal et de<br />\n> faire une jonction sur l\'attribut md-ori-oai-id par exemple ?<br />\n></div>\n</blockquote>\n<p>Je suggère pour ma part cette option depuis le début, plus généralement<br />\nl\'idée de faire des sous-index relié entre eux par l\'identifiant de la<br />\nfiche. Le plein texte est un énorme champ tokenizé qui aurait sa place<br />\ndans un index à part.<br />\nDans mon souvenir, l\'intégration prévue de Compass dans ce module devait<br />\naidé à gérer cet aspect multi-index, mais Yannick t\'en dira plus.<br />\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\"><p>> - Le crawling est-il incrémental ou bien toujours complet ?<br />\n><br />\n> - Si le document associé à une fiche de metadata a déjà été crawlé<br />\n> mais est modifié depuis ; sera-t-il mis à jour lors du prochain<br />\n> crawling ? (je ne vois aucune référence à l\'attribut<br />\n> md-ori-oai-datestamp qui pourrait servir de repère par rapport à la<br />\n> date de dernier crawling).<br />\n><br />\n> - A-t-on un moyen de savoir si le crawling est terminé (à part cliquer<br />\n> continuellement sur le bouton \"Lancer le crawling\") ?<br />\n><br />\n> - Peux-t-on arrêter le crawling sans couper le tomcat du module<br />\n> d\'indexation ? Je pose la question car lors du crawling de canal-u<br />\n> j\'ai mis la machine sur les genoux à cause du nombre d\'io. Je tournais<br />\n> à 30 de charge pendant plusieurs heures et du coup plus aucun service<br />\n> n\'était réactif :-(.<br />\n><br />\n> - Sinon dans src/ori-oai-indexing-svn/properties/liusConfig.xml on est<br />\n> passé entre les versions \"1.1\" et \"1.4\" de :<br />\n> <indexWriterProperty mergeFactor=\"10\"<br />\n> maxMergeDocs=\"100\" optimize=\"true\"/><br />\n> à<br />\n> <indexWriterProperty mergeFactor=\"2\" maxMergeDocs=\"20\"<br />\n> optimize=\"true\"/><br />\n> Autant cela doit accélérer la recherche, autant l\'indexation doit être<br />\n> plus lente si j\'ai bien compris l\'utilité de ces paramètres.<br />\n> Actuellement j\'ai l\'impression que les valeurs sont fixes. Il doit<br />\n> être possible de modifier ces valeurs temporairement afin d\'optimiser<br />\n> les ressources cpu et le temps passé lors d\'un moissonnage ou lors du<br />\n> crawling.<br />\n><br />\n> - La configuration des types de fichiers explorés (mimeTypes) se fait<br />\n> dans le module d\'indexation en mode texte<br />\n> (properties/configIndexing.xml) ; pourtant cela aurait bien sa place<br />\n> dans l\'interface graphique du module de moissonnage.<br />\n></div>\n</blockquote>\n<p>Je pense que cette partie d\'ihm doit être gérée par le module indexing,<br />\nhistoire de ne pas coupler abusivement les deux modules, mais que par<br />\ncontre cet onglet devrait en effet être intégré à l\'ihm du moissonneur<br />\nd\'une façon ou d\'une autre (par un lien, une iframe, une lytebox...)<br />\nCela fait partie des choses auxquelles on doit commencer à réflechir<br />\npour remembrer/interconnecter les ihm.</p>\n<p>A+<br />\nFrançois<br />\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\"><p>> - Est-il prévu de ne pouvoir lancer manuellement le crawler que sur<br />\n> certains entrepôts ? Par exemple il pourrait arriver de vouloir<br />\n> recrawler ses ressources locales en pleine journée sans vouloir faire<br />\n> les autres entrepôts. Actuellement il semble que le crawler attaque<br />\n> tous les entrepôts sauf ceux référencés dans la balise <doNotCrawl>,<br />\n> mais on ne va pas couper le module d\'indexation juste pour modifier<br />\n> cette valeur temporairement...<br />\n><br />\n> À+</div>\n</blockquote>\n<p>--<br />\nCe message a été vérifié par MailScanner<br />\npour des virus ou des polluriels et rien de<br />\nsuspect n\'a été trouvé.</p>\n</div>\n', created = 1507749290, expire = 1507835690, headers = '', serialized = 0 WHERE cid = '4:7d257b6c2a7afc204e567cce72399619' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:9dfe241b6c51e63f2d65608c20c0d23f' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour,</p>\n<p>je réponds dans le mail.</p>\n<p>Francois Jannin a écrit :<br />\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\"><p>> Bonjour Mikael,<br />\n><br />\n> Merci de participer aussi activement à ces apsects avancés (je trouve<br />\n> que certains éléments de tes remarques auraient plutôt leur place sur<br />\n> la liste dev, que je met en copie pour en garder plus facilement la<br />\n> trace)<br />\n><br />\n> Je répond sur certains points généraux, mais je laisse Yannick<br />\n> répondre sur l\'état des fonctionnalités proprement dites du module<br />\n> indexing.<br />\n><br />\n> Mikael Le Bohec a écrit :</p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>> Voici quelques questions que je me pose au niveau du système mis en<br />\n>> place pour l\'indexation plein texte.<br />\n>><br />\n>> - Le crawling d\'un entrepôt peut être très long (plusieurs heures<br />\n>> avec un index de 900Mo par exemple pour l\'entrepôt canal-u si on<br />\n>> n\'applique aucun filtre sur les mimetypes).<br />\n>> Du coup si on veut réinitialiser son index pour une raison quelconque<br />\n>> (suppression du moissonnage d\'un entrepôt par exemple) alors on doit<br />\n>> refaire l\'ensemble du crawling avant de retrouver un service complet ?<br />\n>> Ne serait-il pas mieux de le dissocier de l\'index principal et de<br />\n>> faire une jonction sur l\'attribut md-ori-oai-id par exemple ?<br />\n>></p></blockquote>\n<blockquote class=\"emailFilter_Author_0\"><p>> Je suggère pour ma part cette option depuis le début, plus<br />\n> généralement l\'idée de faire des sous-index relié entre eux par<br />\n> l\'identifiant de la fiche. Le plein texte est un énorme champ tokenizé<br />\n> qui aurait sa place dans un index à part.<br />\n> Dans mon souvenir, l\'intégration prévue de Compass dans ce module<br />\n> devait aidé à gérer cet aspect multi-index, mais Yannick t\'en dira plus.</div>\n</blockquote>\n<p>La politique sur laquelle se base OOIndexing dans le cadre du crawling<br />\nest de dire ceci : \"Si je supprime une fiche, je supprime le plein texte<br />\nassocié\". On va même plus loin en disant : \"Si je modifie une fiche<br />\nalors je supprime le plein texte associé\". Il n\'a pas été prévu<br />\nqu\'OOIndexing reçoive une information lui indiquant s\'il faut ou non<br />\nsupprimer le plein texte. Donc pour l\'instant on supprime le tout. Pour<br />\néviter de supprimer le plein texte avec la fiche il faudrait donc lui<br />\nindiquer ce qu\'il doit faire.</p>\n<p>Avec cette information supplémentaire, on peut alors imaginer d\'utiliser<br />\nun second index ne contenant que le plein texte.</p>\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_1\"><p>>> - Le crawling est-il incrémental ou bien toujours complet?<br />\n>> - Si le document associé à une fiche de metadata a déjà été crawlé<br />\n>> mais est modifié depuis ; sera-t-il mis à jour lors du prochain<br />\n>> crawling ? (je ne vois aucune référence à l\'attribut<br />\n>> md-ori-oai-datestamp qui pourrait servir de repère par rapport à la<br />\n>> date de dernier crawling).</div>\n</blockquote>\n<p>Non, la modification du document n\'entraine pas de nouveau crawling.<br />\nOn se base ici sur la fiche descriptive. Si elle est modifiée alors on<br />\nsupprime le plein texte.</p>\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_1\"><p>>><br />\n>> - A-t-on un moyen de savoir si le crawling est terminé (à part<br />\n>> cliquer continuellement sur le bouton \"Lancer le crawling\") ?</div>\n</blockquote>\n<p>Pour l\'instant non.<br />\nMais ceci devrait être créé dans une prochaine version du module.</p>\n<p>A l\'heure actuelle dans l\'onglet \"Visualisation de toutes les fiches\",<br />\nil existe une colonne \"crawled\" qui indique si une fiche a été crawlée<br />\nou non. Si des fiches sont encore à la valeur \"no\" c\'est que le crawling<br />\nn\'est pas terminé.</p>\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_1\"><p>>><br />\n>> - Peux-t-on arrêter le crawling sans couper le tomcat du module<br />\n>> d\'indexation ? Je pose la question car lors du crawling de canal-u<br />\n>> j\'ai mis la machine sur les genoux à cause du nombre d\'io. Je<br />\n>> tournais à 30 de charge pendant plusieurs heures et du coup plus<br />\n>> aucun service n\'était réactif :-(.</div>\n</blockquote>\n<p>Non. Cette fonctionnalité serait très intéressante effectivement. Je<br />\nl\'ajoute dans la liste de mes tâches à effectuer.</p>\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_1\"><p>>><br />\n>> - Sinon dans src/ori-oai-indexing-svn/properties/liusConfig.xml on<br />\n>> est passé entre les versions \"1.1\" et \"1.4\" de :<br />\n>> <indexWriterProperty mergeFactor=\"10\"<br />\n>> maxMergeDocs=\"100\" optimize=\"true\"/><br />\n>> à<br />\n>> <indexWriterProperty mergeFactor=\"2\" maxMergeDocs=\"20\"<br />\n>> optimize=\"true\"/><br />\n>> Autant cela doit accélérer la recherche, autant l\'indexation doit<br />\n>> être plus lente si j\'ai bien compris l\'utilité de ces paramètres.<br />\n>> Actuellement j\'ai l\'impression que les valeurs sont fixes. Il doit<br />\n>> être possible de modifier ces valeurs temporairement afin d\'optimiser<br />\n>> les ressources cpu et le temps passé lors d\'un moissonnage ou lors du<br />\n>> crawling.</div>\n</blockquote>\n<p>Effectivement ces valeurs ont été modifiées pour améliorer les<br />\nperformances à la recherche. Mais elles permettent aussi de conserver un<br />\nindex \"propre\" durant l\'indexation. Avec l\'arrivée du crawling on ne<br />\npeut plus optimiser l\'index après passage de la dernière fiche à<br />\ntraiter. En modifiant ces valeurs on évite donc de se retrouver avec un<br />\nindex qui n\'a pas été optimisé depuis trop longtemps, quitte à perdre en<br />\nterme de performances à l\'indexation.</p>\n<p>Donc il faut préalablement une commande qui permette à l\'utilisateur<br />\nd\'optimiser son index quand il souhaite. Alors on pourra ensuite<br />\nimaginer d\'avoir des valeurs qui permettent de meilleures performances à<br />\nla recherche.</p>\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_1\"><p>>><br />\n>> - La configuration des types de fichiers explorés (mimeTypes) se fait<br />\n>> dans le module d\'indexation en mode texte<br />\n>> (properties/configIndexing.xml) ; pourtant cela aurait bien sa place<br />\n>> dans l\'interface graphique du module de moissonnage.<br />\n>></p></blockquote>\n<blockquote class=\"emailFilter_Author_0\"><p>> Je pense que cette partie d\'ihm doit être gérée par le module<br />\n> indexing, histoire de ne pas coupler abusivement les deux modules,<br />\n> mais que par contre cet onglet devrait en effet être intégré à l\'ihm<br />\n> du moissonneur d\'une façon ou d\'une autre (par un lien, une iframe,<br />\n> une lytebox...)<br />\n> Cela fait partie des choses auxquelles on doit commencer à réflechir<br />\n> pour remembrer/interconnecter les ihm.<br />\n><br />\n> A+<br />\n> François</p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>> - Est-il prévu de ne pouvoir lancer manuellement le crawler que sur<br />\n>> certains entrepôts ? Par exemple il pourrait arriver de vouloir<br />\n>> recrawler ses ressources locales en pleine journée sans vouloir faire<br />\n>> les autres entrepôts. Actuellement il semble que le crawler attaque<br />\n>> tous les entrepôts sauf ceux référencés dans la balise <doNotCrawl>,<br />\n>> mais on ne va pas couper le module d\'indexation juste pour modifier<br />\n>> cette valeur temporairement...</div>\n</blockquote>\n<p>Cette idée est également très intéressante et je mettrai en place cette<br />\nfonctionnalité dans une future version du module.</p>\n<p>Je tiens à rappeler enfin que le système de crawling est encore très<br />\njeune et qu\'il y a beaucoup d\'améliorations à y apporter. Il ne s\'agit<br />\nlà que d\'une première version qui ne demande qu\'à être perfectionnée.<br />\nMerci donc pour l\'intérêt que vous portez au crawling.</p>\n<p>Yannick</p>\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_1\"><p>>><br />\n>> À+</p></blockquote>\n<blockquote class=\"emailFilter_Author_0\"><p>><br />\n></div>\n</blockquote>\n<p>--<br />\nCe message a été vérifié par MailScanner<br />\npour des virus ou des polluriels et rien de<br />\nsuspect n\'a été trouvé.</p>\n</div>\n', created = 1507749290, expire = 1507835690, headers = '', serialized = 0 WHERE cid = '4:9dfe241b6c51e63f2d65608c20c0d23f' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
3 messages / 0 nouveaux
Sujet clos
Dernière contribution
5 mars 2009 - 6:30pm
#1
mikaellebohec
quelques questions sur le module d'indexation
Voici quelques questions que je me pose au niveau du système mis en
place pour l'indexation plein texte.

- Le crawling d'un entrepôt peut être très long (plusieurs heures avec
un index de 900Mo par exemple pour l'entrepôt canal-u si on n'applique
aucun filtre sur les mimetypes).
Du coup si on veut réinitialiser son index pour une raison quelconque
(suppression du moissonnage d'un entrepôt par exemple) alors on doit
refaire l'ensemble du crawling avant de retrouver un service complet ?
Ne serait-il pas mieux de le dissocier de l'index principal et de faire
une jonction sur l'attribut md-ori-oai-id par exemple ?

- Le crawling est-il incrémental ou bien toujours complet ?

- Si le document associé à une fiche de metadata a déjà été crawlé mais
est modifié depuis ; sera-t-il mis à jour lors du prochain crawling ?
(je ne vois aucune référence à l'attribut md-ori-oai-datestamp qui
pourrait servir de repère par rapport à la date de dernier crawling).

- A-t-on un moyen de savoir si le crawling est terminé (à part cliquer
continuellement sur le bouton "Lancer le crawling") ?

- Peux-t-on arrêter le crawling sans couper le tomcat du module
d'indexation ? Je pose la question car lors du crawling de canal-u j'ai
mis la machine sur les genoux à cause du nombre d'io. Je tournais à 30
de charge pendant plusieurs heures et du coup plus aucun service n'était
réactif :-(.

- Sinon dans src/ori-oai-indexing-svn/properties/liusConfig.xml on est
passé entre les versions "1.1" et "1.4" de :
optimize="true"/>
à
optimize="true"/>
Autant cela doit accélérer la recherche, autant l'indexation doit être
plus lente si j'ai bien compris l'utilité de ces paramètres.
Actuellement j'ai l'impression que les valeurs sont fixes. Il doit être
possible de modifier ces valeurs temporairement afin d'optimiser les
ressources cpu et le temps passé lors d'un moissonnage ou lors du crawling.

- La configuration des types de fichiers explorés (mimeTypes) se fait
dans le module d'indexation en mode texte
(properties/configIndexing.xml) ; pourtant cela aurait bien sa place
dans l'interface graphique du module de moissonnage.

- Est-il prévu de ne pouvoir lancer manuellement le crawler que sur
certains entrepôts ? Par exemple il pourrait arriver de vouloir
recrawler ses ressources locales en pleine journée sans vouloir faire
les autres entrepôts. Actuellement il semble que le crawler attaque tous
les entrepôts sauf ceux référencés dans la balise , mais on
ne va pas couper le module d'indexation juste pour modifier cette valeur
temporairement...

À+

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

Haut
Étiquettes:
6 mars 2009 - 9:46am
#2
francoisjannin
Bonjour Mikael,

Merci de participer aussi activement à ces apsects avancés (je trouve
que certains éléments de tes remarques auraient plutôt leur place sur la
liste dev, que je met en copie pour en garder plus facilement la trace)

Je répond sur certains points généraux, mais je laisse Yannick répondre
sur l'état des fonctionnalités proprement dites du module indexing.

Mikael Le Bohec a écrit :

> Voici quelques questions que je me pose au niveau du système mis en
> place pour l'indexation plein texte.
>
> - Le crawling d'un entrepôt peut être très long (plusieurs heures avec
> un index de 900Mo par exemple pour l'entrepôt canal-u si on n'applique
> aucun filtre sur les mimetypes).
> Du coup si on veut réinitialiser son index pour une raison quelconque
> (suppression du moissonnage d'un entrepôt par exemple) alors on doit
> refaire l'ensemble du crawling avant de retrouver un service complet ?
> Ne serait-il pas mieux de le dissocier de l'index principal et de
> faire une jonction sur l'attribut md-ori-oai-id par exemple ?
>

Je suggère pour ma part cette option depuis le début, plus généralement
l'idée de faire des sous-index relié entre eux par l'identifiant de la
fiche. Le plein texte est un énorme champ tokenizé qui aurait sa place
dans un index à part.
Dans mon souvenir, l'intégration prévue de Compass dans ce module devait
aidé à gérer cet aspect multi-index, mais Yannick t'en dira plus.

> - Le crawling est-il incrémental ou bien toujours complet ?
>
> - Si le document associé à une fiche de metadata a déjà été crawlé
> mais est modifié depuis ; sera-t-il mis à jour lors du prochain
> crawling ? (je ne vois aucune référence à l'attribut
> md-ori-oai-datestamp qui pourrait servir de repère par rapport à la
> date de dernier crawling).
>
> - A-t-on un moyen de savoir si le crawling est terminé (à part cliquer
> continuellement sur le bouton "Lancer le crawling") ?
>
> - Peux-t-on arrêter le crawling sans couper le tomcat du module
> d'indexation ? Je pose la question car lors du crawling de canal-u
> j'ai mis la machine sur les genoux à cause du nombre d'io. Je tournais
> à 30 de charge pendant plusieurs heures et du coup plus aucun service
> n'était réactif :-(.
>
> - Sinon dans src/ori-oai-indexing-svn/properties/liusConfig.xml on est
> passé entre les versions "1.1" et "1.4" de :
> > maxMergeDocs="100" optimize="true"/>
> à
> > optimize="true"/>
> Autant cela doit accélérer la recherche, autant l'indexation doit être
> plus lente si j'ai bien compris l'utilité de ces paramètres.
> Actuellement j'ai l'impression que les valeurs sont fixes. Il doit
> être possible de modifier ces valeurs temporairement afin d'optimiser
> les ressources cpu et le temps passé lors d'un moissonnage ou lors du
> crawling.
>
> - La configuration des types de fichiers explorés (mimeTypes) se fait
> dans le module d'indexation en mode texte
> (properties/configIndexing.xml) ; pourtant cela aurait bien sa place
> dans l'interface graphique du module de moissonnage.
>

Je pense que cette partie d'ihm doit être gérée par le module indexing,
histoire de ne pas coupler abusivement les deux modules, mais que par
contre cet onglet devrait en effet être intégré à l'ihm du moissonneur
d'une façon ou d'une autre (par un lien, une iframe, une lytebox...)
Cela fait partie des choses auxquelles on doit commencer à réflechir
pour remembrer/interconnecter les ihm.

A+
François

> - Est-il prévu de ne pouvoir lancer manuellement le crawler que sur
> certains entrepôts ? Par exemple il pourrait arriver de vouloir
> recrawler ses ressources locales en pleine journée sans vouloir faire
> les autres entrepôts. Actuellement il semble que le crawler attaque
> tous les entrepôts sauf ceux référencés dans la balise ,
> mais on ne va pas couper le module d'indexation juste pour modifier
> cette valeur temporairement...
>
> À+

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

Haut
9 mars 2009 - 11:58am
(Répondre à #2) #3
yannickcaillaux
Bonjour,

je réponds dans le mail.

Francois Jannin a écrit :

> Bonjour Mikael,
>
> Merci de participer aussi activement à ces apsects avancés (je trouve
> que certains éléments de tes remarques auraient plutôt leur place sur
> la liste dev, que je met en copie pour en garder plus facilement la
> trace)
>
> Je répond sur certains points généraux, mais je laisse Yannick
> répondre sur l'état des fonctionnalités proprement dites du module
> indexing.
>
> Mikael Le Bohec a écrit :

>> Voici quelques questions que je me pose au niveau du système mis en
>> place pour l'indexation plein texte.
>>
>> - Le crawling d'un entrepôt peut être très long (plusieurs heures
>> avec un index de 900Mo par exemple pour l'entrepôt canal-u si on
>> n'applique aucun filtre sur les mimetypes).
>> Du coup si on veut réinitialiser son index pour une raison quelconque
>> (suppression du moissonnage d'un entrepôt par exemple) alors on doit
>> refaire l'ensemble du crawling avant de retrouver un service complet ?
>> Ne serait-il pas mieux de le dissocier de l'index principal et de
>> faire une jonction sur l'attribut md-ori-oai-id par exemple ?
>>

> Je suggère pour ma part cette option depuis le début, plus
> généralement l'idée de faire des sous-index relié entre eux par
> l'identifiant de la fiche. Le plein texte est un énorme champ tokenizé
> qui aurait sa place dans un index à part.
> Dans mon souvenir, l'intégration prévue de Compass dans ce module
> devait aidé à gérer cet aspect multi-index, mais Yannick t'en dira plus.

La politique sur laquelle se base OOIndexing dans le cadre du crawling
est de dire ceci : "Si je supprime une fiche, je supprime le plein texte
associé". On va même plus loin en disant : "Si je modifie une fiche
alors je supprime le plein texte associé". Il n'a pas été prévu
qu'OOIndexing reçoive une information lui indiquant s'il faut ou non
supprimer le plein texte. Donc pour l'instant on supprime le tout. Pour
éviter de supprimer le plein texte avec la fiche il faudrait donc lui
indiquer ce qu'il doit faire.

Avec cette information supplémentaire, on peut alors imaginer d'utiliser
un second index ne contenant que le plein texte.

>> - Le crawling est-il incrémental ou bien toujours complet?
>> - Si le document associé à une fiche de metadata a déjà été crawlé
>> mais est modifié depuis ; sera-t-il mis à jour lors du prochain
>> crawling ? (je ne vois aucune référence à l'attribut
>> md-ori-oai-datestamp qui pourrait servir de repère par rapport à la
>> date de dernier crawling).

Non, la modification du document n'entraine pas de nouveau crawling.
On se base ici sur la fiche descriptive. Si elle est modifiée alors on
supprime le plein texte.

>>
>> - A-t-on un moyen de savoir si le crawling est terminé (à part
>> cliquer continuellement sur le bouton "Lancer le crawling") ?

Pour l'instant non.
Mais ceci devrait être créé dans une prochaine version du module.

A l'heure actuelle dans l'onglet "Visualisation de toutes les fiches",
il existe une colonne "crawled" qui indique si une fiche a été crawlée
ou non. Si des fiches sont encore à la valeur "no" c'est que le crawling
n'est pas terminé.

>>
>> - Peux-t-on arrêter le crawling sans couper le tomcat du module
>> d'indexation ? Je pose la question car lors du crawling de canal-u
>> j'ai mis la machine sur les genoux à cause du nombre d'io. Je
>> tournais à 30 de charge pendant plusieurs heures et du coup plus
>> aucun service n'était réactif :-(.

Non. Cette fonctionnalité serait très intéressante effectivement. Je
l'ajoute dans la liste de mes tâches à effectuer.

>>
>> - Sinon dans src/ori-oai-indexing-svn/properties/liusConfig.xml on
>> est passé entre les versions "1.1" et "1.4" de :
>> >> maxMergeDocs="100" optimize="true"/>
>> à
>> >> optimize="true"/>
>> Autant cela doit accélérer la recherche, autant l'indexation doit
>> être plus lente si j'ai bien compris l'utilité de ces paramètres.
>> Actuellement j'ai l'impression que les valeurs sont fixes. Il doit
>> être possible de modifier ces valeurs temporairement afin d'optimiser
>> les ressources cpu et le temps passé lors d'un moissonnage ou lors du
>> crawling.

Effectivement ces valeurs ont été modifiées pour améliorer les
performances à la recherche. Mais elles permettent aussi de conserver un
index "propre" durant l'indexation. Avec l'arrivée du crawling on ne
peut plus optimiser l'index après passage de la dernière fiche à
traiter. En modifiant ces valeurs on évite donc de se retrouver avec un
index qui n'a pas été optimisé depuis trop longtemps, quitte à perdre en
terme de performances à l'indexation.

Donc il faut préalablement une commande qui permette à l'utilisateur
d'optimiser son index quand il souhaite. Alors on pourra ensuite
imaginer d'avoir des valeurs qui permettent de meilleures performances à
la recherche.

>>
>> - La configuration des types de fichiers explorés (mimeTypes) se fait
>> dans le module d'indexation en mode texte
>> (properties/configIndexing.xml) ; pourtant cela aurait bien sa place
>> dans l'interface graphique du module de moissonnage.
>>

> Je pense que cette partie d'ihm doit être gérée par le module
> indexing, histoire de ne pas coupler abusivement les deux modules,
> mais que par contre cet onglet devrait en effet être intégré à l'ihm
> du moissonneur d'une façon ou d'une autre (par un lien, une iframe,
> une lytebox...)
> Cela fait partie des choses auxquelles on doit commencer à réflechir
> pour remembrer/interconnecter les ihm.
>
> A+
> François

>> - Est-il prévu de ne pouvoir lancer manuellement le crawler que sur
>> certains entrepôts ? Par exemple il pourrait arriver de vouloir
>> recrawler ses ressources locales en pleine journée sans vouloir faire
>> les autres entrepôts. Actuellement il semble que le crawler attaque
>> tous les entrepôts sauf ceux référencés dans la balise ,
>> mais on ne va pas couper le module d'indexation juste pour modifier
>> cette valeur temporairement...

Cette idée est également très intéressante et je mettrai en place cette
fonctionnalité dans une future version du module.

Je tiens à rappeler enfin que le système de crawling est encore très
jeune et qu'il y a beaucoup d'améliorations à y apporter. Il ne s'agit
là que d'une première version qui ne demande qu'à être perfectionnée.
Merci donc pour l'intérêt que vous portez au crawling.

Yannick

>>
>> À+

>
>

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

Haut

Options d'affichage des commentaires

Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur « Enregistrer les paramètres » pour activer vos changements.
Sujet clos
‹ Sujet précédent : outil statistiques Sujet suivant : Meilleure architecture ›