Page 1 sur 2

Que choisir entre Oracle et MySQL

Posté : 16 oct. 2007, 16:28
par moileraz
Bonjour,
J'ai un petit souci de choix entre Oracle et MySQL.

Je travail sur un gros projet web 2.0 (vidéo). Le site a déjà plusieurs miliers d'abonnés (pour béta privé) et une grosse campagne de pub sera mis en place pour son lancement.

Quel base de donné choisir?

Merci pour votre aide

Re: Que choisir entre Oracle et MySQL

Posté : 16 oct. 2007, 17:01
par Hubert Roksor
Quel base de donné choisir?
Ploum! ploum! ce-sera-toi-que-je-prendrai-au-bout-de-trois.

Je ne connais que très mal Oracle, mais j'imagine que ça dépend grandement de ton budget et de vos compétences internes. Sinon, dans le doute les gens te répondront "MySQL". C'est ce qu'utilise YouTube. [video]

Ensuite, ça dépend aussi des données à traiter, si le contenu est très personnalisé, si vous tirez des milliards de stats qui requerraient des types de jointures particuliers, ou si vous utilisez des vues, etc...

Au fait, ce genres de gros sites m'intéressent particulièrement, tout retour d'expérience sera le bienvenu, comme par exemple les décisions que vous avez à prendre, ce qui consomme le plus de ressources (génération de pages, bande passante vidéo, DB, etc...), comment servir les vidéos (serveur statique comme lighttpd, voir Zeus et cie, proxy Squid, CDN), etc...

Posté : 16 oct. 2007, 20:35
par Sedril
Pour pouvoir être précis dans la réponse il faut savoir de quelle version MySQL on parle, et quelles sont les fonctionnalités que doit fournir le SGBD-R.

On ne peut pas comparer à froid Oracle à MySQL.

Pourquoi vous limiter à ces 2 systèmes (je pense à d'autres comme PostgreSQL) ?
Avez vous déjà des administrateurs de base de donnée ?
Quel est l'existant ?

Posté : 17 oct. 2007, 10:50
par moileraz
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

Posté : 17 oct. 2007, 11:00
par Hubert Roksor
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 Sphinx, 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.

Posté : 17 oct. 2007, 11:06
par Sékiltoyai
MySQL a été utilisé avec des bases de plusieurs TeraOctets d'après Mysql AB.

Posté : 17 oct. 2007, 11:09
par Hubert Roksor
Au fait, j'avais oublié ça :
devra gérer des miliers de requêtes simultanées
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.
MySQL a été utilisé avec des bases de plusieurs TeraOctets d'après Mysql AB.
En effet, la taille importe peu et le nombre d'enregistrements est plus important que leur taille, du point de vue des performances.

Posté : 17 oct. 2007, 12:10
par jojolapine
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 ;)

Posté : 18 oct. 2007, 11:47
par moileraz
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

Posté : 18 oct. 2007, 12:13
par Hubert Roksor
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.

Posté : 18 oct. 2007, 12:59
par moileraz
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 :)

Posté : 18 oct. 2007, 13:05
par Hubert Roksor
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.

Posté : 27 févr. 2008, 14:52
par ShaiLeTroll
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.
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)

Posté : 27 févr. 2008, 15:35
par Berzemus
et quid de MaxDB ?

Posté : 27 févr. 2008, 15:43
par Hubert Roksor
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
À 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, ce bug devrait être corrigé dans MySQL 4.1.24.
et quid de MaxDB ?
Je sais pas, ils sont morts ? :lol: