questions à se poser pour choisir le SGBD le plus approprié

fgalves · 07/12/2010, 08h18

Bonjour,

Je suis en train de préparer un document pour aider aux utilisateurs de choisir le SGBD le plus approprié selon leurs besoins. Le choix porte sur les SGBD suivants: Oracle, SQL Server, PostgreSQL et MySQL.

Pour cela, je suis en train de réfléchir aux principales questions à se poser; elles devraient permettre de les diriger vers une solution adaptée à leur problématique.

Voici les questions:

- Quel volume de données et sur combien de "lignes"?
Commentaire: Pour des grands volumes, privilégier Oracle et SQL Server. Pour des petits volumes, privilégier PostgreSQL et MySQL.

- L'évolution de la volumétrie est connue en avance de phase? Faut-il privilégier la scalabilité?
Commentaire: idem question précédente

- Quel types de données doit-on stocker? (données, documents, images, …)
Commentaire: ?

- Quel type d'application va attaquer la base de données? (Web, transactionnel (OLTP), OLAP, Datamining, …)?
Commentaire: Si c'est du Web, privilégier MySQL. Si c'est du transactionnel, privilégier Oracle et SQL Server (voire même PostgreSQL). Si c'est du Datamining, privilégier Oracle et SQL Server.

- Combien d'utilisateurs pourront accéder concurremment à la base?
Commentaire: puis-je privilégier un SGBD en particulier?

- Les pré-requis de stockage sont-ils connus en avance de phase?
Commentaire: puis-je privilégier un SGBD en particulier?

Auriez-vous des remarques à faire ou d'autres questions à rajouter dans la liste?

Merci par avance,
Cdlt,
Fgalves

CinePhil · 07/12/2010, 09h18

Citation:

Envoyé par fgalves

- Quel volume de données et sur combien de "lignes"?
Commentaire: Pour des grands volumes, privilégier Oracle et SQL Server. Pour des petits volumes, privilégier PostgreSQL et MySQL.

Encore faut-il définir le nombre de lignes qui correspond à un "grand volume" !
Postgresql et Mysql permettent l'interrogation de tables de plusieurs dizaines de millions de lignes sans problème, pour autant que la BDD soit bien modélisée, bien indexée, que la requête soit bien construite et que le serveur ne soit pas sous-dimensionné.
Par contre pour l'écriture, il paraît que MySQL est un veau sur les grosses tables. Ma seule (mauvaise) expérience en ce domaine est l'indexation de tables de plusieurs millions de lignes qui laissait largement le temps d'aller prendre l'apéro.

Citation:

- Quel types de données doit-on stocker? (données, documents, images, …)
Commentaire: ?

Si on veut absolument stocker des documents ou des images dans la BDD, il vaut mieux se diriger vers SQL Server qui propose des dispositifs spéciaux pour contrôler entièrement l'accès aux fichiers. Mais d'une manière générale, éviter de stocker des images ou documents en BDD.
Il y a aussi un autre type de données particulier à prendre en compte : les données géospatiales. Et là il vaut mieux éviter MySQL dont les fonctionnalités en la matière ne sont pas au top, contrairement à Postgresql avec l'extension Postgis qui est très utilisé.

Citation:

- Quel type d'application va attaquer la base de données? (Web, transactionnel (OLTP), OLAP, Datamining, …)?
Commentaire: Si c'est du Web, privilégier MySQL. Si c'est du transactionnel, privilégier Oracle et SQL Server (voire même PostgreSQL). Si c'est du Datamining, privilégier Oracle et SQL Server.

Le web peut être une interface pour une application complexe demandant une grande rigueur et des performances dans la gestion des données, ce en quoi MySQL est loin de la première place ! Et je pense que les autres SGBDR fonctionnent très bien aussi avec les applications web. Ce n'est pas le SGBD qui fait le web, c'est l'application web qui interroge la BDD, quel que soit le SGBDR.

Pas d'avis argumenté sur le reste.

À prendre en compte aussi dans le choix : le budget !
Oracle est cher, SQL Server existe en version gratuite mais limitée, MySQL est faussement gratuit et Postgresql est entièrement gratuit.

L'environnement peut aussi entrer en ligne de compte. SQL Server ne fonctionne que sous Windows et si le client refuse cet OS dans son SI, c'est de suite un candidat à éliminer malgré ses grandes qualités.

Dans quel but veux-tu faire ce document ?

fgalves · 07/12/2010, 13h18

Merci pour vos remarques.

Citation:

Envoyé par CinePhil

Dans quel but veux-tu faire ce document ?

Le but de ce document est de "guider" les différents projets (clients potentiels du service "bases de données" de notre DSI) vers le choix du SGBD le plus adapté à leurs besoins.

kedare · 07/12/2010, 13h28

