Re: Un article linuxfr récent

[Stéphane Bunel <stephane+pgfr(at)bpf(dot)st>]

Le samedi 18 juillet 2009 03:43:00, Pascal Brognez a écrit :
> Bonjour,
> 
> Je viens de lire cet article récent sur linuxfr
> Logiciel : Répartition de charge : axes de réflexion et quelques 
> exemples de solutions libres
> 
> http://linuxfr.org/2009/06/18/25620.html
> 
> 
> Avez vous un avis sur la justesse et la pertinence de cet article?

L'article se concentre sur un type d'architecture, celle du Web (Mavigateur- > 
Serveur(s) HTTP -> Moteur(s) d'application -> Base(s) de données) avec le 
travers systématique de la base relationnelle/transactionnelle/SQL. L'auteur 
souligne d'ailleurs rapidement que la base de donnée occupe le premier poste 
de coût sur le critère ressource/performance.

Pour rejoindre le 1er commentaire, la réponse apportée par l'article n'est 
pas/plus adaptée au contexte. Sur le fond elle ne propose pas de solution sur 
le critère retenu et offre plutôt le moyen de reculer une échéance technique 
bâtie sur une vision académique (rétrécie) des possibilités d'architecture.

On peut observer que la grande majorité des sites à fort trafic ne requièrent 
que peu de besoin transactionnel. Pour "les pages Web" le marché a désormais 
l'habitude d'appliquer un traitement en fonction de la nature de l'objet 
requis ( .html/statique, *.php/dynamique, *.png/cache, *.jsp/moteur 
d'application...).

Par analogie on comprend qu'il en va de même pour la donnée. Le tout SGBD/R 
dans le contexte donné est une erreur de fond si l'on cherche à diminuer la 
ressource nécessaire, améliorer la performance, réduire la complexité. La 
faute en revient aussi au contenu éducatif qui, pour mon expérience, se 
focalise sur l'unique modèle du SGBD/R. LDAP est rarement présenté comme une 
base de données! Ce qu'il est pourtant. Avec en prime une réplication native, 
de la répartition, du fail-over, du proxying, un langage d'accès aux données 
normalisé et standard (oui, en théorie SQL aussi est normalisé, mais en 
pratique je vous laisse juge), etc.

L'article apporte des informations très intéressantes mais ce trompe de 
contexte ce qui minimise la pertinence des réponses. On peut regretter que, 
bien qu'abordé, l'aspect moteur d'application reste focalisé sur un traitement 
synchrone des événements. En la matière l'apport d'un découplage applicatif au 
travers, par exemple, d'un middleware de messagerie peut considérablement 
accroitre la capacité d'absorption de charge d'un système. Ce modèle permet en 
outre de concentrer ses efforts là où c'est nécessaire plutôt que de dupliquer 
des machines entières (et leurs données). D'ailleurs l'article ne parle même 
pas de sharding, ce qui constituerai pourtant un bout de réponse théorique 
valable dans l'univers du SGBD/R.

Stéphane Bunel.