Discussion :

[yakiniku]

Bonjour,

Nous sommes en train de réfléchir pour repenser la mise en place de l'architecture déjà présente de nos bases de données.

Actuellement, nous avons 2 serveurs de bases de données SQL Server 2008 qui interagissent parfois entre eux à l'aide de linked server.


Après un premier debriefing, nous avons pensé scinder notre architecture en 2 afin de séparer la partie Backoffice et la partie Frontoffice : Le premier serveur pour le BO qui contiendrait toutes les tables et s'occuperait des MAJ/Ajout/Suppression et la partie FO avec vues indexées et procédure stockée. Les 2 serveurs seraient alors liés via LinkedServer.

Mais j'ai de sérieux doutes concernant la sécurisation et la rapidité d’exécution des requêtes si nos SGBD communiquent entre elles en permanence...

Nous avons aussi penser à une autre solution qui éviterait d'utiliser le LinkedServer : avoir un SGBD source pour le BO qui synchroniserait le SGBD cible utilisé pour le FO, mais cela risque de poser des problèmes de MAJ sur le FO et de charges serveurs je suppose...

Bref, j'aimerais avoir vos avis et critiques concernant ces solutions ou d'autres propositions si vous avez de meilleures idées.

[Philippe Robert]

Je n'aime pas cette idée

Quand une requête exécutée sur un serveur A demande des données du serveur B via serveur liés, les données sont temporairement stockée dans tempbd => augmentation du nombre d'IO.

J'ai déja eu l'occasion de tuner une procédure stockée faisant appel à des données d'un serveur lié. Et bien, cette requête ramenait tout le contenu de la table du serveur B vers A avant de faire sa clause WHERE !

Selon mon point de vue, le mieu est d'investir dans une bonne architecture disque, serveur et réseau, un solide modèle de données et un cluster pour la haute disponibilité

[mikedavem]

En fait tout dépend comment la requête est écrite.

Avec un nom en quatre parties il y a de grandes chances que le moteur décide de ramener l'ensemble de données du serveur distant pour effectuer les opérations localement.

En utilisant OPENQUERY cela permet d'exécuter la partie de la requête concernée sur le serveur distant AVANT de ramener les données sur le serveur local.

++

[Ptit_Dje]

Après un premier debriefing, nous avons pensé scinder notre architecture en 2 afin de séparer la partie Backoffice et la partie Frontoffice : Le premier serveur pour le BO qui contiendrait toutes les tables et s'occuperait des MAJ/Ajout/Suppression et la partie FO avec vues indexées et procédure stockée. Les 2 serveurs seraient alors liés via LinkedServer.

Qu'est ce que vous entendez par backoffice et frontoffice ?
Doit on comprendre transactionnel et reporting ?

Nous avons aussi penser à une autre solution qui éviterait d'utiliser le LinkedServer : avoir un SGBD source pour le BO qui synchroniserait le SGBD cible utilisé pour le FO, mais cela risque de poser des problèmes de MAJ sur le FO et de charges serveurs je suppose...

Bref, j'aimerais avoir vos avis et critiques concernant ces solutions ou d'autres propositions si vous avez de meilleures idées.

C'est le principe du datawarehousing...
C'est assez courant comme pratique et recommande pour ne pas affecter outre mesure les performances du systeme transactionnel avec de lourdes queries plutot analytiques.

Pourriez vous clarifier ?

[yakiniku]

Qu'est ce que vous entendez par backoffice et frontoffice ?
Doit on comprendre transactionnel et reporting ?

J'ai oublié de préciser que les données sont principalement utilisés dans le cadre de projet web, d'où la notion de Backoffice et de frontoffice : le backoffice équivaut à toute la partie d'administration des données qui est caché à l'utilisateur lambda, et le front office est tout simplement le site en production qui lui est utilisé par l'utilisateur lambda.

Je ne connais pas trop la notion de transactionnel et reporting par contre, donc je ne sais pas si ca correspond à ca.

En fait tout dépend comment la requête est écrite.

Avec un nom en quatre parties il y a de grandes chances que le moteur décide de ramener l'ensemble de données du serveur distant pour effectuer les opérations localement.

En utilisant OPENQUERY cela permet d'exécuter la partie de la requête concernée sur le serveur distant AVANT de ramener les données sur le serveur local.

++

Je ne connaissais pas Openquery, mais ca a l'air vraiment pas mal pour optimiser au maximum les échanges entre les 2 serveurs

C'est le principe du datawarehousing...
C'est assez courant comme pratique et recommande pour ne pas affecter outre mesure les performances du systeme transactionnel avec de lourdes queries plutot analytiques.

Je pensais plus à de la réplication de données.

[Ptit_Dje]

Quelles sont vos contraintes d'architecture ?
Le BO et le FO doivent-ils absolument être séparés ?

le backoffice équivaut à toute la partie d'administration des données qui est caché à l'utilisateur lambda, et le front office est tout simplement le site en production qui lui est utilisé par l'utilisateur lambda.

A priori vous pouvez tres bien realiser cela a l'aide de vues et de roles de securite definis pour soit le BO, soit le FO.
Ca vous evite d'avoir 2 serveurs.

Quel est votre regle en matiere de publication des données BO/FO ?
Est ce que c'est de l'instantané ?

[elsuket]

Bonjour,

Encore une fois, je crois que l'on oublie l'intérêt des schémas et la possibilité d'implication qu'ils peuvent avoir dans la gestion de la sécurité des données ...

D'autre part, par l'échange de données à travers le réseau, vous ajoutez du temps d'exécution ...

@++

[yakiniku]

Quelles sont vos contraintes d'architecture ?
Le BO et le FO doivent-ils absolument être séparés ?

A priori vous pouvez tres bien realiser cela a l'aide de vues et de roles de securite definis pour soit le BO, soit le FO.
Ca vous evite d'avoir 2 serveurs.

Le problème c'est qu'on a déjà actuellement 2 serveurs, du coup on réfléchissait à un moyen de les optimiser au maximum, mais faute d'avoir un dba sous la main, nous ne savons trop sur quoi partir. Donc non le BO/FO ne doivent pas forcément être séparés, c'est une idée pour mieux structurer nos données. (Personnellement, je pense que les vues sont faites pour ça et que c'est se compliquer la vie pour rien que de vouloir les séparer totalement, mais je voulais soumettre l'idée pour en débattre)

Quel est votre regle en matiere de publication des données BO/FO ?
Est ce que c'est de l'instantané ?

Je ne crois pas qu'on est besoin d'afficher des données provenant de la base instantanément, il peut y avoir quelques minutes de latence avant l'affichage des données.

Encore une fois, je crois que l'on oublie l'intérêt des schémas et la possibilité d'implication qu'ils peuvent avoir dans la gestion de la sécurité des données ...

J'avoue ne pas y avoir penser (il n'y a aucun schéma mis en place dans la BDD actuelle...), donc je vais me pencher la dessus

D'autre part, par l'échange de données à travers le réseau, vous ajoutez du temps d'exécution ...

C'est bien là le problème .

Une autre solution que je vois serait de laisser l'ensemble des données scinder sur 2 serveurs pour partager la charge et éviter les échanges entre serveurs, et optimiser le tout par des vues et une meilleure gestion de la sécurité (schéma, etc)

[Ptit_Dje]

1 seul de vos serveurs tient il completement la charge du BO et du FO ?

Si c'est le cas, pensez a mettre une solution de HA (cluster/miroir) en place plutot que de partir sur des complications bizarres pour utiliser vos 2 serveurs.
L'avantage sera que vous aurez une plus grande availability de votre site ce qui est loin d'etre negligeable d'apres moi !