RE: [sdx-developers] Fragmenter une base de documents et un index Lucene

[Emmanuel Bégué]

Bonjour,

> -----Message d'origine-----
> De la part de Martin Sevigny
> Envoyé : jeudi 15 juillet 2004 08:59

> Aujourd'hui dans SDX, une base de documents = un index Lucene,
> conceptuellement mais aussi dans son implémentation.
>
> Même si dans sa conception ce modèle est encore tout à fait valable,
> dans son impémentation nous pouvons rencontrer certains problèmes.
>
> Par exemple, pour une application sur laquelle nous avons travaillé,
> l'index est rendu très gros (plusieurs centaines de Mo), et nous avons
> fini par créer une seconde base de documents, identique à la première,
> uniquement pour avoir un index plus petit et ainsi accélérer les mises à
> jour. Les deux bases de documents sont systématiquements recherchées en
> même temps, il n'y a vraiment aucune justification fonctionnelle à cela.

Oui on fait ça aussi pour La Croix, on met le "stock" dans un index
et le "flux" (les documents de l'année en cours) dans un autre.


> Notre proposition est de rendre une telle "fonctionnalité" transparent à
> un développeur SDX, c'est-à-dire qu'à un certain moment SDX déciderait
> lui-même de créer un second index Lucene, et ce pour une même base de
> documents.

J'ai l'impression que ça représente beaucoup de travail du côté de SDX
pour un bénéfice pas très évident du côté du développeur d'applications,
qui "perd" le contrôle de ce qu'il met dans quel index (s'il utilise
la fonctionnalité, ce qu'il n'est évidemment pas obligé de faire).

Est-ce que le jeu en vaut la chandelle?

La seule chose un peu lourde dans la configuration actuelle c'est
de devoir répéter la liste des champs d'une base à une autre: si on
pouvait nommer la fieldlist et y faire référence dans application.xconf,
de mon point de vue ça serait largement suffisant... ;-)

Cdt,
EB