Re: [TECH] Limitation mysql

[Sébastien Dinot <sdinot AT april.org>]

Bonjour à tous,

Voici une petite anecdote qui me semble intéressante ici car elle a
trait à une conception singulière que je ne conseillerais pas en temps
normal mais qui, dans un contexte particulier, s'est avérée
extrêmement performante.

En mars 2005, on m'a demandé d'évaluer le code d'une application qui
collectait des données et les stockait dans une base de données MySQL
en les consolidant au fil de l'eau. Une interface Web en PHP
permettait aux utilisateurs d'obtenir des statistiques ou d'extraire
des données de la base.

Sachant que la base contenait plus de 250 millions d'enregistrements
de même nature - représentant des SMS - constitués chacun d'une
trentaine de champs de types variés, j'ai immédiatement été saisi tant
par les performances de l'application. Le moteur traitait et
consolidait les données au fur et à mesure qu'elles arrivaient sans
mettre à genoux la machine. L'interface Web répondait en moins de 2
secondes quels que soient mes critères d'extraction ou les
statistiques que je demandais.

Certes, le serveur était musclé (sans être hors norme) mais cela
n'expliquait pas tout. J'ai vite plongé dans le code pour comprendre
d'où venait la magie. La base était constituée de plus de 40 000
tables identiques au nom près (bien évidemment, les données qu'elles
contenaient été différentes). Grosso modo, si un SMS était en relation
avec le service XYZ et avait été émis le 13/03/2005, il était stocké
dans la table XYZ_20050313. La couche d'accès aux données se chargeait
d'insérer la donnée dans la bonne table en fonction de la date et du
service. De même, lorsqu'une extraction ou un décompte étaient
demandés, elle se chargeait de sélectionner en fonction des critères
d'extraction les tables à interroger et c'est elle qui agrégeait les
résultats. Quelques tables de configuration et de statistiques mises à
jour au fil de l'eau complétaient le schéma. Avec une telle
conception, la taille moyenne d'une table était de 6 000
enregistrements. Du coup, lorsqu'un utilisateur demandait la liste des
SMS envoyés par le 0612345678 au service XYZ entre le 13/03/2005 à
9h00 et le 15/03/2005 à 17h00, les requêtes générées portaient sur 3
tables totalisant moins de 20 000 enregistrements, non sur une seule
table de 250 millions d'enregistrements. D'où les temps de réponse
extrêment courts...

Ceux d'entre vous qui s'intéressent à l'informatique décisionnelle et
aux entrepôts de données auront reconnu dans cette conception le
simulacre (ou les bases archaïques) d'un moteur OLAP.

Bien évidemment, une telle conception ne va pas sans poser de sérieux
problèmes de maintenabilité et d'évolutivité. Mais cette application
affichait des performances à faire pâlir de jalousie toute personne
ayant déjà joué avec des bases de cette taille. Elle m'a donc marqué.

Et le pire dans tout cela, c'était que le code était sale et que le
moteur en C était lui-même largement optimisable ! Comme quoi la
créativité est une réelle qualité dans notre métier.

A++, Sébastien

-- 
Sébastien Dinot, sdinot AT april.org
Secrétaire de l'APRIL (http://www.april.org)
Association pour la Promotion et la Recherche en Informatique Libre