Dimensionnement d'une base de données

[Catullo]

Bonjour,

Dans le cadre d'un stage de fin d'étude en Ingéniérie réseau-télécom, je dois développer une base de données récupérant des données d'audits d'équipements réseaux mobile GPRS puis UMTS. Je vais devoir apprendre sur le tas la conception de base de données n'ayant eu aucune formation théorique dans ce domaine.

Pour des soucis de facilité de développement et de maintenance le choix s'est porté sur :

- type de base de données : SQL Server 2000
- développement objet en VB. NET avec Visual Studio 2003
- modélisation : UML


J'aurais besoin d'aide en particulier sur la partie dimensionnement de la base de données :

- règles de dimensionnement hardware (RAM, HDD)
- volume critique de données sans perte de performance
- règles pour réaliser des tests de régression

Mes contraintes :

- capacité de montée en charge importante (taille globale de la base)
- pas de mode client / serveur indispensable puisqu'il s'agit de valider le dimensionnement d'équipements réseau à une date X puis de réaliser des audits périodiques.
- développement industriel à but commercial : les solutions du type opensource sont mise de côté pour des raisons évidentes de SLA (envers l'éditeur et envers le client final).

Pour des raisons de taille globale de la base, les solutions basées sur Microsoft Access par exemple ont été abandonnées.

Toutes les suggestions sont sincèrement bienvenues.

P.S.: Si je fais du développement objet avec VB.NET permettant entre autre une meilleure maintenance du code à long terme, qu'elle sera la nature de ma base de donnée sous SQL-Serveur 2000 - Objet ou relationnel - ?

La question est peut-être stupide ou n'a peut-être aucune importance ?

Merci beaucoup.

[SQLpro]

Vastes questions.... C'est presque un audit que vous demandez...

partie dimensionnement de la base de données :

1 - règles de dimensionnement hardware (RAM, HDD)
2 - volume critique de données sans perte de performance
3 - règles pour réaliser des tests de régression

1) à l'aide de votre outil de modélisation, renseignez chacune des tables du MPD en nombre de lignes à terme (5 ans par exemple). N'oubliez pas d'ajouter à votre modèle les principaux index. Normalement un outil bien fait est capable de calculez le volume de la base

1-2) un SGBDR C/S fonctionne en montant en mémoire les données. Je prend un exemple. Soit un SELECT quelconque. Le moteur se demande si les données sont présentent en mémoire. Si oui, il effectue le traitement. Si non, il passe la demande en relais à un processus de lecture disque. Lorsque le processus de lecture disque à montée en mémoire les pages à traiterj, il réveille le processus demandeur et ce dernier réalise le traitement. A terme la mémoire est saturée, et c'est un nouveau processus qui libère les pages les moins lues, pour faire de la place pour les nouvelles. L'adéquation à trouver est donc : quelle est la quantité de données réellement exploitée. Par exemple base compta, six années de compta, volume 8 Go... On peut penser que seul 8/6 de Go sont réellement exploitées. En prenant un coeff de majoration et 256 Mo de RAM pour l'OS et les exe, on obtient 2 Go de RAM. Au dela c'est la qualité des disques qui influe : différentes grappes de disques SCSI 320Mbs à 15000 rpm (le plus important) avec fichiers de taille fixe.
Par exemple :
Grappe 1 RAID 0 pour OS et EXE
Grappe 2 RAID 0 pour JT
Grappe 3 RAID 0 pour tempdb
Grappe 4 RAID 5 pour une partie de la base (par exemple les index)
...
Grappe n RAID 5 pour une partie de la base (par exemple les données)
=> paralléllisme d'accès

SQL Server peut monter en standard jusqu'à 3 Go de RAM. Après il faut des éditions spéciales de l'OS Server (Advanced ou DataCenter) et l'édition Entreprise de SQL Server.
Pensez aussi que si le projet voit le jour en septembre, il est sans doute intéressant d'investir dans SQL Server 2005 qui actuellement en béta version fonctionne parfaitement et se trouveêtre gratuit.

3) Pour vos teste de régression, un outil de test genre QArun... mais ce genre d'outil a été abandonné. Reste le banc de test manuel avec base de test et utilisateur.

Mes contraintes :

