Performances de MySQL [Résolu]

[toffff]

Bonjour,

J'ai besoin de conseil concernant les performances de mysql.

En effet, je suis en train de dev un site pour la boite ou je bosse et je viens de m'appercevoir que j'allais peut-être avoir quelques problèmes au niveau des perf max de mysql.

En 2 mots voici ce que je réalise:

Je travail pour une boite qui est implanté sur toute la France.
Chaque région possède ca propre agence et chaque agence est donc responsable de toutes les communes de ca région.

Au départ, le projet intranet que j'ai dev concernant uniquement mon agence (en gros 1000 communes) mais aujourd'hui on me demande de mettre en place l'application pour toute les agences de France (soit plus de 36 000 communes).

Mon inquiétude est de savoir si dans un premier temps mysql est capable de gérer une table contenant 36000 communes.

Ensuite, chaque agence qui utilisera l'application ne verra que les communes qui les concerne. Ma seconde question est donc de savoir si le fait de requêter dans une table contenant 36 000 communes et d'en sortir entre 700 et 1000 ne risque pas de faire ramer totalement l'application intranet?

Je ne connais pas bien les limite de mysql associé avec php d'ou ces questions avant de me lancer tête baissée en créant une seule et unique table reprenant toute mes communes.

Autrement, j'ai toujours la solution de créer une table par agence (c'est moins propre mais si je n'ai pas le choix....).

Qu'en pensez vous?

Merci d'avance.

[Biglo]

Salut,

Première chose : il est difficile de te répondre si MySQL peut gérer "une table contenant 36 000" communes. Il serait mieux de parler en terme d'espace disque occupé par cette fameuse table.

Mais je doute que tu aies beaucoup de problèmes de performances, surtout si la plupart des requêtes exécutées peuvent tirer profit d'index.

En ce qui concerne le pourcentage de données accédées par rapport aux données totales, tu soulèves un problème intéressant. En effet, si chaque agence avait sa propre table, les performances seraient bien meilleures.

Comme tu le dis, ce n'est pas très propre... Et c'est là que le principe du partitionnement (horizontal) intervient. Une seule table est vue dans MySQL mais sur le disque dur, la table est répartie en plusieurs fichiers plus petits. Et MySQL ne lit que les fichiers qu'il a besoin.

Une gestion correcte du partitionnement ne sera disponible qu'à partir de MySQL 5.1 (et encore, je pense que ça ne sera pas vraiment au point ). Il est néanmoins possible d'utiliser le moteur de stockage MERGE pour les versions inférieures (au moins la 5.0).

Si mon explication n'est pas très claire à propos du partitionnement, je t'invite à lire l'introduction de l'article que j'ai redigé. voire même l'intégralité pour préparer le futur de ton application si un jour tu migreras vers MySQL 5.1

[Sivrît]

Bien... 36000 c'est petit . Avec les machines actuelles ça a de bonnes chances de tenir en RAM (suivant le contenu) ce qui limite grandement les problèmes de disques, et si les requêtes sont proprement indéxées ça va aller.

C'est plutôt la quantité de requêtes qui seront effectuées et la bande passante nécessaire dont il faudra probablement s'occuper. Qu'elle est l'affluence attendue ? Si c'est un client par région, à moins que le site soit très lourd, ça devrait être gérable (louchomètre inside).

[toffff]

Avant tout merci pour vos réponse.

C'est pas vraiment la table en elle même qui m'inquiète car finalement, il y a peu de données dans celle ci:

un champ "codePostal"
un champ "commune"
un champ "idAgence"

C'est plutôt le nombre d'entrées (36700) et par conséquent les requêtes qui m'inquiète (en sachant que j'ai pas mal de tri du même type sur cet outil étant donné que chaque agence doit avoir ces propres spécificités).

Par contre, qu'est ce que vous entendez par:
"surtout si la plupart des requêtes exécutées peuvent tirer profit d'index."
"requêtes sont proprement indéxées ça va aller."

??

Encore merci

[Biglo]

En supposant que la plupart de tes requêtes auront une condition comme "WHERE idAgence = x", si tu as défini un index pour cette colonne idAgence, MySQL sera capable de récupérer rapidement les résultats qui t'intéressent. Ca lui évite de parcourir les 36700 lignes de la table.

Mais bon, si tu n'as que ça comme données à stocker dans la table, ça va à peine dépasser le méga octet. Tu n'as pas à t'en faire pour MySQL pour si peu Et le partitionnement ne sera pas intéressant non plus.

[toffff]

si tu as défini un index

Je ne connaissais pas le fait d'indexer une colonne dans une table.. Je vais faire quelques recherches à ce sujet.

Merci

[Florian]

Envoyé par toffff

Je ne connaissais pas le fait d'indexer une colonne dans une table.. Je vais faire quelques recherches à ce sujet.

Merci

Comme tous les sgbd, indexer une colonne augmente les performances d'un facteur tel que faire sans c'est une erreur
Si en plus l'index est une clé unique (ce qui devrait être le cas pour les communes) alors c'est encore mieux.