[Choix SGBD] Demande de conseils

[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]

Envoyé par Raz-X

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 :
http://www.amazon.com/Server-Service-Broker-Books-Professionals/dp/1590599993/ref=sr_1_1?s=books&ie=UTF8&qid=1303202237&sr=1-1http://www.amazon.co.uk/Pro-SQL-Server-2008-Hardback/dp/1590599837/ref=sr_1_2?ie=UTF8&s=books&qid=1303202335&sr=8-2http://www.amazon.co.uk/SQL-Server-2005-Practical-Troubleshooting/dp/0321447743/ref=sr_1_7?s=books&ie=UTF8&qid=1303202372&sr=1-7Ce sont les 3 qui m'ont servi pour mettre en œuvre SB dans différentes situations pour quelques un de mes client !

A +

[vmolines]

Envoyé par SQLpro

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é ?

[SQLpro]

Là j'en tombe des nues !!!!

la réplication de fusion n'a d'intérêt que si elle est bilatérale. De plus elle soufre de tares congénitales inhérente au principe de dualité de l'information :
que se passe t-il si 2 personnes sur deux serveurs différents modifient les données de la même ligne au même moment ?
=> conflit de réplication (qui est le lot quotidien de ce mode)
Il faut donc en sus écrire manuellement des règles de gestion des conflits pour résoudre ces problèmes, sous peine de voir rapidement la table tombstone saturé de lignes de conflits (je me rappelle avoir été en 2001 faire du conseil en réplication et trouver la table tombstone chez le client remplie de 120 millions de lignes.... j'ai donc annoncé qu'il fallait résoudre les conflits en regardant les lignes une à une et en indiquant quelle version devait être acceptée au final... bref, du travail jusqu'à la retraite !!!)

En sus tous les mécanisme de réplication de données font que l'information circule en clair dans le système. C'est fait pour un SI interne, pas pour du WAN ! Si l'on doit rester discret avec ces données, il faut en sus prévoir un
cryptage, décryptage...

En sus toutes les réplications sont très couteuses en terme de ressources. dans l'exemple précité, la personne répliquait toutes les tables de 120 bases sur 3 serveur dans le monde (france, indes, USA) et cela en "dès que possible" (c'est à dire sans temps de latence). Bilan, les CPU étaient utilisés à 99% et le service des données très fortement ralentit (c'était sur un très gros serveur....)

C'est pourquoi les réplication ne sont généralement pas synchrone !
En revanche SB, même s'il n'est pas synchrone est au fil de l'eau et très rapide (quelques centaines de ms en général).

Enfin, la mécanique de réplication est complexe car fortement distribuée (source + cible + distribution) ce qui fait que la fiabilité est nettement moins bonne (en particulier qaund un serveur pète, si l'on a pas pris la précaution de tout scripter, alors il faut tout remettre en place...

Pour finir, mis à part la réplication transactionnelle, les autres mode de réplication ne sont pas transactionné, ce qui veut dire que les données répliquées peuvent rendre la base non intègre !

Sache que lorsque j'interviens en conseil sur la réplication, je met mon tarif maximal : 2500 euros jour... ! De manière à dissuader ce genre de pratique, car dans 90% des cas on peut allègrement s'en passer !

A +

[Raz-X]

A vrai dire, la complexité de notre application réside dans le fait que chaque client ne possède pas le même contrat qu'un autre, et à des accès à notre système différent.

Par exemple, un client souhaitera superviser des données internes à son entreprise, et ne souhaitera pas les divulguer, alors qu'on autre ira placer ses données directement sur nos bases et choisira alors de décentraliser ses données afin que nous les gérions.

Sur le plan de l'architecture, c'est assez difficile d'imaginer la manière de déployer mes bases de données dans le monde. Voilà en gros comment je vois les choses (de manière simple) pour le moment pour essayer d'être plus clair:

- Je déploie une base de données par continent, c'est à cette base que mes clients sur ce continent auront à faire.
- Mes clients décident (ou non) d'utiliser cette base pour y stocker les données qu'ils souhaitent superviser avec notre système.
- Si ils décentralisent leurs données sur nos serveurs, nous en devenons responsables, et devons donc assurer la non perte de ces données, grâce à la réplication (sur les bases des autres continents par exemple).
- Si ils décident de garder leurs données en interne, il faut que le système soit capable d'assurer la supervision de ces données même si notre entreprise n'a pas directement accès à leur base.

Notre système de supervision fait la liaison entre le client et la donnée.
Globalement, notre entreprise garde la gestion des bases que nous avons déployées sur les différents continents, et bien-sûr la gestion du service de supervision proposé au client.

La réplication de bases est-elle possible via le WAN en natif sous SQL Server? avec SB (dont je n'ai pas trop compris le principe j'avoue)?

J'avoue que PostgreSQL m'attire pas mal, mais la gestion du XML en natif manque cruellement.

[SQLpro]

Envoyé par Raz-X

A vrai dire, la complexité de notre application réside dans le fait que chaque client ne possède pas le même contrat qu'un autre, et à des accès à notre système différent.

Par exemple, un client souhaitera superviser des données internes à son entreprise, et ne souhaitera pas les divulguer, alors qu'on autre ira placer ses données directement sur nos bases et choisira alors de décentraliser ses données afin que nous les gérions.

Sur le plan de l'architecture, c'est assez difficile d'imaginer la manière de déployer mes bases de données dans le monde. Voilà en gros comment je vois les choses (de manière simple) pour le moment pour essayer d'être plus clair:

- Je déploie une base de données par continent, c'est à cette base que mes clients sur ce continent auront à faire.
- Mes clients décident (ou non) d'utiliser cette base pour y stocker les données qu'ils souhaitent superviser avec notre système.
- Si ils décentralisent leurs données sur nos serveurs, nous en devenons responsables, et devons donc assurer la non perte de ces données, grâce à la réplication (sur les bases des autres continents par exemple).
- Si ils décident de garder leurs données en interne, il faut que le système soit capable d'assurer la supervision de ces données même si notre entreprise n'a pas directement accès à leur base.

Notre système de supervision fait la liaison entre le client et la donnée.
Globalement, notre entreprise garde la gestion des bases que nous avons déployées sur les différents continents, et bien-sûr la gestion du service de supervision proposé au client.

La réplication de bases est-elle possible via le WAN en natif sous SQL Server? avec SB (dont je n'ai pas trop compris le principe j'avoue)?

J'avoue que PostgreSQL m'attire pas mal, mais la gestion du XML en natif manque cruellement.

je pense que votre conception est irréaliste sur bien des niveaux... je n'ai pas le temps de tout détailler, mais voici quelques éléments :
1) ce n'est pas des bases de données à déployer mais des serveurs chez chacun de vos clients
2) il n'y a aucun intérêt à déployer une BD par continent. Prévoyez un seul serveur et ajoutez y un deuxième un peu éloigné pour votre PRA. En matière de SGBDR on épuise le scale up avant de faire du scale out qui est 10 fois plus couteux à tous les niveaux.
Sachez que MS SQL Server travaille bien avec plusieurs To de données et que les plus grosses bases actuelles sous SQL Server sont de plusieurs dizaines de To (en France il y a de nombreux clients avec plusieurs To de données.... Conforama, fnac.com, amadeus...)
3) la réplication n'est pas conçue pour faire de la haute disponibilité. La réplication concerne des données (pas toute le base) tandis que le haute dispo concerne la totalité de la base ou du serveur. Pour faire cela il faut utiliser du log shipping, du clustering ou du mirroring. Tout dépend de l'éloignement, du temps de latence induit par votre tuyau et du prix que vous êtes prêt à mettre dans le matos
4) à mions de mettre de la fibre optique dédié, la réplication sera toujours asynchrone ou sinon elle engorgera votre serveur jusqu'à l'étrangler du fait du stockage local des données en delta lorsque les délais de répercussion s'allonge