1 - capacité de montée en charge importante (taille globale de la base)
2 - pas de mode client / serveur indispensable puisqu'il s'agit de valider le dimensionnement d'équipements réseau à une date X puis de réaliser des audits périodiques.
3 - développement industriel à but commercial : les solutions du type opensource sont mise de côté pour des raisons évidentes de SLA (envers l'éditeur et envers le client final).

1) SQL Server peut absorber des bases de données de plusieurs téra octets. Il faut simplement avoir les ressources physiques en face. Exemple : le SAP de Microsoft est en version 2005...
http://www.microsoft.com/resources/casestudies/CaseStudy.asp?CaseStudyID=16597

2) pas compris

3) pas compris (SLA ???).

P.S.: Si je fais du développement objet avec VB.NET permettant entre autre une meilleure maintenance du code à long terme, qu'elle sera la nature de ma base de donnée sous SQL-Serveur 2000 - Objet ou relationnel - ?

a) évitez VB, utilisez C# : SQL Server 2005 intégre directement CLR, le run time C#. En effet, SQL Server 2005 permet dorénavant de coder ses UDF, procédures stockées, triggers et type utilisateurs directement en C#. Il serait donc dommage de devoir supporter deux langages alors que VB est un "produit" MS (et pas terrible, un vrai merde dans sa syntaxe) tandis que C# est un langage en voie de normalisation par l'ECMA et bientôt supporté pour d'autres plateformes.

b) le pur objet est un leurre et les bases de données objet ont fait un gigantesque flop. Si vous voulez de la perf, optez pour un mapping realtionnel obejt via des procédures stockée. Cela est intéressant dans le cadre d'une appli en mode déconnecté.

A +

[orafrance]

Attention, le RAID 5 est aussi mauvais pour les écritures qu'il est bon pour les lectures... gare aux conditions d'utilisation donc

[Catullo]

Merci pour vos réponses.

1) SLA (Service Level Agreement) : dans la mesure où il s'agit d'un développement à but commercial, la société préfère acheter un produit avec licence commerciale pour avoir un support technique avec une qualité de service contractuelle.

2) le choix de VB .NET se justifiait selon moi s'agissant d'un langage plus facile à apprendre que C# me semble-t-il et sachant que j'ai des contraintes de délai forte :

Préalable :
apprentissage à faire => Conception DB, langage de dev (VB ou C#), SQL

=> développement code archevé pour mi-juillet
=> implémentation de la base de données : mi-juillet

3) Le choix de SQL Server 2005 ne me semble pas à priori une bonne solution car même s'il propose de nouvelles fonctionnalités intéressantes. Il n'y a aucun retour client sur sa fiabilité à long terme, sur les bugs ignorés, sachant que Microsoft commercialise souvent des produits buggés. Une solution éprouvé depuis plusieurs années me semblait donc plus appropriée. A moins que ce soit une réflexion inappropriée dans ce cas précis.

@+.

[orafrance]

Merci de décocher l'option Désactiver le BBCode dans ce message de votre profil

[SQLpro]

Contrairement à une idée répandue les langages "lâches" dans leur syntaxe conduisent à des temps de développement plus important que les langages "serrés" ou impératifs. C'est la raison pour laquelle des langages comme Ada ont vu le jour. Certe le temps de dev est allongé par rapport à C, mais le temps de débugage est très fortement diminué. Donc un projet d'envergure est plus court.

La formation à un langage nouveau compte pour très peu sur un projet.

A +

[Catullo]

Bonjour,

Merci pour vos réponses.

1-2) un SGBDR C/S fonctionne en montant en mémoire les données. Je prend un exemple. Soit un SELECT quelconque. Le moteur se demande si les données sont présentent en mémoire. Si oui, il effectue le traitement. Si non, il passe la demande en relais à un processus de lecture disque. Lorsque le processus de lecture disque à montée en mémoire les pages à traiterj, il réveille le processus demandeur et ce dernier réalise le traitement. A terme la mémoire est saturée, et c'est un nouveau processus qui libère les pages les moins lues, pour faire de la place pour les nouvelles. L'adéquation à trouver est donc : quelle est la quantité de données réellement exploitée. Par exemple base compta, six années de compta, volume 8 Go... On peut penser que seul 8/6 de Go sont réellement exploitées. En prenant un coeff de majoration et 256 Mo de RAM pour l'OS et les exe, on obtient 2 Go de RAM. Au dela c'est la qualité des disques qui influe : différentes grappes de disques SCSI 320Mbs à 15000 rpm (le plus important) avec fichiers de taille fixe.
Par exemple :
Grappe 1 RAID 0 pour OS et EXE
Grappe 2 RAID 0 pour JT
Grappe 3 RAID 0 pour tempdb
Grappe 4 RAID-5 pour une partie de la base (par exemple les index)
...
Grappe n RAID 5 pour une partie de la base (par exemple les données)
=> paralléllisme d'accès

