Solution montée en charge

Coming_next · 19/11/2007, 22h04

Bonjour,

comment on s y prends lorsque qu une application web par exemple qui tourne autour d une base de données commence a recevoir beaucoups de requetes SQL
jusqu a etouffer la base ?

Il faut obligatoirement plusieurs bases , mais comment faire pour assurer la coherence des données ?

Plusieurs bases synchrones ce n est pas possible ?

La replication c est quoi exactement ?

Merci

vmolines · 20/11/2007, 12h19

Tu peux utiliser une base maitre et des bases esclave en réplication unidirectionnelle. Ainsi toutes les lectures se font sur les esclaves et l'ecriture sur le maître (qui répercute sur les esclave de manière unidirectionnelle). Comme il y a souvent beaucoup plus de lectures que d'écritures, c'est une solution qui peut être très efficace.

Il faut juste que ton application fasse une sorte de répartition des connections pour ce qui est lecture. A chaque nouvelle session client, affecter une connexion et en changer au prochain client.

Marc Lussac · 20/11/2007, 13h13

La solution la plus simple c'est d'augmenter la ram sur le serveur

Coming_next · 22/11/2007, 07h11

Merci.
Il n y a pas d autres solutions ?

pifor · 22/11/2007, 09h46

Quel est le SGDB utilisé et en quelle version ?

La première chose à faire est d'analyser les performances:
- dans la base
- sur la machine qui héberge la base: charge CPU
- sur le système de stockage externe utilisé (le cas échéant): charge E/S

Suivant le SGBD utilisé, il y a des possibilités d'optimisation des requêtes, d'utilisation de structures de tables ou d'index différentes, d'utiliser certains paramètres ou options. Dans certains cas l'ajout de processeurs ou de mémoire peut être une solution, mais il est illusoire de résoudre un problème de performance sans éléments concrets.

vmolines · 22/11/2007, 09h53

On peut aussi stocker les tables sur différents disques pour améliorer les E/S. Selon les SGBD, les possibilités diffèrent.

Toujours au niveau des E/S, pourquoi ne pas regarder du côté des SSD (Solid State Disk) qui sont des disques durs à base de mémoire NAND. L'avantage est le temps d'accès 100 fois moins important que les disques traditionnels. Attention cependant à la durée de vie de ceux ci.

SQLpro · 25/11/2007, 21h21

On commence TOUJOURS par faire du scale up avant de faire du scale out.

scale up : augmenter les ressources du serveur
scale out : augmenter le nombre des serveurs

En effet le scale up est toujours plus économique que le scale out !

Pourquoi ?

Le scale up consiste à rajouter de la RAM des processeurs et des disques. Cela laisse une seule base sur un seul serveur.

Dans le scale up il faut rajouter les coût supplémentaires du matériel. Le reste : licences, administration ... reste inchangé.

Le scale out consiste à répliquer des parties verticales ou horizontales de la base de données sur différents serveurs.

Dans le scale up il faut rajouter le coût des nouveaux serveur, les licences supplementaires et l'administration supplémentaire (administrer deux serveurs coute deux fois plus cher).

En outre le scale out possède de multiples inconvénients :
1) baisse du MTBF : chaque machine possède un MTBF (temps moyen de bon fonctionnement - avant panne). Chaque machine supplémentaire dégrade donc le MTBF. SI l'on veut rester dans le même standard, il faut donc des machine d'une game supérieure !
2) performances en baisse : les ressources des différents serveurs sont mobilisées pour la réplication au détriment du service des données. Autrement dit 2 machines ne veut pas dire 2 fois plus de ressources, mais un coefficient largement inférieur à 2 et fortement dépendant de la rapidité du réseau et du temps de latence de la réplication. En pratique on compte entre 1,8 et 1,5.

C'est pourquoi le scale out est toujours beaucoup plus cher globalement que le scale up, mais peu de gens perçoivent ce fait de prime abord !

Autrement dit une fois que le serveur 32 bits à atteint 64 processeurs, 64 Go de RAM et quelques Tera octets de disque, alors si on ne peut plus lui rajouter des ressources physiques, la seule solution est de rajouter du serveur !