Bref, reconcevez votre système et commencez par avoir une idée assez précise de la volumétrie attendue.

A +

[Raz-X]

Merci de ces indications qui m'aident à avancer et à réfléchir autrement sur notre architecture.

Cette application est pour le moment a l'état de projet sur papier, et il reste encore énormément de choses à étudier. N'ayant pas de connaissances extrêmes en bases de données (je suis surtout développeur de formation), j'essaye d'envisager chaque solution possible pour voir les avantages et inconvénients.

Comme je l'ai dit, il est possible que ma vision des choses soit utopiste (c'est aussi la raison pour laquelle je viens sur ce forum), mais mes connaissances actuelles en SGBD, et surtout sur les technologies de distribution des SGBD sont minces. Je vais tenter de me procurer les ouvrages que vous avez cités ci-dessus.

Le volume de données à traiter n'étant pas énorme (une dizaine de mégas par client), une solution basée sur SQL Server Express 2008 R2 semble envisageable. On partirait donc, comme vous l'avez indiqué, sur un serveur central basé chez nous, et nous déportons ponctuellement des serveurs au plus proche des clients, qui sont connectés à notre serveur central pour assurer le maintien de la donnée. Ai-je bien compris ce que vous m'avez indiqué dans les posts précédents? Si oui, c'est donc SB qui assurerait le service entre les différentes bases?

Ce que j'ai du mal à voir avec cette architecture, c'est comment continuer à assurer le service si l'un des serveurs distants tombe?

[SQLpro]

Envoyé par Raz-X

Ce que j'ai du mal à voir avec cette architecture, c'est comment continuer à assurer le service si l'un des serveurs distants tombe?

La vous posez la question de la haute disponibilité. Cela dépend de ce que vous voulez faire, notamment :
combien de temps/volume de perte de données est acceptable (voir même zéro) ?
combien de temps d'indisponibilité pouvez vous avoir ? (vois même proche de zéro)
quels sont les tuyaux (bande passante) entre les systèmes ?

A +

[mikedavem]

Bonsoir,

- Si ils décentralisent leurs données sur nos serveurs, nous en devenons responsables, et devons donc assurer la non perte de ces données, grâce à la réplication (sur les bases des autres continents par exemple).

Si vous parlez de disaster recovery, je ne pense pas que la réplication soit la solution la plus viable surtout sur des sites distants. Comme l'a expliqué SQLPro il faudra prendre en compte votre RPO pour savoir quelle architecture à mettre en place.

- Si ils décident de garder leurs données en interne, il faut que le système soit capable d'assurer la supervision de ces données même si notre entreprise n'a pas directement accès à leur base.

Devez vous absolument avoir une copie de leur données en local pour en faire la supervision ?

++

[Raz-X]

Devez vous absolument avoir une copie de leur données en local pour en faire la supervision ?

Non, nous n'avons pas de copie locale des données, notre serveur s'occupe de faire le mapping entre les écrans de supervision, et la donnée à afficher. Nos serveurs lisent donc de manière ponctuelle la donnée sur la base, la formate de la manière voulue pour ensuite l'afficher sur les écrans.

Pour la réplication, il s'avère en effet que ce n'est pas une solution viable pour notre projet. Après réflexion et les conseils avisés de SQLPro, il s'avère que le mirroring serait une solution bien plus adaptée aux exigences de notre produit, d'autant plus qu'elle nécessite un investissement financier beaucoup plus faible que la réplication.