Merci pour ces informations. Cependant cette analyse me semble empirique dans le principe du dimensionnement.
Existe-t-il des matrices de dimensionnement ou des règles mathématiques précises pour pourvoir évaluer au mieux le dimensionnement du serveur d'hébergement. Par exemple :
- le volume moyen des transactions ? par seconde ?
- le volume de données généré par une transaction
- Rapport RAM/Volume de données : 1/1 ? 2/1 ?
- Taille critique de la RAM sans perte de performance ?

Je pense à ces indicateurs mais ne manière empirique ?

Merci beaucoup.

@+.

[SQLpro]

Existe-t-il des matrices de dimensionnement ou des règles mathématiques précises pour pourvoir évaluer au mieux le dimensionnement du serveur d'hébergement. Par exemple :
- le volume moyen des transactions ? par seconde ?
- le volume de données généré par une transaction
- Rapport RAM/Volume de données : 1/1 ? 2/1 ?
- Taille critique de la RAM sans perte de performance ?

Pas dans la pratique. En effet le volume d'une base de données doit être connue et le style de développement fortement élaboré pour mesurer proprement le volume moyen des transactions. Par exemple entre un code n'utilisant que des requêtes SQL et jamais de proc stock et un code n'utilisant que des proc stocke et jamais de requêtes la différence sera très sensible : l'un aura beaucoup de données en transit et de très nombreuses petites transactions. L'autre aura beaucoup moins de données à véhiculer, moins de transaction, mais des transactions très volumineuses.

Pour le volume des données, il y a une différence très sensible entre une appli comptable et une application de gestion documentaire. Même avec un style identique, le volume et la durée des transactions seront dans les deux cas très différents.

Enfin pour la RAM, ce n'est heureusement pas toute la base qu'il faut monter, mais la partie de données réellement exploitée. Par exemple dans une compta on peut compter les données exploitée comme suit :
mois en cours : 100%
mois -1 : 90%
mois -2 et -3 : 80%
mois - 4 à - 12 : 50%
an passé : 20%
années antérieures à l'an passé : 5 à 10 %

etc.

A +

[SQLpro]

3) Le choix de SQL Server 2005 ne me semble pas à priori une bonne solution car même s'il propose de nouvelles fonctionnalités intéressantes. Il n'y a aucun retour client sur sa fiabilité à long terme, sur les bugs ignorés, sachant que Microsoft commercialise souvent des produits buggés. Une solution éprouvé depuis plusieurs années me semblait donc plus appropriée. A moins que ce soit une réflexion inappropriée dans ce cas précis.

Il y a actuellement une trentaines de comptes SQL Server 2005 dans le monde qui l'utilise en exploitation avec plus de 1 tera octets de données en ligne. Pensu tu que ces gens là soient fous ?
Simplement le noyau SQL est achevé, testé et fiabilisé depuis bien avant la béta 2. La release d'avril a éliminé tous les petits bugs. Mais ce sont les outils et techniques périphériques qui ne sont pas encore tous parfaitement achevés. Nottament les nouveaux outils de l'informatiquer décisionnelle tournant autour de Maestro.

Il se trouve qu'étant MVP sur SQL Server, je discute avec les équipes de dev comme avec les béta utilisateurs dans des forums privés. Etr les rares bugs qui sont relevés ont été érradiques dans la version d'avril 2005.

Enfin, depuis la reprise de MS par Ballmer, MS s'est orienté vers l'informatique professionnelle et abandonné ses mauvaises habitudes liées à l'informatique domestique. Ceci a d'ailleurs été mal compris, voir le pataquès provoqué par le SP 2 de Windows XP...

Sache pourtant que je suis assez anti microsoft, mais je considère que SQL Server est l'un des SGBDR les plus intéressant dans son compris facilité, productivité performance, respect des normes et standards (SQL, XML)... Très loin devant Oracle et IBM DB2.

A +