La seule information que l'on a est qu'il y a enormément de requètes. C'est maigre.
Il va falloir d'autres informations :
a) c'est quoi enormément ? 100/min 1000/min 1M/min ?
b) c'est quoi comme requète ? Requètes simples ? Requètes complexes avec jointure aggregats et conditions ? Appel de procédures stoquées avec des fonctions des 12Mo ?
c) Combien d'utilisateurs simultanés sur la base , typiquement ? En pointe ?
d) Quel est le volume des données retournées ? (Non parceque si c'est systèmatiquement des centaines de milliers de tuples sur une connexion 100Mb/s ca va grincer même si tu mets un cluster Oracle)
e) Combien de tables sont accédées typiquement ? 1 ? 10 ? 100
Attention pub gratuite
De façon générale il faut préférer Postgres à MySQL en cas de forte charge. MySQL est plus rapide sur les requètes simples sur de petites tables, mais il scale très mal et de plus il est assez loin des normes SQL (sans compter qu'il n'y a pas de méthode pour mettre en cluster simplement)
# On va essayer de répondre....
Posté par Jerome Herman . En réponse au journal Performance MYSQL. Évalué à 6.
Il va falloir d'autres informations :
a) c'est quoi enormément ? 100/min 1000/min 1M/min ?
b) c'est quoi comme requète ? Requètes simples ? Requètes complexes avec jointure aggregats et conditions ? Appel de procédures stoquées avec des fonctions des 12Mo ?
c) Combien d'utilisateurs simultanés sur la base , typiquement ? En pointe ?
d) Quel est le volume des données retournées ? (Non parceque si c'est systèmatiquement des centaines de milliers de tuples sur une connexion 100Mb/s ca va grincer même si tu mets un cluster Oracle)
e) Combien de tables sont accédées typiquement ? 1 ? 10 ? 100
Attention pub gratuite
De façon générale il faut préférer Postgres à MySQL en cas de forte charge. MySQL est plus rapide sur les requètes simples sur de petites tables, mais il scale très mal et de plus il est assez loin des normes SQL (sans compter qu'il n'y a pas de méthode pour mettre en cluster simplement)