sdx-developers
[Top][All Lists]
Advanced

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

Re: [sdx-developers] Plusieurs bases


From: Pierrick Brihaye
Subject: Re: [sdx-developers] Plusieurs bases
Date: Wed, 19 Jun 2002 16:51:54 +0200
User-agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3

Re,

Martin Sévigny wrote:

Imaginons une application d'un service public d'ampleur nationale ;-) qui dispose de... disons 22 documentBase.

Ici, je comprends que les 22 bases contiennent des documents différents.


Mmmmh. C'est plus délicat à mon avis. J'ai bien compris que, idéalement, il vaut mieux mettre N types de documents différents dans N bases, possibilité dont je ne vais pas me priver d'ailleurs :-)

Pour expliciter : les dossiers d'inventaire dans une base, la documentation sur les opérations d'Inventaire (en Docbook si tant est que je parvienne à en obtenir un jour !) dans une autre.

*Mais* dans une perspective de déploiement efficace, je pressens qu'il vaut mieux déployer 22 bases qu'une seule. Ma longue expérience me fait dire que c'est la meilleure façon de ne froisser personne et de créer de l'emploi :-) Sans compter le gain de performance : mieux vaut indexer 40 Mo sur 22 serveurs que 880 Mo sur un seul... et récupérer 22 "petits" lots de résultats qu'un "gros" tout seul (enfin... dans un monde idéal où tous la bande passante ne tend pas vers epsilon ; on en reparle à la fin de ce message).

J'oublie le terme "bases locales" pour considérer que tu veux dire l'une
ou l'autre des 22 bases propres à l'application dont on parle.


Cela permet, par exemple, d'offrir une formulaire de recherche avec des
cases à cocher pour laisser le choix à l'utilisateur. Et aussi de faire
des choses plus complexes.


On est d'accord.


Ou bien je ne comprends pas, ou bien tu ménages des choses ;-)


Qui sait ;-)) ?

> Pour le multilinguisme, explique-moi ce que tu veux atteindre comme
> objectif, parce que je ne te suis pas là-dessus (ni sur un précédente
> message d'ailleurs, mais j'avais oublié).


Tu as une collection de documents que tu indexes en 22 bases
différentes, mais chaque document est indexé (et stocké) une seule fois,
non?


Oui... mais ça, c'est l'approche "basique". Je m'explique :


J'ai des dossiers en français que je sais indexer suite à la remise d'un cahier des charges par un public (francophone) donné, les chercheurs d'Inventaire pour les nommer.

Ceux-ci ont une culture d'indexation très fine, pas forcément toujours pertinente selon moi, mais là n'est pas le problème. Pour prendre un exemple simple, SCLE n'est pas aussi intuitif qu'il y paraît : il mentionne un siècle de campagne de construction *principale*. Si on veut un siècle de datation *secondaire*, il faut utiliser SCLD. Passons sur l'opposition entre les deux qui, elle, est encore plus tordue...

Arrive un nouveau public, francophone ou non, avec sa demande particulière dont le déploiement sous SDX serait confié à une SSII pour qui on dira que l'index SCLED = SCLE | SCLD de l'indexation préexistante.

Là, j'ai plusieurs approches :

- on patche la documentbase d'origine en créant un index supplémentaire nommé SCLED : gros conflits en perspective avec le premier concepteur : il faudra qu'il partage sa feuille d'indexation, qu'il ouvre les ressources, etc. A supposer que cela se fasse sans heurts, il faut bien sûr relancer une indexation. C'est là que les 22 bases feraient ça mieux qu'une seule. - on crée une application spécifique (avec bases spécifiques ayant le fameux index SCLED... mais pas SCLE et SCLD) et, dans ce cas, les deux publics s'ignorent superbement : pas possible, étant donné la fragmentation en applis différentes, d'envoyer une requête en anglais, en français, sur SCLE, sur SCLD ou sur SCLED... sans compter le problème de la mise en forme des résultats, différente d'une appli à une autre probablement et potentiellement générateur de divergences. De but en blanc, cette approche me paraît pire que la précédente.

Ces deux premières approches sont compatibles avec SDX tel qu'il est dans le CVS.

- on mutualise autant que faire se peut, chacun restant néanmoins dans son rayon. Là, une base générique pourrait dispatcher la requête aux différents index, à charge pour eux de répondre ou pas : "pas d'index SCLED", "Sorry, I don't speak french"...

Mais bon, je suis d'accord avec toi que le design de l'application peut grandement masquer les architectures sous-jacentes... mais cela aura un prix (dans les deux sens du terme).


C'est sûrement prévu, mais ce n'est peut-être pas suffisant. Explique ce
que tu veux dire par indexation en N langues d'un même document.


Sans aller jusqu'à une traduction simultanée des documents à indexer, on pourrait utiliser des dictionnaires pour traduire les index dont le nombre de valeurs est plus ou moins clos : SCLE = "19e siècle" vs SCLE (multilinguisme "vrai") = "19e siècle/19th century" vs CENTURY ("pseudo-mutilinguisme") = "19th century".

C'est un problème différent. Si tu penses à une super-application qui
fait des recherches sur des bases de documents hébergées sur un autre
framework, alors il faudra utiliser des outils de type Web services (ou
API URL de SDX) qui seront ajoutés pour faire ce genre de multibase.


Pas forcément. Je pense plutôt à :

- *un* framework : bases du MCC
-- *une* appli : Inventaire
--- *des* bases : dossiers/documents (éventuellement en 22 exemplaires)
---- *des* repositories : XML CI, XML Docbook, images, fonds de carte...


Mais pour des raisons de performance (en recherche), moi je préconiserai
en général ce scénario :

- indexation dans une application (à une ou plusieurs bases, peu
importe) "nationale" des contenus locaux, mise à jour périodique de
cette indexation
- affichage des documents (une fois cherchés dans la base nationale)
directement depuis les applications locales ou depuis leur URL d'origine

De cette façon, les documents sont à jour, mais pas nécessairement les
index. Comme Google quoi.


J'ai bien compris et ce schéma me semble tout à fait fonctionnel. Mais ça fait, comme dit plus haut, une charge supplémentaire sur le design de l'application dont je me demande s'il elle ne sera pas trop forte.


Et avec une utilisation judicieuse des URLRepository, les documents ne
sont pas copiés...


On est d'accord.


Et c'est rapide : parce que faire une recherche dans 22 bases dispersées
dans autant de DRAC, Lucene ne le fera pas en 30ms et il ne faut pas lui
en vouloir ;-)


Là, je ne peux qu'être d'accord mais ça pose le problème du haut-débit au MCC. Soyons optimistes : ça ne peut que s'arranger.

A+


--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden




reply via email to

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