Discussion :

[Raz-X]

Bonjour à tous,

je travaille actuellement sur un projet d'entreprise visant à reconstruire une application existante dans le but d'étendre son activité à l'international. Le SGBD actuellement utilisé est mySQL, mais ce système n'est pas très scalable et ne correspond plus aux attentes.

L'application tournera majoritairement autour du XML (en particulier pour le transfert de données). C'est une application orientée SaaS.

Je recherche un SGBD distribué (type Cassandra) qui pourrait idéalement gérer du XML en natif (à la manière d'eXist). J'ai recherché des bases de données distribuées XML, mais les solutions trouvées sont peu (pas) maintenues et présentent donc un risque à moyen/long terme pour l'entreprise en terme de développement.

Connaissez-vous un SGBD qui pourrait correspondre aux besoins de l'application ?
Cassandra peut-il gérer assez simplement du XML avec son DataModel spécifique ?

N'hésitez pas à commenter et à apporter votre avis.
Merci d'avance.

[SQLpro]

SQL Server me parait le bon choix dans le sens ou :
1) pour le XML
- il est stocké de manière typé et validable par des collections de schémas XML
- il est indexable (par valeur, path ou attribut)
Voir l'article de Rudi Bruchez sur le sujet : http://rudi.developpez.com/sqlserver/tutoriel/xquery/

2) pour la distribution des données, il existe Service Broker
- c'est un outil de messagerie de niveau data entre serveur SQL basé sur des Web Services et http.
- il est fiable (table SQL servant de file d'attente) sécurisé (transport crypté et accès par certif) et transactionné
- c'est performant car asynchrone
J'ai personnellement mise en œuvre cela notamment dans le domaine pharmaceutique (tracabilité) et la SNCF l'utilise à grande échelle

Vous pouvez même utiliser ces deux outils dans la version gratuite de SQL Server Express 2008 R2. Seule limitation : la taille des bases (max 10 Go), mais pas de limite en nombre !

A titre d'exemple, l'article que j'ai écrit sur SB :
http://blog.developpez.com/sqlpro/p7...ervice-broker/

A +

[Raz-X]

Merci de cette réponse constructive.

Je me suis renseigné un petit peu sur Service Broker, si je ne me trompe pas, c'est une forme un peu détournée pour faire du distribué avec plusieurs serveurs SQL. L'idée est intéressante.

Cependant, ce système permet-il de faire de la réplication, du load balancing, du fail over (je ne pense pas)? Ou cela est-il pris en compte dans une version payante? Doit-on passer à un système de cluster pour obtenir ces caractéristiques?

[SQLpro]

Service broker peut être utilisé pour dire de la réplication, mais cela n'est pas son rôle primale. Pour faire de la réplication SQL Server dispose de 5 techniques différentes :
- réplication transactionnelle
- réplication point à point
- réplication snapshot
- réplication de fusion
- réplication avec Oracle

La réplication est un moyen de faire du load balancing, mais il en existe d'autres, comme les vues partitionnées ou la couche système de Windows (Windows Network Load Balancing).

Pour la haute dispo on peut aussi utiliser SB, mais là c'est loin d'être ça vocation. Il existe 3 moyens de faire de la haute dispo dans SQL Server :
- log shipping (asynchrone)
- mirroring de bases de données (asynchrone ou synchrone)
- clustering (synchrone)

A +

[Raz-X]

Merci pour ces précisions.

Pour notre application, la réplication de données est importante pour la sauvegarde des données clients. Le load balancing serait optionnel, mais intéressant toutefois.

Notre but est de déployer une base de donnée au plus prêt du client, contenant les informations dont il se sert pour sa supervision (en temps réel). Les données sont alors acheminées rapidement vers le client, et l'aspect distribué de l'ensemble des bases nous permet à nous, distributeurs du service, d'assurer la réplication des données et bien-sur d'avoir une vue globale des bases clients interconnectées.

L'utilisation du XML est un choix majeur de notre projet, nous souhaitons donc si possible que notre base prenne en charge nativement le XML, avec si possible une interface SQL/XML XQuery pour une interrogation puissante de la base.

Le prix de cette installation est aussi important, dans l'idéal une licence opensource serait préférable, ou au pire des cas, une licence peu contraignante tant sur le plan des libertés que sur le plan financier/économique.

Ce type de solution est peut-être irréaliste, et il faudra surement faire des concessions, ou bien développer en interne notre propre système, mais je tiens à récupérer les conseils avisés de la communauté avant de prendre une décision.

[Waldar]

Quel serait la volumétrie des échanges XML ?

Ne vous attendez pas non plus à quelque chose d’extrêmement performant, c'est impossible avec le XML.

Le XML c'est bien pour des messages courts, mais pas pour des échanges massifs de données.

[Raz-X]

La volumétrie des échanges n'est pas très importante, la taille de la ou des base(s) ne devrait pas être trop importante dans un premier temps, mais pourrait très vite grandir dans les années à venir. Les échanges dépendront d'une nombre de clients à gérer par la base, mais globalement la base sera plus souvent écrite que lue (le superviseur vient maintenir le XML à jour, alors que les clients ne lisent les données que lorsqu'il y a un changement les concernant).

[SQLpro]

Pour notre application, la réplication de données est importante pour la sauvegarde des données clients.

Le but de la réplication n'est pas non plus pour faire de la sauvegarde de données. pour faire de la sauvegarde il existe... la sauvegarde !

Notre but est de déployer une base de donnée au plus prêt du client, contenant les informations dont il se sert pour sa supervision (en temps réel). Les données sont alors acheminées rapidement vers le client, et l'aspect distribué de l'ensemble des bases nous permet à nous, distributeurs du service, d'assurer la réplication des données et bien-sur d'avoir une vue globale des bases clients interconnectées.

J'ai du mal à vous suivre....
Essayons d'y voir clair :
1) vous avez de nombreux clients (par exemple 5 000) qui doivent avoir une base de données locales installée sur leur machines (mettons 10 machines par client)
2) ces clients enrichissent la base par des données collectées au fil de l'eau
3) chez vous, vous avez un serveur central qui doit être alimenté régulièrement par les données de vos clients
4) se pose donc le problème de l'acheminement des données entre les machines de vos clients et votre serveur centralisé.
EST-CE BIEN CELA ?

