On pourrait aussi dire que Sun n'est surement pas le moins bien placé pour prendre en considération toutes ces problématiques lors des futurs développements du SGBDR :)

Pour mémoire, les serveurs de Google tournent avec MySQL aussi : j'ignore totalement le nombre de clusters qu'ils utilisent, mais coté montée en charge, je crois qu'ils ont démontré que MySQL tient parfaitement la route.

Maintenant ça dépendra aussi en grande partie de l'optimisation des configuration et de la qualité de l'application. Et avoir un vrai DBA ne nuirait pas non plus, il est précisément formé pour ce genre de chose.

Je ne déconseillerai pas du tout MySQL non plus, pour peu qu'il n'y ai pas de tâches critiques dans ton application, et encore ! (Billetel -- service billetterie de la Fnac -- travaille avec MySQL, alors qu'il y a des tâches critiques !)

[quote="ShaiLeTroll"]Cette remarque m'intéresse, cela signifie-t-il que MySQL (version 4.1 d'un EasyPHP 1.8), aurait des problèmes sur une machine Multi-Core[/quote]
À ma connaissance, et je ne me base que sur ce que j'ai pu lire à ce sujet, le problème des multi-core n'est apparent qu'à partir de ~8 cores, et concerne l'exécution des requêtes, pas la connexion à la base. De plus, [url=http://bugs.mysql.com/bug.php?id=15815]ce bug devrait être corrigé dans MySQL 4.1.24[/url].

[quote="Berzemus"]et quid de MaxDB ?[/quote]
Je sais pas, ils sont morts ? :lol:

et quid de MaxDB ?

[quote="Hubert Roksor"]Si vous utiliser une DB sur un gros multi-CPU/multi-core, il vous faudra impérativement utiliser une version récente de MySQL, qui ont reçu des patches de performance pour ce type de configuration.[/quote]

Cette remarque m'intéresse, cela signifie-t-il que MySQL (version 4.1 d'un EasyPHP 1.8), aurait des problèmes sur une machine Multi-Core, ce type de machine se répend chez nos clients, et on a eu récemment, des lenteurs (à l'ouverture de la connexion, semble-t-il) avec les nouveaux serveurs (on a cru à une lenteur liée au RAID5, alors qu'avant il n'y a avait qu'un simple ATA)

Par exemple, ce serait cool de publier les résultats d'EXPLAIN pour les requêtes les plus courantes / complexe, afin de se faire une idée du type de requêtes que tu vas exécuter, ainsi que pour leur intérêt académique.

Pour l'optimisation du code, cela comprend les requêtes, la structure de l'algorithm. Oui nous avons utilisé 'EXPLAIN'.

je vous donnerai des "feedbacks" sur les reactions des bases :)

Si je peux être franc, changer de SGBD en plein milieu est la pire chose à faire. Les problèmes de perf se gèrent 99% du temps au niveau de l'application, pas du serveur (pour peu que ce dernier soit correctement configuré). Par exemple, tu parles d'optimisation du "code", est-ce que ça comprend les requêtes elles-mêmes ? Est-ce que vous avez étudié les plans (EXPLAIN) de chaque requête ? C'est vraiment le premier truc à faire pour garantir de bonnes perfs au niveau du SQL, et c'est beaucoup plus rentable que se ruiner sur des licences Oracle.

Merci pour vos retours.

Sur notre base il y a plusieurs sous requêtes. Actuellement ca tourne sans problème sous MySQL. Je pense que pour se faire un avis on dois voir comment MySQL reagira en production. Je lui laisse sa chance :D Car au niveau du code on l'a revu plusieurs fois pour l'optimiser. Je pense que l'infrastructure devrait aussi avoir un impact. Actuellement nous avons 2 serveurs que pour la base.


Et si nous avons des petits souci de ralentissement au niveau de la base on passera sous Oracle

Pour donner un exemple de "gros site", il y a le site du zero (siteduzero.com) qui tourne à peu près à 250 visiteurs simultanés toute la journée... avec de nombreux tutoriels, un forum très actif...
Au départ le site à été développé avec mysql, et il ont fait récemment une migration sur postgreSQL
Après je n'en sais pas plus sur les SGDB à choisir ...
Bonne chance ;)

Au fait, j'avais oublié ça :
[quote="moileraz"]devra gérer des miliers de requêtes simultanées[/quote]
Quand tu dis "des milliers de requêtes simultanées", est-ce une hyperbole ? Parce qu'une telle charge correspond à un nombre de visiteurs simultanés à 5 chiffres, et il y a sûrement d'autres problèmes à prendre en compte.

[quote="Sékiltoyai"]MySQL a été utilisé avec des bases de plusieurs TeraOctets d'après Mysql AB.[/quote]
En effet, la taille importe peu et le nombre d'enregistrements est plus important que leur taille, du point de vue des performances.

MySQL a été utilisé avec des bases de plusieurs TeraOctets d'après Mysql AB.

Là encore, tout dépend des requêtes. Est-ce que ces requêtes se font sur des vues ? Est-ce que ces requêtes utilisent beaucoup de sous-requêtes ? Auquel cas, l'optimiseur de MySQL ne vous suffira pas si vous n'avez pas optimisé ces cas à la main.

D'ailleurs, tu dis avoir de nombreuses requêtes complexes... mais sur quel SGBD ont-elles été développées ? De plus, comment fonctionne cet algorithme complexe pour la pertinence des recherches ? Ça me semble étrange d'implémenter un tel algorithme en SQL et j'ai bien peur que les performances soient mauvaises. Si je devais monter un gros site, je m'orienterais plutôt vers [url=http://www.sphinxsearch.com/]Sphinx[/url], qui est très très rapide et tout à fait pertinent d'après ce que j'ai pu voir (bien meilleure pertinence que le FULLTEXT de MySQL).

La meilleure façon pour toi de savoir si MySQL tiendra le coup c'est de le vérifier par un générateur de requêtes comme ab (Apache) ou httperf. D'un autre côté, si vous avez des problèmes de performance c'est au niveau de l'application qu'il faudra les régler, je doute que changer de SGBD changera quoi que ce soit.

Si vous utiliser une DB sur un gros multi-CPU/multi-core, il vous faudra impérativement utiliser une version récente de MySQL, qui ont reçu des patches de performance pour ce type de configuration.

Bonjour merci pour vos réponses, alors la version de MySQL est 5. Nous disposons d'administrateur de base. Pourquoi nous limité à ces deux version de base tout simplement par habitude.

La base devra gérer un nombre de données très important (plusieurs GO) et nous avons créer un algorithm complexe pour la pertinence des recherches. Je tiens beaucoup à utiliser MySQL mais avec une base de taille aussi importante et qui devra gérer des miliers de requêtes simultanées(les unes plus complexe que les autres) est-ce que MySQL tiendra le coup?

N'y aura-t-il pas un ralentissement?

Merci encore pour vos réponses