Une autre question que tu devrais te poser: prévois tu de faire du scale-out ? (scaling horizontale), c'est très important car si tu commence à avoir énormément d'utilisateurs simultanés, tu sera obligé de passer par la, et sur ce point la, tous les systèmes ne sont pas égaux (genre PostgreSQL s'en sort plutôt mal..)

SQLpro · 07/12/2010, 20h12

Citation:

Envoyé par fgalves

- Quel volume de données et sur combien de "lignes"?
Commentaire: Pour des grands volumes, privilégier Oracle et SQL Server. Pour des petits volumes, privilégier PostgreSQL et MySQL.

Vous oubliez IBM DB2...

Citation:

- L'évolution de la volumétrie est connue en avance de phase? Faut-il privilégier la scalabilité?
Commentaire: idem question précédente

Avant de commencer à faire du scale out qui coute TRES TRES TRES cher et en fait est totalement utopique, il convient d'épuiser le scale up. Avez vous un seveur avec 128 CPU, 2 To de RAM et 300 To de disque ????
En fait le sacle out est une idiotie, car il faut trouver un moyen de dupliquer les données d'un serveur à l'autre... inutile de vous dire que le cout de duplication peut consommer énormément de ressources. Je me souviens d'une intervention chez un client ou les serveurs était en scale out et 99,8% des CPU occupés à gérer la duplication des données en mode synchrone !!!

Citation:

- Quel types de données doit-on stocker? (données, documents, images, …)
Commentaire: ?

Excellente question... Avez vous besoin de XML, des données géographiques, du full text??? A lire :
http://blog.developpez.com/sqlpro/p9...ext-search-no/
http://blog.developpez.com/sqlpro/p9...n-geographiqu/

Citation:

- Quel type d'application va attaquer la base de données? (Web, transactionnel (OLTP), OLAP, Datamining, …)?
Commentaire: Si c'est du Web, privilégier MySQL. Si c'est du transactionnel, privilégier Oracle et SQL Server (voire même PostgreSQL). Si c'est du Datamining, privilégier Oracle et SQL Server.

J'espère que vous plaisantez avec MySQL pour du web !!! Aucune application web transactionnelles un peu sérieuse ne fonctionne avec ce pseudo SGBDR.
Par exemple fnac.com ou tgv.com (respectivement 1er et 2e site marchand français fonctionnent l'un avec Oracle l'autre avec SQL Server. Et pour un site web international, même Oracle ne sait pas les gérer correctement car il ne gére pas les collation et sur ce sujet MySQL en est encore à l'age de pierre !!!!
A lire : http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/

Citation:

- Combien d'utilisateurs pourront accéder concurremment à la base?
Commentaire: puis-je privilégier un SGBD en particulier?

Tout dépend si c'est plus en lecture ou plus en écriture. SQL Server est meilleure en optimisation de requêtes SELECT. Oracle est meilleurs en gestion des transactions. Bref, jusqu'à 30 000 utilisateurs pas de problème, mais il faut les ressources machine en rapport !

Citation:

- Les pré-requis de stockage sont-ils connus en avance de phase?
Commentaire: puis-je privilégier un SGBD en particulier?

Si gros volume gestion des espaces de stockage fine, obligatoire. Mais aussi sauvegarde compressées et/ou parallélisée.
Exit donc MySQL et PostGreSQL...

Citation:

Auriez-vous des remarques à faire ou d'autres questions à rajouter dans la liste?

Des tas !!!

A +

kedare · 07/12/2010, 22h05

Sauf pour pour le scale-in, une machine 2x plus puissante coute (beaucoup) plus de 2x plus chère, il est CLAIREMENT plus rentable de passer par du scale-out, entre prendre un mainframe a plusieurs centaines de milliers d'euros, et pouvoir faire un cluster de 150 a 200 serveurs pour le même prix, on obtiendra de bien meilleurs performances avec le cluster...
C'est pas pour rien que tous les gros sites fonctionnent comme ça... (+ sharding pour certains)
Après forcement si on passe par des RDMBS proprio avec des licences de plusieurs milliers d'euros par CPU ou par serveurs... Fallait y penser avant

fgalves · 08/12/2010, 10h51

Citation:

Envoyé par SQLpro

Des tas !!!

A +

Bonjour,

Merci SQLpro pour tes remarques toujours précieuses.
Si tu as d'autres questions à proposer, je suis preneur!

Merci!
Cdlt,
Fgalves

SQLpro · 08/12/2010, 20h36

Citation:

Envoyé par kedare

Sauf pour pour le scale-in, une machine 2x plus puissante coute (beaucoup) plus de 2x plus chère, il est CLAIREMENT plus rentable de passer par du scale-out, entre prendre un mainframe a plusieurs centaines de milliers d'euros, et pouvoir faire un cluster de 150 a 200 serveurs pour le même prix, on obtiendra de bien meilleurs performances avec le cluster...
C'est pas pour rien que tous les gros sites fonctionnent comme ça... (+ sharding pour certains)
Après forcement si on passe par des RDMBS proprio avec des licences de plusieurs milliers d'euros par CPU ou par serveurs... Fallait y penser avant

Visiblement vous êtes tout à fait à côté de la plaque en matière de gestion de parc informatique :
1) le MTBF diminue à mesure que vous augmentez le nombre des machines
2) les couts de licence sont beaucoup plus important sur n machine que sur 1 même gigantesque
3) le cout d'admin est directement proportionnel au nombre de machines

