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

[Martin Sevigny]

Bonjour,

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.

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.

Pourquoi SDX ferait cela? Parce que le développeur lui a demandé
indirectement, c'est-à-dire il lui a demandé de le faire si l'index
dépassé une certain taille (espace disque) ou s'il y a plus d'un certain
nombre de documents.

On pourrait par exemple le faire ainsi:

<sdx:documentBase>
  <sdx:split size="500m" nbDocuments="500000"/>
  ...
</sdx:document>

Cela voudrait dire qu'un second index serait créé dès que le précédent
dépasse 500Mo ou contient plus de 500000 documents. Bon on pourrait
avoir une logique plus compliquée (et/ou...) mais je ne crois pas que ce
soit le plus important.

Si on indique cela dans un application.xconf, on n'a strictement rien à
faire d'autre pour en bénéficier ; tout le reste est transparent, la
base de documents a un seul identifiant, on la chercher de la même
manière, etc.

Derrière, que ferait SDX? D'abord, pour la recherche ou les listes de
termes, il ouvrairait un "multisearcher" plutôt qu'un "searcher", et un
"multireader" plutôt qu'un "reader". Ca ne cause pas un problème
particulier, il faut juste être certain que ces objets sont
réinitialisés lorsqu'un nouvel index doit être créé.

Pour l'indexation, et bien il indexerait toujours dans le "dernier"
index, le reste est pareil. Avant de commencer à indexer un lot de
documents, il vérifie si le dernier index dépasse pas les
caractéristiques indiquées ; si non, il les indexe dans celui-ci, si oui
il en crée un nouveau et il indexe dans ce nouveau, qui devient le
"dernier" ou l'index en cours.

Pour l'instant, nous avons identifié un seul aspect qui mérite une plus
ample réflexion... Les suppressions. En effet, lorsqu'on demande à une
base de documents SDX de supprimer un document, il doit l'enlever de
l'index Lucene. Aujourd'hui, pas de problème, il y en a un seul, alors
inutile de chercher...

Toutefois, s'il y en a plusieurs, comment faire pour savoir dans quel
index il se trouve? A mon avis, il y deux stratégies "naïves":

a) on fait une recherche dans chaque index et dès qu'on le trouve on le
supprime... S'il y a beaucoup d'index ce n'est pas très efficace.

b) je garderais l'identité de l'index Lucene qui contient un document
dans les "métadonnées SDX" (database) sur ce document. On a déjà
l'entrepôt, et donc on doit déjà chercher dans cette database lors d'une
suppression, il s'agit d'ajouter ce nouveau paramètre et d'en tenir
compte. Sauf que cela pose la question de la compatibilité, car pour
l'instant cette information ne s'y trouve pas. Donc il faudrait
peut-être une seconde stratégie si elle ne s'y trouve pas, c'est-à-dire
on les cherche un par un... Et évidemment, s'il y a un seul index, on ne
s'embête pas à vérifier tout cela...

Vous voyez une autre approche?

Voilà, en implémentant cela, nous ferons peut-être des découvertes qui
compliqueront les choses, mais je pense que ça tient la route. Des
idées? Des suggestions? Des problèmes que vous voyez déjà? Des objections?

A bientôt,

Martin Sévigny