A +

Coming_next · 03/12/2007, 22h56

Merci tres interessant.

pifor · 05/12/2007, 09h35

Citation:

Le scale out consiste à répliquer des parties verticales ou horizontales de la base de données sur différents serveurs.

Cela dépend des SGDB utilisés. Oracle propose son architecture grid qui se base sur le clustering Oracle RAC entre autres. Cela permet de faire du "scale out" avec des "petits serveurs" tout en gardant une seule base.

L'article suivant (de 2003) est une réponse spécifique d'Oracle à Microsoft sur la comparaison SQL Server/federated databases et Oracle/RAC:
http://www.oracle.com/technology/pro...L_Rebuttal.pdf

SQLpro · 05/12/2007, 14h00

On peut faire cela aussi avec MS SQL Server à l'aide de services broker qui permet de concevoir des solutions de bases de données collaboratives.

A +

19/11/2007, 22h04	#1
Coming_next Nouveau Membre du Club Inscription : février 2005 Messages : 47 Détails du profil Informations forums : Inscription : février 2005 Messages : 47 Points : 34 Points : 34	Solution montée en charge Bonjour, comment on s y prends lorsque qu une application web par exemple qui tourne autour d une base de données commence a recevoir beaucoups de requetes SQL jusqu a etouffer la base ? Il faut obligatoirement plusieurs bases , mais comment faire pour assurer la coherence des données ? Plusieurs bases synchrones ce n est pas possible ? La replication c est quoi exactement ? Merci
	00

20/11/2007, 13h13	#3
Marc Lussac Directeur Marketing Marc Lussac Responsable marketing opérationnel Inscription : mars 2002 Messages : 26 358 Détails du profil Informations personnelles : Nom : Marc Lussac Localisation : Canada Informations professionnelles : Activité : Responsable marketing opérationnel Secteur : Communication - Médias Informations forums : Inscription : mars 2002 Messages : 26 358 Points : 23 184 Points : 23 184	La solution la plus simple c'est d'augmenter la ram sur le serveur __________________ -> Ne pas me contacter pour le forum et je ne répondrai à aucune question technique -> Comment nous contacter -> Pour partenariat ou publicité : Mon Email
	00

22/11/2007, 09h46	#5
pifor Expert Confirmé Inscription : février 2006 Messages : 3 433 Détails du profil Informations forums : Inscription : février 2006 Messages : 3 433 Points : 3 462 Points : 3 462	Quel est le SGDB utilisé et en quelle version ? La première chose à faire est d'analyser les performances: - dans la base - sur la machine qui héberge la base: charge CPU - sur le système de stockage externe utilisé (le cas échéant): charge E/S Suivant le SGBD utilisé, il y a des possibilités d'optimisation des requêtes, d'utilisation de structures de tables ou d'index différentes, d'utiliser certains paramètres ou options. Dans certains cas l'ajout de processeurs ou de mémoire peut être une solution, mais il est illusoire de résoudre un problème de performance sans éléments concrets. __________________ P. Forstmann AskTom Forums OTN doc 8, 9, 10 et 11
	00