Donc déjà avec ces 3 éléments vous êtes économiquement beaucoup plus cher.
Le modèle scale out, valable pour les sevreur web n'est absolument pas reproductible pour les SGBDR, même en mode share nothing !

A +

kedare · 08/12/2010, 21h42

Bizarrement c'est ce que quasiment tous les gros sites utilisent pour leurs base de données... Le seule gros site que je connaisse qui fasse du scale-up pour sa base de données, c'est LinkedIn qui tourne sur un gros mainframe Sun sous Solaris avec Oracle...
Facebook : MySQL en scale-out
Twitter : MySQL en scale-out (+ cassandra)
Youtube : MySQL en scale-out (mais je sais pas si c'est toujours le cas)
Yahoo : MySQL en scale-out
Flickr: MySQL en scale-out
Skype: PostgreSQL en scale-out (les courageux...)

Pour le coup des licences, c'est ce que j'ai dis dans mon précédent thread, c'est justement un gros avantage pour les bases de données open-source gratuites par rapport aux solutions proprio style SQL Server ou Oracle. Et sans le prix de ces licences, il est clairement plus rentable (et fiable) de faire du scale-out.

Donc oui, le scale-out est la solution pour les base de données de sites web.

SQLpro · 08/12/2010, 22h48

Encore une fois les mêmes exemples parfaitement stupides !!!!!
En effet facebook twiter et autres site ludiques ne font pas de transactions.... Il n'y a aucune concurrence d'accès vu qu'un seul et même utilisateur peut mettre à jour ses pages...
Dans ces exemples les bases sont utilisées comme de simples fichiers COBOL, pas pour du transactionnel. Et en cas de pertes de données (très nombreuses) tout le monde s'en fout !
Parlez mois de sites réellement transactionnels.
Moi en tant qu'experts SQL je suis allé au coeur de fnac.com qui est le plus gros site web marchand en langue française avec tgv.com.
Je me suis aussi occupé de sites marchand pour la grande distribution...
Et là c'est pas la même chose et bien évidemment pas du MySQL ce SGBD kleenex à peine relationnel et incapable de satisfaire plus de 5 users en parallèle sans que les performances ne plonge de façon catastrophiques...

Bref, soyez un peu sérieux dans vos exemples !!!

Lisez ceci : http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/

A +

kedare · 09/12/2010, 00h46

Ca reste quand même les plus gros sites au monde, fnac.com et tgv.com, ce n'est même pas comparable...
Et si non j'aimerais bien savoir d'ou vous tenez que MySQL ne tient pas plus de 5 connexions simultanées, j'ai de très gros doutes... (Sauf si MyISAM est utilisé... Mais aucun site serieux n'utilise ce truc), si c'était tellement naze, personne ne l'utiliserais... Et le fait qu'il diffère des autres RDBMS est une bonne chose, a quoi bon avoir X RDBMS si c'est pour qu'il soit tous des clones l'un de l'autre avec exactement les mêmes fonctionnalités....

MySQL à des défauts, c'est clair, mais PostgreSQL en a aussi (ainsi que les RDBMS proprios)

gregory.broissard · 09/12/2010, 07h43

Je ne suis pas toujours en accord avec SQLPro mais je partage profondément son agacement sur ce forum sur les mêmes réponses qui reviennent sans arrêt...

