NPDS : Gestion de contenu et de communauté
Content & Community Management System (CCMS) robuste, sécurisé, complet, performant, parlant vraiment français, libre (Open-Source) et gratuit.
27 visiteur(s) et 0 membre(s) en ligne.
Autres infos
Activité du Site
Pages vues depuis 25/05/2001 : 109 368 390
- Nb. de membres 8 695
- Nb. d'articles 1 695
- Nb. de forums 26
- Nb. de sujets 8
- Nb. de critiques 92
Index du forum »» Le coin des codeurs »» MySQL peut-il gérer de très gros volumes ?
MySQL peut-il gérer de très gros volumes ?#6079
4Contributeur(s)
3 Modérateur(s)
ratp_isv
Bonjour,
Je ne sais pas si je suis dans le bon forum pour ma question.
Il s'agit de la possibilité de gérer de gros volumes sur un serveur sous linux.
J'aimerais savoir si MySQL est envisageable pour une grosse base ( entre 500 Mo et 1 Go).
Je crois comprendre que MySQL n'est pas fait pour ça.
Mais peut-on avoir plusieurs bases sur le même serveur ?
Et qui communiqueraient ensemble ? Avec qqchose qui ressemble à des "database links" sous Oracle.
Merci par avance à celle ou celui qui pourrait me donner des infos.
Je ne sais pas si je suis dans le bon forum pour ma question.
Il s'agit de la possibilité de gérer de gros volumes sur un serveur sous linux.
J'aimerais savoir si MySQL est envisageable pour une grosse base ( entre 500 Mo et 1 Go).
Je crois comprendre que MySQL n'est pas fait pour ça.
Mais peut-on avoir plusieurs bases sur le même serveur ?
Et qui communiqueraient ensemble ? Avec qqchose qui ressemble à des "database links" sous Oracle.
Merci par avance à celle ou celui qui pourrait me donner des infos.
developpeur
Les gros volumes ne font pas peru à MySql mais :
- Mysql ne dispose pas des proc-stockées
- l'analyseur et l'optimiseur sont moins puissants que ceux d'oracle par exemple
- Mysql est pas trop bon sur les jointures (les grosses)
- par contre, avec de bon index, la vitesse est là
- plusieures bases : voui, réparties voui aussi
=> en fin de compte, pour de gros projet, j'aurais tendance à dire : postgre (7.3.x)
- Mysql ne dispose pas des proc-stockées
- l'analyseur et l'optimiseur sont moins puissants que ceux d'oracle par exemple
- Mysql est pas trop bon sur les jointures (les grosses)
- par contre, avec de bon index, la vitesse est là
- plusieures bases : voui, réparties voui aussi
=> en fin de compte, pour de gros projet, j'aurais tendance à dire : postgre (7.3.x)
EBH
Pour avoir utilisé mySQL récemment pour un projet où les bases de données (au nombre de 3 pour être exact et sur le même serveur) font entre 400Mo et 800Mo, je dois avouer que ça marche plutôt bien.
Effectivement, mieux vaut bien choisir ses index, ça demande un peu plus d'espace disque mais cela améliore sensiblement les performances.
La seule remarque que j'ajouterais, c'est que l'on est parfois à la limite de temps d'exécution des scripts (limité par le serveur web). Du coup, il faudra p-e en revoir la valeur un peu à la hausse pour s'assurer que ça passe dans tous les cas.
Effectivement, mieux vaut bien choisir ses index, ça demande un peu plus d'espace disque mais cela améliore sensiblement les performances.
La seule remarque que j'ajouterais, c'est que l'on est parfois à la limite de temps d'exécution des scripts (limité par le serveur web). Du coup, il faudra p-e en revoir la valeur un peu à la hausse pour s'assurer que ça passe dans tous les cas.
Anonyme
Eh bien c'est très très intéressant ce que vous dites. ça veut dire que c'est possible alors. Merci à tous pour vos réponses.
ratp_isv
woops, vous en doutez p-e mais le message précédent de "anonyme" c'est bien moi 'ratp_isv'.
Si on passe par Netscape ça ne mémorise pas le login.
voilà voilà.
A+
Si on passe par Netscape ça ne mémorise pas le login.
voilà voilà.
A+