Re: [TECH] Limitation mysql

[Mathieu Ignacio <mathieu.ignacio AT gmail.com>]

Bernard Choppy wrote:
> Bonjour à tous,
>
> A la base, se demander si on fait 40 000 tables devrait en soi - AMHA - 
> mener à une remise en cause de la structure, je pense.
>
> Je ne connais pas de moteur qui travaille bien dans ce genre de 
> situations (si : un mainframe qui gère de l'ISAM en COBOL, sans doute ;-)).
>
> En effet, chaque table et chaque colonne dans un SGBD/R correspondent à 
> des enregistrements de définition dans les tables système (genre 
> all_tables, all_columns, etc.) avec la gestion des droits y afférant, etc.
>
> Cela veut dire qu'on se retrouve avec des tables système assez 
> gigantesques pour lesquelles on va se retrouver avec des problèmes 
> d'optimisation qu'on ne peut maîtriser puisque c'est justement le moteur 
> qui y accède.
>
> Le simple calcul de plan d'exécution SQL risque de représenter une 
> charge énorme.
Ca c'est super intéressant. Je ne suis pas DBA et je ne me suis jamais 
penché sur la conception de moteur de bd : je négligeais totalement la 
gestion des indexes des tables et des colonnes, je pensais que c'était 
une "formalité" pour un moteur, très loin d'être une charge lourde.

> Si on a 10000 utilisateurs en environnement professionnel, cela veut 
> sans doute dire qu'on travaille environ à 100 utilisateurs simultanés, 
> ce qui nécessite une réactivité excellente.
>
> Dans ce cas, les bons principes de dénormalisation tendent, je crois, à 
> privilégier la limitation drastique du nombre de tables.
>
> De plus, les bonnes vieilles formes normales tendent, sauf erreur de ma 
> part, à préconiser que s'il y a identité de structure et de sémantique, 
> il y a sans doute identité d'entité, non ?
Non, c'est pour cela que je me suis laissé l'éventualité de créer 1 base 
de données pour chaques entités, d'où ma question sur le nombre max de 
BD géré par mySQL.

> Bien sûr, il faudrait avoir plus d'informations sur ton besoin et sur 
> l'utilisation qui en sera faite, mais je pencherais pour un attribut 
> "userid" dans chaque table, avec une paire d'index bien léchés.
Oui, ça c'est la réponse du développeur (et du DBA probablement)[1], 
mais j'ai également touché pas mal à la production/l'exploitation et les 
technicien/ingénieur de prod ont un autre point de vue car ils ne sont 
pas confrontés aux mêmes problèmes. Si tu as 10000 entités [2] qui 
utilisent la version 1 d'un soft, et que tu souhaites migrer vers la 
version 2, malgré tous les tests que tu peux faire préalablement un ingé 
d'exploit soigneux préfèrera toujours migrer quelques comptes pour 
valider le bon fonctionnement de l'appli en prod, puis migrer le reste 
par tranche. En cas de merde,(1) il est plus facile de restaurer 
l'ancienne config et bd pour ces quelques comptes, (2) tu n'as pas la 
pression des 10000 utilisateurs pour qui plus rien ne marche et qui ne 
sont pas content, et (3) c'est toujours les techniciens et ingés de prod 
qui se lèvent à 3 heures du mat pour gérer les crises et plus rarement 
les développeurs et les DBA.
Tout ça pour dire que la solution de l'attribut "userid" effraie les 
équipes de prod car les outils de migration/test/validation sont 
rarement budgétisés et donc développé par les équipes de devs, et 
souvent effectué par la prod.


[1] Attention, ce n'est absolument pas péjoratif
[2] Encore une fois chiffre choisi au pifomètre mais pas dénué de sens

> Mathieu Ignacio a écrit :
> > Stéphane Schildknecht wrote:
> > > Pourquoi 4 tables ?
> > C'est juste une estimation de ma part avec mon gros pif, peut-être 3 
> > ou 6. Bref, pas une appli très complexe.
>
> Ca, pour le coup, ça me surprend beaucoup. Une appli simple, en général, 
> a du mal à rester en-deçà d'une vingtaine de tables en raison des 
> besoins en informations transversales (utilisateurs, groupes, tables de 
> référence, j'en passe et des meilleures).
>
> As-tu fait une esquisse de modèle de données ?
Absolument pas, c'est pour cela que je suis resté aussi imprécis. Pour 
un forum, une table message, utilisateur, droits d'accès, catégories. 
Une autre pour gérer les stats probablement. Bon, disons 10 tables, mais 
je pense vraiment pas +.
> Peux-tu faire passer un fichier DBDesigner par exemple ?
Non, en fait j'éprouve une immense réticence à ce que l'on me réponde à 
titre gracieux sur une question professionnelle. Je sais c'est con.

> > > Pourquoi le choix du SGBD aurait-il un impact sur la conception du 
> > > produit ?
> > - Des limitations toutes simples de capacité de stockage peuvent nous 
> > amener à concevoir le logiciel différemment.
>
> Euh... Le prix du disque a baissé, tu sais ;-)
>
> Enfin moi, ce que j'en dis, hein ?

;-) je pensais à des limitations logicielles sur le nombre ou la taille 
des entrées, des tables, des colonnes, des bases de données, etc...


> Cordialement,

Bonne soirée !
a+.

--
Mathieu Ignacio,
* mignacio AT nospam.april.org
* http://pydhcplib.tuxfamily.org/
* http://www.anemon.org/