sdx-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[sdx-developers] RE : SDX 2 : implantation des entrepots de documents


From: Martin Sévigny
Subject: [sdx-developers] RE : SDX 2 : implantation des entrepots de documents
Date: Sat, 23 Mar 2002 10:31:06 +0100

Salut,

> > Moi aussi je pense. Je me rappelais de tes commentaires à 
> ce sujet, et
> > j'ai hésité un peu, mais finalement j'ai trouvé que ça m'était plus
> > naturel de le faire en entrepôts. Les documents, je voulais 
> les garder
> > indépendants de la notion de stockage. Mais bon, je crois 
> que les deux
> > approches se défendent.
> 
> 
> Si j'ai dit ça, c'est que ça permet d'avoir un niveau 
> d'abstraction plus 
> grand et, par exemple, de sérialiser/désérialiser au niveau des 
> documents qui resteraient ainsi l'une des grandes unités 
> "atomiques" de 
> SDX. Ceci permettrait par exemple de proposer un jeu d'API pour des 
> outils de production ;-) qui devraient tout de même respecter 
> l'interface ad hoc de SDX et d'ignorer superbement toute 
> l'infrastructure sous jacente.

OK, je vois mieux l'intérêt. Bonne idée, je crois que je vais garder les
entrepôts tels que proposés et que l'on va ajouter des méthodes aux
documents pour qu'ils puissent eux-mêmes se sérialiser dans un entrepôt.
Mais l'indexation? Je pensais la gérer au-dessus des entrepôts, dans un
DocumentBase...

> Je pense essentiellement à la gestion des résultats. Voici 
> comme je vois 
> les choses :
> 
> - Récupération du résultat Lucene
> - Mapping sur un SGDB (puis libération rapide de l'objet fourni par 
> Lucene qui peut être très lourd)
> - A partir de là le SGDB gère les résultats, en particulier 
> le *tri* et 
> ne renvoie au client que ce qu'il a demandé.

Ah... Là je comprends où tu veux en venir...

> Le SGDB propose *nativement* (au moins, on l'espère) une gestion 
> optimale de la mémoire, du caching, voire un déport sur un autre 
> processeur ou une autre machine... C'est là que l'on peut 
> trouver de la 
> performance. A moins d'avoir à gérer un code très lourd de 
> threading et 
> de ramasse-miettes, *je* ne vois pas comment on pourrait faire 
> autrement, au moins pour une version 2.

D'accord. Ce serait donc un éventuel ajout à SDX pour permettre de
meilleures performances. Il faudra penser la nouvelle architecture dans
ce sens, mais pour l'instant j'avoue que ce n'est pas une priorité de
notre côté.

A bientôt,

Martin Sévigny




reply via email to

[Prev in Thread] Current Thread [Next in Thread]