Re: Un article linuxfr récent

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.