sdx-users
[Top][All Lists]
Advanced

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

RE: RE : RE : [sdx-users] Stratégie d'indexation / n ombre de bases


From: Emmanuel Bégué
Subject: RE: RE : RE : [sdx-users] Stratégie d'indexation / n ombre de bases
Date: Sun, 23 Feb 2003 18:54:54 +0100

> -----Message d'origine-----
> De la part de Martin Sevigny
> Envoyé : dimanche 23 février 2003 13:06


> Beaucoup de choses. C'est sous Windows, non? Ce sera pire sous Linux je
> crois.

Oui, windows xp Home Edition avec Fat 32; est-ce que ça dépend de l'OS,
du file system, ou des deux? Avez-vous des infos sur Solaris (la plate-
forme de production)?


> En fait, techniquement, SDX utilise Lucene pour plusieurs choses, dont
> ses index contenant toutes sortes d'informations internes. Et Lucene
> utilise beaucoup les ressources fichiers. Donc si on multiplie le nombre
> de bases et le nombre d'applications, les ressources utilisées finissent
> par être trop importantes. Ca m'étonne que ça arrive sous Windows, mais
> il fallait s'y attendre.

Est-ce que vous voulez dire que si on ouvre moins d'applications on peut
ouvrir plus de bases dans chaque application?


> La seule façon de corriger ce problème est de modifier l'architecture
> interne de SDX pour permettre d'autres types d'index internes que ceux
> de Lucene. Tout est prévu pour cela, mais ce n'est pas développé. Je
> vais faire la même réponse que pour les recherches par intervalles de
> dates : ça ne se résoud pas en quelques heures, mais on réfléchit à la
> solution.

D'accord, je comprends; c'est assez gênant pour nous puisque dans la
pratique ça ne nous laisse comme choix que de gérer un moins nombre de
bases plus grandes (donc des temps d'indexation plus importants); mais
bon on va essayer de faire avec. Avez-vous une idée de jusqu'où on peut
aller, concrètement?

Est-ce qu'en attendant qu'une solution soit développée, on ne pourrait
pas autoriser de se passer de file repository et de base d'utilisateurs,
(que notre application n'utilise pas), ce qui libérerait donc autant de
ressources disponibles pour des bases d'index?

Cordialement,
EB





reply via email to

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