Bonjour,
Cet élément est pris en compte depuis SDX 2.1. Cf. fr.gouv.culture.sdx.application.Application.configureDefaultDatabaseType(Configuration configuration)
Je me permets de renvoyer le contenu d'un message de 2004 rédigé par Martin Sévigny sur le sujet (je ne l'ai pas retrouvé dans les archives de sdx-users).
André Davignon -------------------------------------------------------------- Bonjour, Je reviens sur ce problème. Pour rappel, André Davignon a une application avec 50 000 petits documents (références bibliographiques), et il constate que la suppression est très lente: ----- requête avec 5 réponses, puis suppression : temps de réponse 1min. une requête avec 107 réponses, puis suppression : temps de réponse entre 25 et 30 min. ----- J'ai récupéré son application et ses données. J'ai installé cela sur ce SDX: http://www.ajlsm.com/download/sdx-22.war qui, pour rappel, est le CVS du 20 octobre en branche 2.2, donc pas très loin de la 2.2.1 qui sortira bientôt. Autres infos techniques: Windows XP sur un ordinateur portable au disque plutôt lent, Tomcat 5.0.28, Java 1.4.2_03. J'ai indexé les 49232 documents en 5 lots de 10000 (sauf le dernier...), ce qui a pris un total de 17 minutes et 9 secondes. Ensuite je me suis amusé à supprimer des documents (c'est ça le but) pour voir ce que ça donne... ... et c'est ce que je croyais: aucun problème. De l'ordre d'une seconde ou deux, voire 4, que ce soit 1, 10 ou 100 documents à la fois. Normal que ce soit semblable, ce qui prend du temps c'est la réoptimisation des index et là ça ne change pas. J'ai tout de même fait une modification à son application, et elle est peut-être significative. Celle-ci utilisait un entrepôt "FS" (filesystem), donc "système de fichiers", ce qui signifie que SDX copie le fichier et le gère lui-même, dans une hiérarchie de dossiers. Personnellement, je n'ai même pas osé l'essayer sur mon ordinateur, je sais par expérience que ce n'est pas très efficace. Et les entrepôts SDX ne sont pas faits pour gérer un tel nombre de documents. Donc premier conseil: utiliser les entrepôts FS uniquement pour de petites bases, voire pour des tests. J'ai utilisé un entrepôt MySQL: <sdx:repository type="MYSQL" dsi="identifiant de la connexion"/> Deuxième modification: les métadonnées associées à différents objets (entrepôts, bases de documents, ...) sont gérés à l'aide d'une base de données relationnelle par SDX. Par défaut, c'est HSQLDB qui est utilisé, et les données sont dans conf/databases/_hsql. Là aussi c'est pas trop mal, mais pour de grands volumes je préfère confier cela à MySQL. Je n'ai pas testé avec HSQLDB l'application qui nous concerne ici, donc je ne sais pas si c'était réellement un facteur... Pour faire le changement, vous insérez cette ligne dans l'élément racine du application.xconf: <sdx:database type="MYSQL" dsi="identifiant de connexion"/> où l'identifiant de connexion est bien sûr défini dans le cocoon.xconf. J'ai utilisé la même base de données MySQL que pour l'entrepôt. Bref, avec ces deux changements, tout fonctionne normalement. On peut donc conclure que SDX peut gérer parfaitement de telles quantités de données, y compris en suppression. Maintenant, il faudrait qu'André fasse les mêmes changements pour voir si ça règle son problème. Si oui, alors c'est bien cela, si non, alors il y a un autre goulot d'étranglement qui est bien extérieur à SDX. Il y a Dave Castonguay qui avait, je crois, des problèmes similaires. Est-ce que c'est possible de faire les mêmes changements de configuration? En gros, voici comment procéder. 1) Installez MySQL, si vous n'avez pas déjà un accès défini 2) Créez une base de données sur ce serveur MySQL, et ayez au moins un utilisateur qui a tous les droit sur cette base. Je vais supposer que le nom de la base est "sdx", l'utilisateur est "sdx" et le mot de passe "sdx" pour le reste... 3) Dans le cocoon.xconf, répérez la ligne où c'est inscrit "datasources" en commentaires, si vous n'avez jamais configuré des sources données JDBC alors il n'y a rien d'autre que ce commentaire. 4) Inscrivez ceci sous cette ligne: <datasources> <jdbc name="ma_db" logger="sdx.rdbms.ma_db"> <pool-controller min="5" max="10"/> <dburl>jdbc:mysql://localhost:3306/sdx?autoReconnect=true</dburl> <user>sdx</user> <password>sdx</password> </jdbc> </datasources> 5) Dans le fichier WEB-INF/web.xml, vous devez avoir ces lignes (non commentées): <init-param> <param-name>load-class</param-name> <param-value> org.gjt.mm.mysql.Driver </param-value> </init-param> Voilà, c'est tout je crois. Redémarrez Tomcat bien sûr pour bien relancer tout cela. Vérifiez les logs pour être certain que rien n'a été oublié. A bientôt, Martin Sévigny _______________________________________________ sdx-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/sdx-users _______________________________________________ sdx-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/sdx-users
