Discussion :

[Daïmanu]

Bonjour.

En comparant la taille d'une base de donnée locale (conteneur docker), j'obtiens deux résultats différents.
Depuis la base, j'ai deux commandes SQL donnant le même résultat : SHOW TABLE STATUS; et SELECT SUM(round(data_length + index_length, 2)) `Size (B)` FROM information_schema.TABLES WHERE table_schema = "mydb"; (inspiré d'ici).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
+-----------+
| Size (B)  |
+-----------+
| 819200.00 |
+-----------+

Et depuis le disque du --si /var/lib/mysql :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

2.0M	/var/lib/mysql/mydb

Soit environ un rapport de 2,5 (2M / 819200).

L'inverse ne m'aurait pas étonné, avec une compression des données dans la base. Mais ce rapport dans ce sens m'étonne.

Quelqu'un saurait explication une telle différence ?

[Daïmanu]

Question subsidiaire, si je cherche ces infos c'est pour pouvoir extrapoler la taille dans X mois.

Mais du coup, en sachant que certaines tables ne changeront pas en taille, et d'autres pourront largement grossir, je ne sais sur laquelle des deux volumétrie je dois me baser ?
Est-ce que je peux simplement extrapoler depuis la taille dans MySQL, puis multiplier le tout par ~2,5 ?

[SQLpro]

Certaines données étant de taille variable (exemple VARCHAR) la requête dans INFORMATION_SCHEMA donne une réponse théorique qui considère que le remplissage des informations de taille variable est toujours au maximum.
De plus votre requête est fausse car il y a d'autres subtilité. En effet, les lignes des tables contiennent des méta données (donc quelques octets de plus), les pages des tables contiennent aussi des métadonnées (donc quelques octets de plus) de même que les fichiers des bases....

A +

[Daïmanu]

Bonjour.

Effectivement, beaucoup de colonnes sont déclarées en VARCHAR(255), ORM oblige. Je vais changer et optimiser ça, mais ça ne va pas dans le sens de la différence que j'observe.

Pareil pour les métadonnées, si il ne s'agit que de quelques octets, ça ne peut pas remplir tous les MB manquants. Je vais quand même investiguer dans cette direction.

[SQLpro]

...Effectivement, beaucoup de colonnes sont déclarées en VARCHAR(255), ORM oblige. Je vais changer et optimiser ça, mais ça ne va pas dans le sens de la différence que j'observe.

Les ORM sont la pire des choses qui pouvait arriver en matière informatique. Le fait de mettre systématiquement du VARCHAR(255) pour toute données littérale va plomber les performances de manière rédhibitoire. En effet un code postal de 5 caractères sur du VARCHAR(255) va, dans certaines étapes du calcul de la requête, être réaligné à 255 caractères, et donc consommer BEAUCOUP plus de ressources que s'il avait été bien dimensionné.
Pour information, dans un audit pour une grande boite française, les développeurs avaient fini par mettre du VARCHAR(8000) partout et les performances du SGBDR était drastiquement tombées. Lors de l'exécution, certaines requête prenait 30 Go en RAM, alors que le cache en faisait 64... bref, à chaque exécution de ces requêtes près de la moitié du cache des données était expurgé ! En comme ces requêtes étaient exécutées par plusieurs utilisateurs, la mémoire était sans arrêt vidé, rendant le système ultra lent....

LES ORM sont considérés comme le vietnam de l'informatique....
A lire :
http://sqlpro.developpez.com/cours/b...s-epaisses.pdf
https://www.developpez.net/forums/d1...-requetes-sql/

Pareil pour les métadonnées, si il ne s'agit que de quelques octets, ça ne peut pas remplir tous les MB manquants. Je vais quand même investiguer dans cette direction.

Ne croyez pas que ce soit si négligeable que cela. Si la base est mal modélisée, les octets perdu peuvent occuper près de 50 % du volume global de la base.
Si l'on y ajoute l'inévitable fragmentation des données qui arrivent dès qu'il y a des INDERT, UPDATE et DELETE, alors ce volume résiduel inoccupé peut être largement supérieur à 80 % !


A +

[Daïmanu]

LES ORM sont considérés comme le vietnam de l'informatique....
A lire :
http://sqlpro.developpez.com/cours/b...s-epaisses.pdf
https://www.developpez.net/forums/d1...-requetes-sql/

J'ai vu les arguments, mais malheureusement le choix d'utiliser un ORM ne me revient pas. Je ne pourrai que customiser les annotations pour essayer de gagner en performances, mais mes actions sont limitées.

En revanche je garde ça dans un coin de ma tête pour les futurs projets.

Ne croyez pas que ce soit si négligeable que cela. Si la base est mal modélisée, les octets perdu peuvent occuper près de 50 % du volume global de la base.
Si l'on y ajoute l'inévitable fragmentation des données qui arrivent dès qu'il y a des INDERT, UPDATE et DELETE, alors ce volume résiduel inoccupé peut être largement supérieur à 80 % !

Entendu, je présume donc que la différence de taille vient des métadonnées.
Comment déterminer si la base est mal modélisée ? Je n'ai qu'une vingtaine de tables avec une à deux clés étrangères et qu'une dizaine de références. À priori que les bases d'une DB relationnelle.