Discussion :

[Coming_next]

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]

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]

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

[Coming_next]

Merci.
Il n y a pas d autres solutions ?

[pifor]

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]

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]

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]

Merci tres interessant.

[pifor]

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]

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 +