-
Info optimisation
Bonjour à tous :D
Je dois mettre en place pour un site une base de donnée MySQL qui risque a plus ou moins long terme d'etre volumineuse (je pense 2 a 3 000 000 de lignes) sachant que le serveur et un 3500+ 2Go Ram Linux. (mais cela pourra évoluer)
Cette base sera souvent sollicité en lecture et ecriture puisque le site gerera des petites annonces. Elle est divisé en plus de 1700 catégories/sous catégorie (sur 4 niveaux).
N'ayant jamais traité de base aussi importante j'aurais aimé avoir votre avis sur les optimisations possibles.
Pour ma part je pensais procéder de la sorte. Faire une table par niveau pour avoir la hiérachie. L'annonce ayant l'index final, elle remonte l'arborescence logiquement.
Qu'en pensez vous? Peut etre qu'il vaut mieu créer une table par catégorie, mais a ce moment la l'index sera sur 4 niveaux.
De plus, en faisant des recherches avant de poster, j'ai lu que c'était plus le poid de la BDD que la quantité d'entré qui etait importante. Dans ce cas, je m'embète peut etre pour rien puisque chaque ligne ne pésera pas lourd.
Pour terminer, j'ai beaucoup vu le terme "découper la BDD" sans avoir trouvé de la doc ou des infos sur l'intéret et la facon de faire. Si vous avez des liens :wink:
Merci d'avance :D
-
Bonjour,
Est-ce un serveur dédié MySQL ? Qui fait aussi office de serveur Web ?
Quelle est la charge prévue en nombre d'accès simultanés à la base ?
En ce qui concerne les catégories, ça me parait un peu bloquant de se limiter à 4 niveaux. Une vraie arborescence serait plus flexible, il y a plusieurs méthodes possibles.
http://www.developpez.net/forums/vie...ighlight=arbre
http://www.developpez.net/forums/vie...t=arborescence
-
Merci pour les liens.
Oui c'est un serveur dédiés avec MySQL, qui fait office d'hébergement web mais uniquement pour ce site. Donc toutes les ressources de la machine lui sont réservé.
Pour ce qui est des niveaus c'est imposés par le client selon ses rubriques.
Je suis en effet dans ce shema:
http://dev.mysql.com/tech-resources/...cal-data-1.png
D'ailleurs l'article a l'air bien mais mon anglais est un peu limité donc je vais passer un peu plus de temps a l'analizer.
Sinon au sujet de la découpe, tu aurais quelque chose :wink:
Merci
-
Qu'appelles-tu "découper" une BDD ? Tu aurais un exemple ?
-
Ben pas vraiment justement :?
J'ai vu ca a droite a gauche sans rien trouver de concret.
J'en ai entendu parler pour découper les tables genres de 0 a 10000 de 10001 a 20000 etc...(est ce vraiment utile?) ou aussi pour ne pas générer des fichiers trop lourd (genre pour ne pas avoir 1 fichier de 15Go), mais a ce moment la comment ca se gere :?
Bref beaucoup d'interrogation.
:?:
-
OK, il doit s'agir du partitionnement de tables.
C'est vrai que ça peut améliorer les performances, mais la fonctionnalité n'est disponible que sous MySQL 5.1, qui est encore en beta.
-
Salut,
Si la cible est de 2 à 3 millions de lignes en tout c'est relativement faible.
Le partitionnement sera un plus mais généralement, je ne le considère que peu utile en dessous de 2 millions de lignes dans la table. Et encore c'est très arbitraire.
Donc il y a pas encore péril dans la demeure pour ta base. :D
Mais c'est à regarder quand même. Par contre, si tu as une table de 3 millions de lignes, partitionne pas en tranche de 10000 ;), au pire en 2, au max en 4 ou 5.
Autre conseil : essaie d'avoir des partitions équilibrées :)
Enfin, si y a urgence sur le partionnement : change de SGBD
-
Ok!
Merci bien.
Aprés avoir un peu étudier les techniques d'arborescences, j'ai donc décidé d'un commun accord avec moi meme :lol: de rester sur des tables séparés pour chaque niveau.
D'autant plus que le client en a fait sauté un ce qui n'en laisse plus que 3.
J'ai quand meme bien vu la gestion intervallaire qui m'a l'air trés puissante, trés facile a en comprendre le principe mais qui m'a l'air beaucoup plus lourde a mettre en place.
Surtout que je n'ai que les base en SQL (a vrai dire je pensais meme pas que c'était aussi pointu :oops: Je croyais que tout se passé par PHP :roll: Ca m'apprendra 8) )
Bref, voici un exemple de ma structure:
http://www.23d-conception.com/forum/plan_sql_01.jpg
Le petit souci c'est que les annonces peuvent aussi ne dépendre que du 2e niveau, a savoir "categorie".
J'ai un peu de mal a modeliser ca sans passer par la rubrique :calim2:
Dois je faire une table d'annonce séparé?
Une idée???
Merci
-
Dans cette situation je crois que le plus simple c'est de faire 2 classes annonces.
Sinon tu peux aussi mettre 2 FK dans ta classe annonce et remplir celui qui convient mais je pense pas que ce soit terrible même si ça fonctionnerait.
---------------
Il y a aussi une autre solution qui serait de fusionner tes tables categorie et rubrique puis d'ajouter un attribut (id_pere) pour créer un lien père-fils au sein de cette table.
Dans ce cas, tous les enregistrements que tu considères actuellement comme des "rubriques" auraient l'attribut "id_pere" renseigné, ce qui permettrait de connaître à quelle catégorie appartient chaque rubrique. Si l'attribut n'est pas renseignée (null) alors c'est que tu aurais à faire à une catégorie.
La classe annonce resterait inchangée, mais la FK qu'elle contient désignerait soit une rubrique, si l'enregistrement correspondant dans la table fusionnée a une valeur pour id_pere, soit une categorie si id_pere est à null.
Après faut voir si ta base de données permet de faire des FK au sein d'une même table.
Voilà, bonne chance!
-
Merci.
Moi aussi je ne pense pas que faire plusieurs table d'annonce soit une bonne idée.
J'avais aussi pensé a faire une seul table avec le parent enfant a l'intérieur, mais comme le client veut la possibilité de modifier les groupes, les categories et les rubriques a sa guise, cela risque de poser probleme. Car on peut tout aussi bien avoir un groupe qui n'a pas de categories.
Je pensais a ca sinon: créer une table intermédiaire qui contiendrai la relation entre l'annonce et son parent le plus proche. Une fois qu'on a ca on peut remonter facilement et le niveau importe peu.
Qu'en pensez vous?
Merci de votre aide :wink:
-
-
Je suis en train de penser qu'il serais peut etre inutile de passer par une table intermédiare, si je stocke directement le niveau dans l'annonce, non?
Serait ce moin performant?
:?