Les sites Web machin truc (facenaze, twit'jsais pas quoi...)

mais les sites web de ce type là ne sont qu'une infime partie des applications utilisant les SGBD. Deja les sites marchands donnent une idée de ce qu'est une vraie application.

Ca fait plus de 10 ans que je bosse dans différents technos possibles et imaginables (SQL, Oracle, DB2 z/OS & uDB, MySQL, Tamino, Essbase, etc...) et j'ai bossé 2 ans sur les sites internet d'un grand groupe automobile francais à 2 marques notamment sur des certains xxxWebStore.com
Les besoins sur les sites Web sont très différents des autres applications comme le dit SQLPro, et je ne paraphraserai donc pas son propos !

Actuellement travaillant sur des SI logistique sous le plus leader du marché ERP, on ne pourrait pas une seconde envisager un autre SGBD que les leaders du marché et ceux pour plusieurs raisons:
1/ L'ERP ne les supporte pas forcément
2/ Les supports des produits soit disant open source encore très en retard par rapport aux grands éditeurs. Nous avons vécu une crise de plusieurs jours il y a quielques années. Le support Oracle USA/Europe et Inde se relayait 24h sur 24....
3/ Le besoin transactionnel (>8000 utilisateurs simultanés réalisant des vraies grosses transactions et pas des consultations de page Facebook !) et la taille des bases de données (> plusieurs To) imposent des gestions fines des espaces de stockage et une capacitié d'absorption des transactions et une gestion de l'intégrité très élevée. Comme sur la fnac, amazon on ne peut pas perdre une commande........

Enfin, pour revenir à une remarque toujours également hérissante sur les couts des logiciels.
Je trouve que le cout des logiciels SGBD est au regard de la qualité des produits et du service associé. Oui, Oracle, SQLserver et DB2 Sont chers mais ils ont des fonctionnalités étendus, des supports en béton armé et des équipes de dév prêts à débugger tous les problemes rencontrés.
Qui plus est, sur des projets à enjeu ou à forte valeur ajoutée, je suis certain que le prix du SGBD choisi est mineur par rapport au retour sur investissement ou au cout global du projet.
Bien souvent, ce critère n'est pas structurant.
Enfin, à noter que ce critère pourrait avoir tendance à faire faire des choix stupides.
Dans une démarche projet classique, c'est le besoin fonctionnel qui tire l'architecture technique et pas le cout de l'architecture technique qui fera qu'on ajustera les besoins fonctionnels!

En plus, pour revenir sur les infrastructures avec plein de petits serveurs, je rappelle quand meme que avoir 10 serveurs ca coute pas le meme prix en frais de gestion dans un datacenter qu'un seul gros serveur (en terme d'électricité, de climatisation, d'espace , etc...). J'ajoute cela à ce qui a été dit par SQLPro sur les équipes d'admin associées dont le nombre est relatif au nombre de machines. 1 grosse base est plus simple à gérer que plein de petites bases. Cet état de fait est valable egalement pour toutes les équipes d'infrastructure (système, réseaux, etc...)
Donc il faut choisir ce type d'infrastructures dans des besoins très spécifiques commes les sites Web qui ont besoin de scalabilité horizontale. Sites Webs qui je le répète sont une infime partie du parc applicatif informatique..... Dans le cadre d'applications plus classiques avec un nombre d'utilisateurs identifiés, une machine de BD standalone ou un cluster est largement préférable.

Pour répondre à la question de départ, j'ajouterai que dans une entreprise il faut souvent définir une ligne directrice en matière de choix logiciels.
En effet, si vous laissez libre choix, alors c'est le meilleur moyen pour avoir une hétérogénéité de systèmes ingérable.
Il faut donc essayer de choisir une filiere stratégique qui répondra aux besoins classiques.
L'idée du questionnaire reste structurante pour tous les projets afin de valider soit qu'ils vont rentrer dans la filiere stratégique, soit qu'ils sont à part.

- Quel volume de données et sur combien de "lignes"?
SQLPro avait laisser un post sur la taille des bases.
VLDB > xTo
LDB plusieurs centaines de Go
Moyennes et petites bases en dessous.

- L'évolution de la volumétrie est connue en avance de phase? Faut-il privilégier la scalabilité?
Scalabilité horizontale / Verticale ?

- Quel type d'application va attaquer la base de données? (Web, transactionnel (OLTP), OLAP, Datamining, …)?
Poser la question également de l'utilisation de progiciels qui peuvent parfois supprimer des choix de DB.

J'ajouterai éventuellement
- Besoins transactionnels et intégrité
==> Si besoin de transactions avec gestion sans perte de données. Le choix s'oriente également naturellement.

- Criticité de l'application pour le business de l'entreprise
==> Orientation vers les meilleurs supports

Il y a d'autres critères structurants, j'essaierai dans la matinée d'en remettre un ou deux mais je voulais pousser mon coup de gueule . en plus avec la neige et les bouchons hier ca me rend pas de bonne humeur

..

kedare · 09/12/2010, 11h19

Pour le support open source, t'a toujours des grosses entreprises derrieres,
MySQL maintenant c'est Oracle qui fournit le support
PostgreSQL tu a par exemple EnterpriseDB (un des plus gros contributeur au projet PostgreSQL il me semble) qui fournit du support

Bref ça n'a rien à envier aux bases de données proprio au niveau support.
Et non ne comparez pas vos "gros" site français a la fnac.com avec leurs 100 requêtes par secondes contre les géants américains qui font dans les 11,000 requêtes par secondes (pour Twitter du moins) ou même 13.000.000 requêtes par secondes pour Facebook, faut croire qu'on vous n'avez pas compris la définition du scaling...
D'ailleurs ces géants américains n'auraient jamais pu évoluer a cette vitesse si ils avaient du passer par des logiciels propriétaires....

Oishiiii · 09/12/2010, 12h51

On ne peut pas généraliser le cas de ces monstres du web qui font exceptions à la règle.

Il faut voir aussi l'utilisation qu'il font du SGBD. Pour Facebook par exemple, MySQL sert uniquement de vulgaire espace de stockage pour un système "clé/valeur". Il y a une énorme couche de Memcached par dessus, c'est elle qui est attaquée par l'application. Rien de très glorieux.

Que Facebook utilise MySQL c'est leur choix. Ça ne me fera pas choisir MySQL pour une BDD "critique" dans le monde de la banque, de l'assurance, de l'e-commerce, etc.

gregory.broissard · 09/12/2010, 14h14

je parle application on me parle site Web
Je parle transaction on me parle de requete SELECT.

bref j'abandonne

Continuez à faire des sites Web en regardant facebook comme modele. Moi je retrourne m'occuper de vraies applications avec de la valeur ajoutée et du business.

Waldar · 09/12/2010, 14h28

Le sujet initial est très vaste et couvre ces deux domaines, donc d'un point de vue logique aucun problème à ce que la conversation couvre sites web et applications.

Citation:

- Quel type d'application va attaquer la base de données? (Web, transactionnel (OLTP), OLAP, Datamining, …)?
Commentaire: Si c'est du Web, privilégier MySQL. Si c'est du transactionnel, privilégier Oracle et SQL Server (voire même PostgreSQL). Si c'est du Datamining, privilégier Oracle et SQL Server.

vmolines · 09/12/2010, 14h50

Citation:

Envoyé par kedare

Pour le support open source, t'a toujours des grosses entreprises derrieres,
MySQL maintenant c'est Oracle qui fournit le support
PostgreSQL tu a par exemple EnterpriseDB (un des plus gros contributeur au projet PostgreSQL il me semble) qui fournit du support

Bref ça n'a rien à envier aux bases de données proprio au niveau support.
Et non ne comparez pas vos "gros" site français a la fnac.com avec leurs 100 requêtes par secondes contre les géants américains qui font dans les 11,000 requêtes par secondes (pour Twitter du moins) ou même 13.000.000 requêtes par secondes pour Facebook, faut croire qu'on vous n'avez pas compris la définition du scaling...
D'ailleurs ces géants américains n'auraient jamais pu évoluer a cette vitesse si ils avaient du passer par des logiciels propriétaires....

Vous oubliez toujours ce qu'SQLPro a souligné, à savoir que l'utilisation du SGBD est totalement différente sur une application type facebook ou twitter. Ces applications n'ont aucune concurrence d'accès en écriture et aucune problématique de verouillage à gérer. Pour être plus clair, tu peux faire tourner facebook ou twitter en READ UNCOMMITTED. Tu peux pas faire ça sur une plateforme de réservation.

Parler de nombre de requêtes astronomique quand les requêtes n'ont rien à voir entre elles ne prouve strictement rien.

aieeeuuuuu · 09/12/2010, 15h32

Citation:

Envoyé par kedare

Et non ne comparez pas vos "gros" site français a la fnac.com avec leurs 100 requêtes par secondes contre les géants américains qui font dans les 11,000 requêtes par secondes (pour Twitter du moins) ou même 13.000.000 requêtes par secondes pour Facebook, faut croire qu'on vous n'avez pas compris la définition du scaling...

oui c'est vrai ca...

D'ailleurs mon vendeur de kebab me sert mes frites dans des barquettes en plastique, et debite une bonne centaine de kebab par heure...

alors que Paul Bocuse s'obstinne avec ces services en porcelaine et ne fait que quelques dizaines de couverts par jour, ce petit joueur !

conclusion :
Paul bocuse devrait utiliser des assiettes en plastiques, et se ferait les c#!$lles en or !

-------
chacun ses besoins, chacun ses objectifs, chacun ses outils pour y arriver...

kedare · 09/12/2010, 16h33

Citation:

Envoyé par Oishiiii

On ne peut pas généraliser le cas de ces montres du web qui font exceptions à la règle.

Il faut voir aussi l'utilisation qu'il font du SGBD. Pour Facebook par exemple, MySQL sert uniquement de vulgaire espace de stockage pour un système "clé/valeur". Il y a une énorme couche de Memcached par dessus, c'est elle qui est attaquée par l'application. Rien de très glorieux.

Que Facebook utilise MySQL c'est leur choix. Ça ne me fera pas choisir MySQL pour une BDD "critique" dans le monde de la banque, de l'assurance, de l'e-commerce, etc.

Non, mais voila j'en ai marre des gens qui critiques toujours MySQL sans vraiment argumenter comme quoi MySQL peut par exemple pas gérer plus de 5 connexions simultanées, ces sites sont la preuve que c'est faux (et même developpez.net, ou n'importe quel site moyen), si son MySQL est pas capable de gérer ça, c'est qu'il sait pas l'administrer correctement

.
Au final désolé mais (plus de) la moitié des posts de SQLPro que je vois ça se résume a "blablabla Mysql c'est de la m......., blablabla vive SQL Server, blablabla le libre c'est mal, blablabla Linux c'est obsolète, blabla"

Pour memcached tous les sites un minimum bien codé l'utilisent (Ou équivalent style Terracotta si c'est une java-shop, etc)

chaplin · 09/12/2010, 16h49

, on pourrait en dire autant avec Firebird. Le marché de la BDD ne se limite pas aux 3 principaux SGBDR du marché.

07/12/2010, 08h18	#1
fgalves Invité régulier Inscription : novembre 2006 Messages : 63 Détails du profil Informations forums : Inscription : novembre 2006 Messages : 63 Points : 9 Points : 9	questions à se poser pour choisir le SGBD le plus approprié Bonjour, Je suis en train de préparer un document pour aider aux utilisateurs de choisir le SGBD le plus approprié selon leurs besoins. Le choix porte sur les SGBD suivants: Oracle, SQL Server, PostgreSQL et MySQL. Pour cela, je suis en train de réfléchir aux principales questions à se poser; elles devraient permettre de les diriger vers une solution adaptée à leur problématique. Voici les questions: - Quel volume de données et sur combien de "lignes"? Commentaire: Pour des grands volumes, privilégier Oracle et SQL Server. Pour des petits volumes, privilégier PostgreSQL et MySQL. - L'évolution de la volumétrie est connue en avance de phase? Faut-il privilégier la scalabilité? Commentaire: idem question précédente - Quel types de données doit-on stocker? (données, documents, images, …) Commentaire: ? - Quel type d'application va attaquer la base de données? (Web, transactionnel (OLTP), OLAP, Datamining, …)? Commentaire: Si c'est du Web, privilégier MySQL. Si c'est du transactionnel, privilégier Oracle et SQL Server (voire même PostgreSQL). Si c'est du Datamining, privilégier Oracle et SQL Server. - Combien d'utilisateurs pourront accéder concurremment à la base? Commentaire: puis-je privilégier un SGBD en particulier? - Les pré-requis de stockage sont-ils connus en avance de phase? Commentaire: puis-je privilégier un SGBD en particulier? Auriez-vous des remarques à faire ou d'autres questions à rajouter dans la liste? Merci par avance, Cdlt, Fgalves
	00

07/12/2010, 13h28	#4
kedare Membre extrêmement actif Mathieu Administrateur systèmes et réseaux Inscription : juillet 2005 Messages : 1 476 Détails du profil Informations personnelles : Nom : Mathieu Localisation : France Informations professionnelles : Activité : Administrateur systèmes et réseaux Informations forums : Inscription : juillet 2005 Messages : 1 476 Points : 1 260 Points : 1 260	Une autre question que tu devrais te poser: prévois tu de faire du scale-out ? (scaling horizontale), c'est très important car si tu commence à avoir énormément d'utilisateurs simultanés, tu sera obligé de passer par la, et sur ce point la, tous les systèmes ne sont pas égaux (genre PostgreSQL s'en sort plutôt mal..)
	02

07/12/2010, 22h05	#6
kedare Membre extrêmement actif Mathieu Administrateur systèmes et réseaux Inscription : juillet 2005 Messages : 1 476 Détails du profil Informations personnelles : Nom : Mathieu Localisation : France Informations professionnelles : Activité : Administrateur systèmes et réseaux Informations forums : Inscription : juillet 2005 Messages : 1 476 Points : 1 260 Points : 1 260	Sauf pour pour le scale-in, une machine 2x plus puissante coute (beaucoup) plus de 2x plus chère, il est CLAIREMENT plus rentable de passer par du scale-out, entre prendre un mainframe a plusieurs centaines de milliers d'euros, et pouvoir faire un cluster de 150 a 200 serveurs pour le même prix, on obtiendra de bien meilleurs performances avec le cluster... C'est pas pour rien que tous les gros sites fonctionnent comme ça... (+ sharding pour certains) Après forcement si on passe par des RDMBS proprio avec des licences de plusieurs milliers d'euros par CPU ou par serveurs... Fallait y penser avant
	03

08/12/2010, 21h42	#9
kedare Membre extrêmement actif Mathieu Administrateur systèmes et réseaux Inscription : juillet 2005 Messages : 1 476 Détails du profil Informations personnelles : Nom : Mathieu Localisation : France Informations professionnelles : Activité : Administrateur systèmes et réseaux Informations forums : Inscription : juillet 2005 Messages : 1 476 Points : 1 260 Points : 1 260	Bizarrement c'est ce que quasiment tous les gros sites utilisent pour leurs base de données... Le seule gros site que je connaisse qui fasse du scale-up pour sa base de données, c'est LinkedIn qui tourne sur un gros mainframe Sun sous Solaris avec Oracle... Facebook : MySQL en scale-out Twitter : MySQL en scale-out (+ cassandra) Youtube : MySQL en scale-out (mais je sais pas si c'est toujours le cas) Yahoo : MySQL en scale-out Flickr: MySQL en scale-out Skype: PostgreSQL en scale-out (les courageux...) Pour le coup des licences, c'est ce que j'ai dis dans mon précédent thread, c'est justement un gros avantage pour les bases de données open-source gratuites par rapport aux solutions proprio style SQL Server ou Oracle. Et sans le prix de ces licences, il est clairement plus rentable (et fiable) de faire du scale-out. Donc oui, le scale-out est la solution pour les base de données de sites web.
	03

08/12/2010, 22h48	#10
SQLpro Rédacteur/Modérateur Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 10 948 Détails du profil Informations personnelles : Nom : Frédéric BROUARD Localisation : France Informations professionnelles : Activité : Expert SGBDR & SQL Secteur : Conseil Informations forums : Inscription : mai 2002 Messages : 10 948 Points : 17 762 Points : 17 762	Encore une fois les mêmes exemples parfaitement stupides !!!!! En effet facebook twiter et autres site ludiques ne font pas de transactions.... Il n'y a aucune concurrence d'accès vu qu'un seul et même utilisateur peut mettre à jour ses pages... Dans ces exemples les bases sont utilisées comme de simples fichiers COBOL, pas pour du transactionnel. Et en cas de pertes de données (très nombreuses) tout le monde s'en fout ! Parlez mois de sites réellement transactionnels. Moi en tant qu'experts SQL je suis allé au coeur de fnac.com qui est le plus gros site web marchand en langue française avec tgv.com. Je me suis aussi occupé de sites marchand pour la grande distribution... Et là c'est pas la même chose et bien évidemment pas du MySQL ce SGBD kleenex à peine relationnel et incapable de satisfaire plus de 5 users en parallèle sans que les performances ne plonge de façon catastrophiques... Bref, soyez un peu sérieux dans vos exemples !!! Lisez ceci : http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/ A + __________________ Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ *Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.* Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
	21

09/12/2010, 00h46	#11
kedare Membre extrêmement actif Mathieu Administrateur systèmes et réseaux Inscription : juillet 2005 Messages : 1 476 Détails du profil Informations personnelles : Nom : Mathieu Localisation : France Informations professionnelles : Activité : Administrateur systèmes et réseaux Informations forums : Inscription : juillet 2005 Messages : 1 476 Points : 1 260 Points : 1 260	Ca reste quand même les plus gros sites au monde, fnac.com et tgv.com, ce n'est même pas comparable... Et si non j'aimerais bien savoir d'ou vous tenez que MySQL ne tient pas plus de 5 connexions simultanées, j'ai de très gros doutes... (Sauf si MyISAM est utilisé... Mais aucun site serieux n'utilise ce truc), si c'était tellement naze, personne ne l'utiliserais... Et le fait qu'il diffère des autres RDBMS est une bonne chose, a quoi bon avoir X RDBMS si c'est pour qu'il soit tous des clones l'un de l'autre avec exactement les mêmes fonctionnalités.... MySQL à des défauts, c'est clair, mais PostgreSQL en a aussi (ainsi que les RDBMS proprios)
	03

09/12/2010, 07h43	#12
gregory.broissard Membre expérimenté Inscription : mai 2005 Messages : 414 Détails du profil Informations forums : Inscription : mai 2005 Messages : 414 Points : 589 Points : 589	Je ne suis pas toujours en accord avec SQLPro mais je partage profondément son agacement sur ce forum sur les mêmes réponses qui reviennent sans arrêt... Les sites Web machin truc (facenaze, twit'jsais pas quoi...) mais les sites web de ce type là ne sont qu'une infime partie des applications utilisant les SGBD. Deja les sites marchands donnent une idée de ce qu'est une vraie application. Ca fait plus de 10 ans que je bosse dans différents technos possibles et imaginables (SQL, Oracle, DB2 z/OS & uDB, MySQL, Tamino, Essbase, etc...) et j'ai bossé 2 ans sur les sites internet d'un grand groupe automobile francais à 2 marques notamment sur des certains xxxWebStore.com Les besoins sur les sites Web sont très différents des autres applications comme le dit SQLPro, et je ne paraphraserai donc pas son propos ! Actuellement travaillant sur des SI logistique sous le plus leader du marché ERP, on ne pourrait pas une seconde envisager un autre SGBD que les leaders du marché et ceux pour plusieurs raisons: 1/ L'ERP ne les supporte pas forcément 2/ Les supports des produits soit disant open source encore très en retard par rapport aux grands éditeurs. Nous avons vécu une crise de plusieurs jours il y a quielques années. Le support Oracle USA/Europe et Inde se relayait 24h sur 24.... 3/ Le besoin transactionnel (>8000 utilisateurs simultanés réalisant des vraies grosses transactions et pas des consultations de page Facebook !) et la taille des bases de données (> plusieurs To) imposent des gestions fines des espaces de stockage et une capacitié d'absorption des transactions et une gestion de l'intégrité très élevée. Comme sur la fnac, amazon on ne peut pas perdre une commande........ Enfin, pour revenir à une remarque toujours également hérissante sur les couts des logiciels. Je trouve que le cout des logiciels SGBD est au regard de la qualité des produits et du service associé. Oui, Oracle, SQLserver et DB2 Sont chers mais ils ont des fonctionnalités étendus, des supports en béton armé et des équipes de dév prêts à débugger tous les problemes rencontrés. Qui plus est, sur des projets à enjeu ou à forte valeur ajoutée, je suis certain que le prix du SGBD choisi est mineur par rapport au retour sur investissement ou au cout global du projet. Bien souvent, ce critère n'est pas structurant. Enfin, à noter que ce critère pourrait avoir tendance à faire faire des choix stupides. Dans une démarche projet classique, c'est le besoin fonctionnel qui tire l'architecture technique et pas le cout de l'architecture technique qui fera qu'on ajustera les besoins fonctionnels! En plus, pour revenir sur les infrastructures avec plein de petits serveurs, je rappelle quand meme que avoir 10 serveurs ca coute pas le meme prix en frais de gestion dans un datacenter qu'un seul gros serveur (en terme d'électricité, de climatisation, d'espace , etc...). J'ajoute cela à ce qui a été dit par SQLPro sur les équipes d'admin associées dont le nombre est relatif au nombre de machines. 1 grosse base est plus simple à gérer que plein de petites bases. Cet état de fait est valable egalement pour toutes les équipes d'infrastructure (système, réseaux, etc...) Donc il faut choisir ce type d'infrastructures dans des besoins très spécifiques commes les sites Web qui ont besoin de scalabilité horizontale. Sites Webs qui je le répète sont une infime partie du parc applicatif informatique..... Dans le cadre d'applications plus classiques avec un nombre d'utilisateurs identifiés, une machine de BD standalone ou un cluster est largement préférable. Pour répondre à la question de départ, j'ajouterai que dans une entreprise il faut souvent définir une ligne directrice en matière de choix logiciels. En effet, si vous laissez libre choix, alors c'est le meilleur moyen pour avoir une hétérogénéité de systèmes ingérable. Il faut donc essayer de choisir une filiere stratégique qui répondra aux besoins classiques. L'idée du questionnaire reste structurante pour tous les projets afin de valider soit qu'ils vont rentrer dans la filiere stratégique, soit qu'ils sont à part. - Quel volume de données et sur combien de "lignes"? SQLPro avait laisser un post sur la taille des bases. VLDB > xTo LDB plusieurs centaines de Go Moyennes et petites bases en dessous. - L'évolution de la volumétrie est connue en avance de phase? Faut-il privilégier la scalabilité? Scalabilité horizontale / Verticale ? - Quel type d'application va attaquer la base de données? (Web, transactionnel (OLTP), OLAP, Datamining, …)? Poser la question également de l'utilisation de progiciels qui peuvent parfois supprimer des choix de DB. J'ajouterai éventuellement - Besoins transactionnels et intégrité ==> Si besoin de transactions avec gestion sans perte de données. Le choix s'oriente également naturellement. - Criticité de l'application pour le business de l'entreprise ==> Orientation vers les meilleurs supports Il y a d'autres critères structurants, j'essaierai dans la matinée d'en remettre un ou deux mais je voulais pousser mon coup de gueule . en plus avec la neige et les bouchons hier ca me rend pas de bonne humeur ..
	61

09/12/2010, 11h19	#13
kedare Membre extrêmement actif Mathieu Administrateur systèmes et réseaux Inscription : juillet 2005 Messages : 1 476 Détails du profil Informations personnelles : Nom : Mathieu Localisation : France Informations professionnelles : Activité : Administrateur systèmes et réseaux Informations forums : Inscription : juillet 2005 Messages : 1 476 Points : 1 260 Points : 1 260	Pour le support open source, t'a toujours des grosses entreprises derrieres, MySQL maintenant c'est Oracle qui fournit le support PostgreSQL tu a par exemple EnterpriseDB (un des plus gros contributeur au projet PostgreSQL il me semble) qui fournit du support Bref ça n'a rien à envier aux bases de données proprio au niveau support. Et non ne comparez pas vos "gros" site français a la fnac.com avec leurs 100 requêtes par secondes contre les géants américains qui font dans les 11,000 requêtes par secondes (pour Twitter du moins) ou même 13.000.000 requêtes par secondes pour Facebook, faut croire qu'on vous n'avez pas compris la définition du scaling... D'ailleurs ces géants américains n'auraient jamais pu évoluer a cette vitesse si ils avaient du passer par des logiciels propriétaires....
	04

09/12/2010, 12h51	#14
Oishiiii Membre chevronné Administrateur de base de données Inscription : août 2009 Messages : 404 Détails du profil Informations personnelles : Âge : 24 Informations professionnelles : Activité : Administrateur de base de données Informations forums : Inscription : août 2009 Messages : 404 Points : 643 Points : 643	On ne peut pas généraliser le cas de ces monstres du web qui font exceptions à la règle. Il faut voir aussi l'utilisation qu'il font du SGBD. Pour Facebook par exemple, MySQL sert uniquement de vulgaire espace de stockage pour un système "clé/valeur". Il y a une énorme couche de Memcached par dessus, c'est elle qui est attaquée par l'application. Rien de très glorieux. Que Facebook utilise MySQL c'est leur choix. Ça ne me fera pas choisir MySQL pour une BDD "critique" dans le monde de la banque, de l'assurance, de l'e-commerce, etc.
	10

09/12/2010, 14h14	#15
gregory.broissard Membre expérimenté Inscription : mai 2005 Messages : 414 Détails du profil Informations forums : Inscription : mai 2005 Messages : 414 Points : 589 Points : 589	je parle application on me parle site Web Je parle transaction on me parle de requete SELECT. bref j'abandonne Continuez à faire des sites Web en regardant facebook comme modele. Moi je retrourne m'occuper de vraies applications avec de la valeur ajoutée et du business.
	00

09/12/2010, 16h49	#20
chaplin Membre Expert Inscription : août 2006 Messages : 1 068 Détails du profil Informations forums : Inscription : août 2006 Messages : 1 068 Points : 1 213 Points : 1 213	, on pourrait en dire autant avec Firebird. Le marché de la BDD ne se limite pas aux 3 principaux SGBDR du marché.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email