RE : [sdx-users] Too many files open

[Martin Sevigny]

Bonjour,

> Merci pour cette super nouvelle!

Y a pas de quoi!

> -> la limite du nb de bases est repoussée vers quel nombre?

C'est toujours difficile de donner des limites en informatique
"moderne". Les limites théoriques (par exemple la taille maximale d'un
Hashtable en Java) du nombre de bases ne seront jamais atteintes, soit
parce qu'elles ne font aucun sens (je vois mal une application avec
2exp16 bases!) soit parce que des limites pratiques se présenteront bien
avant.

En théorie, la limite est donc la même qu'avec les "lookups" Lucene. En
pratique, elle est à mon avis nettement plus grande, et probablement
assez grande pour que l'on ne s'en inquiète pas. Mais ça reste à être
confirmé par la pratique.

> -> les fichiers du SGBD sont-ils portables d'un OS à l'autre?
>    (pour indexer sur une machine puis copier les index et chercher
>    sur une autre machine)

Oui. Nous avons implanté cette première mouture des lookups "SGBD" avec
HSQL pour deux raisons:

1) Pas besoin d'uns installation particulière (seul un JAR faisant
partie de la distribution SDX)
2) SGBD 100% Java qui présente notamment la caractéristique d'avoir des
données portables d'une plate-forme à l'autre (ceci étant dit, ce ne
sont pas seulement les SGBD Java qui présentent ces caractéristiques)

> -> qu'est-ce qui est stocké par le SGBD vs. ce qui est toujours
>    stocké par Lucene (est-ce que par exemple les urls sont stockées
>    en base, ce qui pourrait vouloir dire qu'on pourra les mettre à
>    jour sans réindexer?)

Les "index de recherche" (là où vous faites des <sdx:execute*Query/>)
sont toujours gérés par Lucene (pour l'instant aucun autre moteur de
recherche n'est offert par SDX). Ensuite, les "index internes" à SDX
(lookups) sont gérés soit par HSQL, soit pas Lucene, selon le
<sdx:database> que vous utilisez (ou la valeur par défaut).

Donc si vous avez un entrepôt URL qui contient un <sdx:database
type="HSQL"/>, alors les relations entre un identifiant de document et
son URL (ce que SDX gère dans le lookup pour un entrepôt de ce type)
seront dans la base de données HSQL. Vous pouvez donc y accéder à partir
de n'importe quel outil qui peut manipuler des bases de données HSQL,
par exemple l'interface graphique livrée avec HSQL lui-même ou l'un des
nombreux GUI pour bases de données JDBC.

Evidemment, si vous faites cela, c'est à vos risques et périls ;-)

Votre exemple (modifier les URL) et ce que vous nous avez déjà dit sur
le fait que vous n'utilisiez pas d'entrepôt (en fait vous n'en avez pas
besoin) m'incitent à répéter une particularité intéressante des
entrepôts URLs.

SDX ne stocke pas nécessairement l'URL complète (absolue) des documents,
il peut aussi stocker l'URL relative à une certaine base. Si, par
exemple, vos documents sont tous situés à quelque part sous
http://www.monserveur.com/mesdocuments/ (ou file:///usr/local/docs/,
c'est pareil), vous pouvez déclarer un entrepôt URL ainsi:

<sdx:repository type="URL"
base="http://www.monserveur.com/mesdocuments/";>
  <sdx:database type="HSQL"/>
</sdx:repository>

Dans ce cas, lorsqu'on ajoute à cet entrepôt, par exemple, un document
dont l'URL est http://www.monserveur.com/mesdocuments/doc1.xml, alors
SDX mettra dans son "lookup" la valeur "doc1.xml". Ainsi, si un jour
vous déplacez vos documents dans
http://www.monserveur.com/mesnouveauxdocuments/, vous n'aurez pas besoin
de réindexer, vous aurez juste à:

- modifier le application.xconf pour mettre
base="http://www.monserveur.com/mesnouveauxdocuments/";
- reconfigurer votre application (interface d'admnistration) ou
redémarrer Tomcat/SDX

Evidemment, cela suppose que sous votre URL de base, les documents
restent organisé de la même façon. Donc si par "modifier les URLs" vous
pensez à ce genre de manipulations (par exemple déplacer vos 20000
fichiers XML ailleurs sur votre disque), vous pouvez peut-être
bénéficier des entrepôts SDX ;-)

Si c'est autre chose, peut-être que quelqu'un d'autre va bénéficier de
ces explications...

A bientôt,

Martin Sévigny