Discussion :

[Bruno13]

Bonjour à tous,

Je dois débuter un projet dans lequel on me fournit des données XML afin de pouvoir les interroger via le Web avec un Service RESTFul avec des requêtes booléennes du genre TI=((airplane and waepon) or car).

Je dois reproduire le service http://ops.epo.org/rest-services qui héberge des données brevets. En fait nous comptons acquérir les données DocDB14.7 pour éviter de se connecter continuellement sur leur service et être ainsi indépendant.

Un jeu de données test est fourni sur le lien dans la section download: http://www.epo.org/searching/subscri...duct-14-7.html

Je sais qu'ils utilisent Linux+Apache+JBossWeb

J'ai donc pour mes tests un serveur Linux Ubuntu+Apache + le jeu de données mais voilà à ce niveau là je sèche car totalement novice dans le domaine des Bdd et Java.

Ma première question est donc: Quelle BDD ?

Il y aura env. 40Go de données + 50 Mo chaque année suivante
Pour environ 1000 utilisateurs sur un an. Je ne connais pas la fréquence d'interrogation.

Est-ce que quelqu'un peut me conseiller, m'aider à arriver à interroger mes données via le WEB?

D'avance merci pour vos conseils,
Amicalement,
Bruno

[StringBuilder]

Vu la volumétrie, n'importe quelle base fera l'affaire, dans la mesure où tu as très peu d'accès concurrentiels (1000 connexions par an, c'est très léger).

Il faut donc te concentrer sur les fonctionnalités du moteur.

Donc exemple n'est pas très clair "IT=((airplane and weapon) or car)"
=> Ca veut dire que le champ "it" doit être égal à airplane et weapon ou car ?

En effet, si tu as besoin par exemple de faire des recherches fulltext, tu devras t'orienter vers un moteur qui les gère.

En tout cas, sans trop prendre de risque, tu dois pouvoir prendre PostGreSQL ou MySQL. Oracle XE peut être intéressant si vous avez déjà du Oracle dans votre parc. En tout cas, la même règle d'or s'applique que d'habitude : quel SGBD utilisez-vous actuellement pour les autres outils ? S'il convient, alors il est tout désigné : cela permettra de mutualiser les compétences, et éventuellement les licences/serveurs

[Bruno13]

Bonjour et merci pour ta réponse,

Vu la volumétrie, n'importe quelle base fera l'affaire, dans la mesure où tu as très peu d'accès concurrentiels (1000 connexions par an, c'est très léger).

petite information supplémentaire, je dirai 30 à 50 consultations par jour pour les jours de "grande affluence"

Il faut donc te concentrer sur les fonctionnalités du moteur.

Donc exemple n'est pas très clair "IT=((airplane and weapon) or car)"
=> Ca veut dire que le champ "it" doit être égal à airplane et weapon ou car ?

Oui c'est exactement ça IT étant le champ "Internal Title". Il y a dans les fichiers XML bien sûr beaucoup d'autres "champs", comme par exemple PD pour "publication date", ou CC pour "Country Code", etc...

En effet, si tu as besoin par exemple de faire des recherches fulltext, tu devras t'orienter vers un moteur qui les gère.

Ce n'est pas le taf de JBoss Web et des "truc" en Java que l'on doit développer?

En tout cas, sans trop prendre de risque, tu dois pouvoir prendre PostGreSQL ou MySQL.

MySQL sait gérer des volumes de 50Go ? et du fichier XML ?

Oracle XE peut être intéressant si vous avez déjà du Oracle dans votre parc.

Non, pas d'Oracle, et en plus ça coute un bras non Oracle ?

En tout cas, la même règle d'or s'applique que d'habitude : quel SGBD utilisez-vous actuellement pour les autres outils ? S'il convient, alors il est tout désigné : cela permettra de mutualiser les compétences, et éventuellement les licences/serveurs

Aucun SGBD chez nous, première fois qu'on en a l'utilité d'où mon incompétence et personne chez nous qui sait faire...

[StringBuilder]

Bonjour et merci pour ta réponse,

De rien, on est là pour ça

petite information supplémentaire, je dirai 30 à 50 consultations par jour pour les jours de "grande affluence"

C'est bien ce que je dis. Avec 30 à 50 consultations par seconde, là tu pourrais commencer à te poser la question du moteur de base de données et de la montée en charge. Mais là, même avec un bête fichier plat que tu parserais comme un porc dans un script shell, ça poserait pas de problème de performances.

Oui c'est exactement ça IT étant le champ "Internal Title". Il y a dans les fichiers XML bien sûr beaucoup d'autres "champs", comme par exemple PD pour "publication date", ou CC pour "Country Code", etc...

Ca semble donc pouvoir se traduire facilement en langage SQL.
Eventuellement, si un SGBD supporte le language que tu cites, ça t'éviteras de traduire le message. Mais bon, autant rester standard et convertir la requête en SQL. Donc je confirme, n'importe quel SGBD fera l'affaire.

Ce n'est pas le taf de JBoss Web et des "truc" en Java que l'on doit développer?

Non, ton webservice devra traduire la requête passée en paramètre pour interroger la base de données. Les recherches fulltext se font directement par le moteur de la base de données. Mais dans ton cas précis, je ne suis pas certain que ça te soit utile. Pour rappel, fulltext permet de faire des recherches dans du contenu kilométrique avec une méthode "à la google" : recherche des occurences dans le champ lexical, etc.

MySQL sait gérer des volumes de 50Go ? et du fichier XML ?

Normalement, oui. Cependant, MySQL n'est pas forcément le meilleur choix. PostGreSQL me semble plus judicieux, car plus standard, et réellement GNU.

Non, pas d'Oracle, et en plus ça coute un bras non Oracle ?

Pas Oracle XE, qui est gratuit. En revanche, je crois que c'est limité en taille, et c'est moins de 50 Go (t'es sûr des 50 Go ?)

Aucun SGBD chez nous, première fois qu'on en a l'utilité d'où mon incompétence et personne chez nous qui sait faire...

Donc vous êtes libres. PostGreSQL me semble judicieux. Sous Windows, je t'aurais conseillé SQL Server (mais à nouveau, les versions Express ne supportent pas 50 Go).
PS : J'insiste quand même... C'est bien 50 Go ?
A raison d'une croisssance de 50 Mo par an, ça veut dire que pour arriver à 50 Go, on a historisé des brevets pendant 1000 ans ? (??????)

[Bruno13]

Salut et merci encore pour tes réponses,

C'est bien 50Go mais depuis mon dernier mail les infos ont changé sur leur site internet:

Frontfile: approx. 1 GByte
Backfile: approx. 53 GBytes

Voici le lien où il y a un exemple de XML:
http://www.epo.org/searching/subscri...duct-14-7.html

Un responsable technique de chez eux vient de m'appeler, c'est cool car je vais pouvoir avoir des infos plus précise sur ce qu'ils ont...ou peut être pas...

Je vous tiendrais informé.

[Bruno13]

Pour clôturer ce post voici la solution que j'ai choisi et qui est vraiment très performante: Solr.

Amicalement,
Bruno