[MYSQL POSTGRESS] Comparatif taille bdd

[PamelaGeek]

Bonjour,

J'utilise mysql5 pour héberger une base de données de 15Go, amenée à grossir d'1Go par an. je trouve les requêtes très lentes, je me demande si j'atteins les limites de mysql ? Postgress est-elle meilleure ? Postgress supporte t-elle davantage de données ? Existe t-il des comparatifs ? Merci.

[vtrone]

Comparatif : http://fadace.developpez.com/sgbdcmp/

Sinon, avant de changer de SGBD, il faudrait savoir si vous effectuer la maintenance de vos tables, vos index etc....

Ensuite, les requêtes sont-elles correctement écrites ? Une requêtes rapide pour 100 000 lignes ne le sera pas forcément pour 1 000 000 de lignes, et la dégradation n'est pas forcément proportionnelle au nombre de lignes. Un réécriture des requêtes peut améliorer vos performances de manière significative .

[SQLpro]

Je dirais même plus :
1) la structure des tables peut améliorer d'un facteur de 2 à 100
2) le choix des index peut améliorer d'un facteur de 2 à 10 000

A +

[PamelaGeek]

Merci pour vos réponses.
Par rapport à la structure des BDD, à quoi pensez-vous ?
Avec mysql5, J'utilise des tables innoDB, et mon client myIsam, ça peut avoir une incidence sur les perfs dans mon cas d'énorme BDD de 15Go ?

[vmolines]

Concernant la structures des tables :

- Tes tables sont-elles en forme normale ? la normalisation diminue la taille des enregistrements au minimum et accélère leur lecture. La lecture d'enregistrements inutilement chargés est un frein.
- Les index sont-ils correctement définis et maintenus ?
- Les plans d'exécution des requêtes incriminées ont-ils été analysés pour voir si les indexes en place sont correctement utilisés ou si des indexes sont nécessaires ?
- Les requêtes méritent peut-être une réécriture pour mieux tirer profit de la structure et des indexes.

Avec mysql5, J'utilise des tables innoDB, et mon client myIsam, ça peut avoir une incidence sur les perfs dans mon cas d'énorme BDD de 15Go ?

Ton client ne peut être MyIsam car c'est un moteur de table tout comme InnoDB. Tout comme SQLPro, je pense qu'avant de te pencher sur ton moteur de SGBDR, tu devrais analyser la manière dont tu t'en sers. Ta BDD peut faire 15go, chaque requête que tu executes ne brasse pas l'intégralité de ta base n'est ce pas ?

[PamelaGeek]