L'utilisation du XML est un choix majeur de notre projet, nous souhaitons donc si possible que notre base prenne en charge nativement le XML, avec si possible une interface SQL/XML XQuery pour une interrogation puissante de la base.

Si tel est le cas, alors SQL Server et Service Broker est parfaitement indiqué :
1) installer sur chaque poste client une version gratuite de MS SQL Server (SQL Server Express 2008 R2)
2) installer chez vous une version plus costaude comme la Standard ou l'enterprise. Tout dépend du volume des données :
2.1 - si dans les 3 à 5 ans vous ne dépassez pas quelques centaines de Go, la standard est OK
2.2 - si dans les 3 à 5 ans vous envisagez d'atteindre le To, alors mieux vaut prendre la version Enterprise (et le serveur qui va avec).
2) la mise en œuvre de service broker est délicate sur le plan de la sécurité (car elle est fortement verrouillée : cryptage + authentification, puisque les données vont transiter sur le net...)
3) SQL Server intègre XQuery et XPath pour faire des requêtes SQL/XML.

Le prix de cette installation est aussi important, dans l'idéal une licence opensource serait préférable, ou au pire des cas, une licence peu contraignante tant sur le plan des libertés que sur le plan financier/économique.
Le type de solution est peut-être irréaliste, et il faudra surement faire des concessions, ou bien développer en interne notre propre système, mais je tiens à récupérer les conseils avisés de la communauté avant de prendre une décision.

Entre le prix d'une licence pour votre serveur interne et 6 mois d'un développement peu fiable, y'a pas photo.
Sachez que pour mettre en œuvre une solution comme celle que j'ai décrit, il m'a fallu 2 jours de boulot, automatisation de l'installation cliente comprise !

Mais il est important soit de vous former à SB et XQuery/XPath dans SQL Server, soit à prendre quelques jour de conseil (un à deux jours devrait suffire) - le mieux étant la formation (voire même à la carte) car c'est pris en charge par votre OPCA (donc rien à débourser !)

Pour votre information, voici les 3 ouvrages que je vous conseille pour vous documenter :
Amazon.com: Pro SQL Server 2008 Service Broker (Books for Professionals by Professionals) (9781590599990): Klaus Aschenbrenner: Books@@AMEPARAM@@http://ecx.images-amazon.com/images/I/51T7uPaspOL.@@AMEPARAM@@51T7uPaspOL
Pro SQL Server 2008 XML Hardback: Amazon.co.uk: Michael Coles: Books@@AMEPARAM@@http://ecx.images-amazon.com/images/I/51laHrRHIpL.@@AMEPARAM@@51laHrRHIpL
SQL Server 2005 Practical Troubleshooting: The Database Engine: Amazon.co.uk: Ken Henderson Editor: Books@@AMEPARAM@@http://ecx.images-amazon.com/images/I/414AERJ5BEL.@@AMEPARAM@@414AERJ5BEL
Ce sont les 3 qui m'ont servi pour mettre en œuvre SB dans différentes situations pour quelques un de mes client !

A +

[vmolines]

Le but de la réplication n'est pas non plus pour faire de la sauvegarde de données. pour faire de la sauvegarde il existe... la sauvegarde !
J'ai du mal à vous suivre....
Essayons d'y voir clair :
1) vous avez de nombreux clients (par exemple 5 000) qui doivent avoir une base de données locales installée sur leur machines (mettons 10 machines par client)
2) ces clients enrichissent la base par des données collectées au fil de l'eau
3) chez vous, vous avez un serveur central qui doit être alimenté régulièrement par les données de vos clients
4) se pose donc le problème de l'acheminement des données entre les machines de vos clients et votre serveur centralisé...

A partir de ces besoins, comment se fait-il que la réplication de fusion ne soit pas le choix tout indiqué ?