25/11/2007, 21h21	#7
SQLpro Rédacteur/Modérateur Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 10 959 Détails du profil Informations personnelles : Nom : Frédéric BROUARD Localisation : France Informations professionnelles : Activité : Expert SGBDR & SQL Secteur : Conseil Informations forums : Inscription : mai 2002 Messages : 10 959 Points : 17 793 Points : 17 793	On commence TOUJOURS par faire du scale up avant de faire du scale out. scale up : augmenter les ressources du serveur scale out : augmenter le nombre des serveurs En effet le scale up est toujours plus économique que le scale out ! Pourquoi ? Le scale up consiste à rajouter de la RAM des processeurs et des disques. Cela laisse une seule base sur un seul serveur. Dans le scale up il faut rajouter les coût supplémentaires du matériel. Le reste : licences, administration ... reste inchangé. Le scale out consiste à répliquer des parties verticales ou horizontales de la base de données sur différents serveurs. Dans le scale up il faut rajouter le coût des nouveaux serveur, les licences supplementaires et l'administration supplémentaire (administrer deux serveurs coute deux fois plus cher). En outre le scale out possède de multiples inconvénients : 1) baisse du MTBF : chaque machine possède un MTBF (temps moyen de bon fonctionnement - avant panne). Chaque machine supplémentaire dégrade donc le MTBF. SI l'on veut rester dans le même standard, il faut donc des machine d'une game supérieure ! 2) performances en baisse : les ressources des différents serveurs sont mobilisées pour la réplication au détriment du service des données. Autrement dit 2 machines ne veut pas dire 2 fois plus de ressources, mais un coefficient largement inférieur à 2 et fortement dépendant de la rapidité du réseau et du temps de latence de la réplication. En pratique on compte entre 1,8 et 1,5. C'est pourquoi le scale out est toujours beaucoup plus cher globalement que le scale up, mais peu de gens perçoivent ce fait de prime abord ! Autrement dit une fois que le serveur 32 bits à atteint 64 processeurs, 64 Go de RAM et quelques Tera octets de disque, alors si on ne peut plus lui rajouter des ressources physiques, la seule solution est de rajouter du serveur ! A + __________________ Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ *Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.* Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
	00

05/12/2007, 14h00	#10
SQLpro Rédacteur/Modérateur Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 10 959 Détails du profil Informations personnelles : Nom : Frédéric BROUARD Localisation : France Informations professionnelles : Activité : Expert SGBDR & SQL Secteur : Conseil Informations forums : Inscription : mai 2002 Messages : 10 959 Points : 17 793 Points : 17 793	On peut faire cela aussi avec MS SQL Server à l'aide de services broker qui permet de concevoir des solutions de bases de données collaboratives. A + __________________ Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ *Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.* Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
	00

20/11/2007, 12h19	#2
vmolines Membre Expert Inscription : mars 2005 Messages : 1 565 Détails du profil Informations personnelles : Âge : 29 Localisation : France, Haute Garonne (Midi Pyrénées) Informations forums : Inscription : mars 2005 Messages : 1 565 Points : 2 178 Points : 2 178	Tu peux utiliser une base maitre et des bases esclave en réplication unidirectionnelle. Ainsi toutes les lectures se font sur les esclaves et l'ecriture sur le maître (qui répercute sur les esclave de manière unidirectionnelle). Comme il y a souvent beaucoup plus de lectures que d'écritures, c'est une solution qui peut être très efficace. Il faut juste que ton application fasse une sorte de répartition des connections pour ce qui est lecture. A chaque nouvelle session client, affecter une connexion et en changer au prochain client.
	00

22/11/2007, 07h11	#4
Coming_next Nouveau Membre du Club Inscription : février 2005 Messages : 47 Détails du profil Informations forums : Inscription : février 2005 Messages : 47 Points : 34 Points : 34	Merci. Il n y a pas d autres solutions ?
	00

22/11/2007, 09h53	#6
vmolines Membre Expert Inscription : mars 2005 Messages : 1 565 Détails du profil Informations personnelles : Âge : 29 Localisation : France, Haute Garonne (Midi Pyrénées) Informations forums : Inscription : mars 2005 Messages : 1 565 Points : 2 178 Points : 2 178	On peut aussi stocker les tables sur différents disques pour améliorer les E/S. Selon les SGBD, les possibilités diffèrent. Toujours au niveau des E/S, pourquoi ne pas regarder du côté des SSD (Solid State Disk) qui sont des disques durs à base de mémoire NAND. L'avantage est le temps d'accès 100 fois moins important que les disques traditionnels. Attention cependant à la durée de vie de ceux ci.
	00

03/12/2007, 22h56	#8
Coming_next Nouveau Membre du Club Inscription : février 2005 Messages : 47 Détails du profil Informations forums : Inscription : février 2005 Messages : 47 Points : 34 Points : 34	Merci tres interessant.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email