1. Je dis que mon client(l'entreprise cliente, pas le client SQL) est myisam car c'est ce qui apparait dans la définition de ses tables, alors que dans le script de création de BDD, il était spécifié innoDB...

2. Pas 15Go non, la plupart des requêtes portent néanmoins sur un spectre de 1 ou 2 Go en général, et portent sur un ensemble de 10 tables, avec qq jointures.

3. Je vais fouiller la question des index, ils existent par défaut sur chaque clé primaire, mais je ne les maintiens pas à ma connaissance

[vmolines]

Envoyé par PamelaGeek

1. Je dis que mon client(l'entreprise cliente, pas le client SQL) est myisam car c'est ce qui apparait dans la définition de ses tables, alors que dans le script de création de BDD, il était spécifié innoDB...

Assure toi que ton serveur SQL est paramétré pour que la gestion des tables InnoDB soit activée. Si ce n'est pas le cas, voir le comportement d'un script de création mentionnant un moteur de table non disponible sur le serveur.

Pour voir comment rendre disponible un moteur de tables sur ton serveur MySQL, réfère toi à la documentation officielle qui est très riche.

Ne parle pas de client ni d'entreprise cliente mais plutôt de moteur de table car c'est vraiment difficile à comprendre.

Sinon, ton besoin nécessite-t-il des tables transactionnelles ? De toute façon je dirais que ça relève d'un autre sujet car ça n'a rien à voir avec tes problèmes de perf.

Envoyé par PamelaGeek

2. Pas 15Go non, la plupart des requêtes portent néanmoins sur un spectre de 1 ou 2 Go en général, et portent sur un ensemble de 10 tables, avec qq jointures.

3. Je vais fouiller la question des index, ils existent par défaut sur chaque clé primaire, mais je ne les maintiens pas à ma connaissance

Assure toi que tes jointures portent sur des rubriques indexées. Si tu fais toujours les jointures sur les PK des tables référencées et si tes tables sont bien modélisées alors les jointures tireront profit des indexes (c'est un peu généraliste comme remarque, à ne pas prendre pour argent content).

Afin de vérifier ceci de manière sûre, analyse le plan d'execution de tes requêtes avec la commande EXPLAIN. Voir la doc officielle qui traite très bien du sujet.

Si tu ne comprends pas pourquoi certains de tes indexes ne sont pas utilisés, réfère toi encore à la documentation MySQL pour voir comment le moteur utilise ou non les indexes.

Si, apès avoir réussi à avoir un plan d'execution optimisé, tu rencontres encore des gros problèmes de perfs sur tes requêtes, alors tu pourras envisager une autre piste (configuration du serveur par ex.)

[SQLpro]

Il faut ajouter des index :
1) sur toutes les clefs étrangères
2) sur toutes les colonnes les plus fréquemment cherchées;

Au niveau de la structure de la base (modélisation des tables), outre le respect des formes normales, il est important que vos clefs soient les plus courtes possible : monocolonne et si possible un entier. Évitez les clefs sémantiques, les clef en chaine de caractère set surtout de longeur variable...

Enfin, maintenez vos index régulièrement (en même temps que la sauvegarde).

A +

[PamelaGeek]

Je vais donc revoir mes index.
En fait, si je résume, même avec une bdd de 15Go, des requêtes complexes avec multi jointures portant souvent sur la moitiée de la base, une dizaine d'utilisateurs au même moment :
mysql5 peut très bien convenir, et postgresql n'est pas forcément un meilleur choix ?

[vmolines]

Pas forcément non car ici on voit clairement qu'il y a un problème de performance dû à la mauvaise modélisation et/ou utilisation de ta base.

Tu as déjà ton système d'informations sous MySQL donc le coût en temps pour une éventuelle migration me fait dire que ce n'est pas un bon choix que de changer de base sans savoir si on est "au bout" de ce que peut offrir la présente.

[PamelaGeek]

pardon ? En quoi est-il clair que ma base pose un problème de modélisation et/ou utilisation ??

[vmolines]

Le fait de ne pas savoir à quoi est due une lenteur d'exécution de ses requêtes est en soi un problème d'utilisation selon moi. A toi de me donner tort quand tu auras fait tes tests et tes recherches .

[PamelaGeek]

je ne pensais pas à "te donner tort", je me demandais seulement si j'avais dit qqchose qui prouvait que j'utilisais mal ma BDD, ou que 15Go était une ineptie pour mysql par exemple (ce que des gens m'ont dit déjà)

[vmolines]

Non rien ne me permet de l'affirmer parmi les informations que tu nous as transmises.

Je pense qu'affirmer de but en blanc que MySQL ne peut pas s'en sortir avec 15Go est extrêmement minimaliste. J'ai toujours vu d'un mauvais oeil les gens qui sous-estiment souvent à tort la capacité des SGBD.

[SQLpro]

L'important n'est pas la taille de la base de données, mais le volume des données utilisées que l'on apelle fenêtre de données. Si cette fenêtre de données est de 10% de la taille de la base et que celle-ci fait 15 Go, 1,5 Go de RAM suffit à la mettre en cache et donc très peu de requêtes auront besoin de lire le disque.

Cependant une mauvais modélisation implique :
1) une fenêtre de données beaucoup plus large que prévue
2) un volume de données beaucoup plus lourd qu'il ne faudrait

Aujourd'hui il existe des bases de données de plus de 100 To qui donnent toute satisfaction.

Bien modélisé et avec peu de transactions en mise à jour (point faible de MySQL), 15Go de données ne devrait pas vous poser de problèmes majeurs.

A +