Discussion :

[_Gabriel_]

bonjour le forum,
ayant lu attentivement tout ce que j'au pu trouvé comme doc sur le sujet (y compris ce forum), je me lance quand meme.

situation:
responsable du redeveloppement (jeune il est vrai) d'un portail national, je viens d'etre confronté à un probleme de taille: le choix d'une base de donnée.

en effet, aprés quelques calculs, mon equipe en vient à la conclusion que certaines tables approcheront les 200 millions d'entrées (234 180 000 exactement). et ceci dans le meilleur des cas.

Actuellement, le travail fait par l'ancien chef de projet etait basé sur mysql mais ne correspondait pas au cahier des charges.

Pour tout dire, cela concerne un module d'affichage de bannieres publicitaires et en faisant le compromis entre la taille des tables et l'optimisation des accés à l'information ( pour l'affichage et la reservation des espaces d'affichage), on arrive à la création de 12 tables de 200 millions d'entrée.

bon d'un autre cote ca fait enorme en nombre d'enregistrement mais un enregistrement s'etend sur deux colonnes de type int( 8 ) (pour mysql).

On pourrait en oubliant le manque à gagner du client, diviser le tout par 10 ramenant l'affaire à 24 millions par tables mais ...

Je n'ai pas forcement besoin de preciser que etant d'envergure national, la fréquentation risque d'etre soutenu à certains moment de la journée ceci dit par requete ca ne ferait qu'un resultat de trois lignes !!!

cote plateforme, je vais entrer en contact avec un hebergeur (serveur dedié) et j'opterais pour freebsd. le tout sur un serveur apache avec php.
alors il y as t il une ame sensible qui pourrait me filer en coup de main?
precision, la version light que je viens de recuperer ne contient actuellement que 500000 enregistrement (20mo à la louche) mais comme le cahier des charges n'etait pas respecté ....

bref voila l'affaire qui reste relativement démesurée car en extrapolant, hormis ces tables, les plus grosses (deux) ne devraient contenir que 600000 entrées mais je prefere prendre les devant.

voila comprenne qui peut
merci encore
++

[Fabien Celaia]

Le comparatif de Geronimo ne te donne-t-il as assez d'info ?

Pour info, une table de 2 champs int devrait avoir une taille approximative de 2,7 Gb, sans compter les indexes (presque autant pour chaque index non-cluster !).

Penses eventuellement aussi aux possibilites de haute disponibilite...
Quelle est votre marge qu'en aux temps de pannes ? d'administration ?

[_Gabriel_]

J'ai lu le comparatif mais malgré qu'il soit complet, il manque encore des stats de performances. C'est surtout une experience face à ce type de probleme que je recherche.

pour l'heure nous avons partiellement contourné le probleme :
une base de donnée à 18000 table de 39000 entrée chacune (en gros). ce qui nous permet un d'optimiser les accés sur base car la majorite des accés se fait sur une des tables pour une requete ( donc dans l'ancien shema sur une portion bien defini de la table) de deux eviter de trainer le monstre.

Par contre il devient clair que l'acquisition d'un serveur dedié aux bases de données est obligatoire.
En ce qui concerne les contraintes de fonctionement, nous pensons, aprés étude, que les pics de fréquentations arriveront pendant les temps libres. 12 -14h, 19-22h. cependant, le nombres d'accés seras constant de 7h à 22 h.

Autant dire qu'une panne dans ces périodes prolongées ou répétitives est à exclure. Par contre, je considere que pour des besoins d'administration nous pouvons lancer des traitements la nuit.

Pour l'instant, on s'oriente vers un developpement en l'etat , avec mysql, en créant une couche d'abstraction entre l'appli et l'accés aux données, afin de pouvoir migrer vers un autre systeme sans avoir à réecrire completement l'application.

Cependant, ma question reste encore en suspend : à défaut d'avoir un table monstrueuse, quelle systeme pour une base avec 18000 (au moins) tables ?

merci
++

[_Gabriel_]

On va dire que notre client pourrait se permettre d'investir dans un systeme. Ensuite, et tout depends si l'appli voit le jour la question financiere pourrait etre solutionner plus facilement.
je dirais que actuellement, le besoin serait un systeme fiable peu onereux qui pourrait lancer l'application puis une migration vers un systeme puissant quite à y mettre le prix pour la faire tourner completement.

Cependant les possibilités du futur systeme devront etre adapté à notre besoin.

Comme je l'ai dit precedement on planche sur une abstraction complete entre l'appli et l'accés aux données.

[Fabien Celaia]

Pour l'abstraction "complete" => developpement en 3-tiers. Quel est le serveur applicatif choisi ? Quel est l'OS choisi ?

[_Gabriel_]

Dans le cas qui nous interresse, on est dans du 3 tier. Apache est le serveur d'application (avec php).
on assure l'abstraction par un composant d'accés au données contenant plusieurs classes spécialisés vers un type de serveur.(pour l'heure mysql, sqlServer), une classe d'interface entre ce composant et l'application.
L'os choisi est freebsd mais je vois l'hebergeur pour les serveurs dédiés la semaine prochaine. Aprés contact avec le client, on s'oriente pour une mise à l'eau vers deux serveur dédiés : un pour le service http l'autre pour la base de donnée. Cependant on reste réactif sur le fait que on pourrai etre amener à renforcer l'architecture et changer de sgbd

[SQLpro]

Ce n'est pas le nombre de ligne qui est important. Mais le volume de la table. Tu parle de 200 millions d'entrée dans des tables ou il y aura deux entiers cela fait donc un volume de données de 8 octets par ligne soit 200 000 000 x 8o = 1,6 Go.... franchement pas énorme comme volume par table.

Le problème réside dans l'organisation des données. Un SGBDR qui peut répartir une même table sur plusieurs fichiers permettra d'organiser les espaces en accordant une priorité plus grande aux données les plus sollicitées.

L'autre problème est l'accès concurrent à la base. Quel sera le nombre réel d'accès simultané. Attention je ne parle ni d'utilisateur, ni d'utilisateur en ligne, car dans ce cas il faut faire du client/server en mode déconnecté. Or on sait que 1 000 utilisateur navigant sur un site web en mode déconnecté simultanément ne provoque pas une charge de plus de 30 à 50 utilisateur simultané du serveur de bases de données. C'est pas énorme non plus pour des SGBDR capable de traiter quelques centaines d'utilisateur simultanémént.

Enfin, le point fondamental à mon avis dans ta demande, concerne la solution de continuité. Là la seule parade est de prévoir deux serveurs de bases de données en cluster actif/passif, afin que l'un preenne automatiquement le reelai de l'autre en cas de panne. Ceci suppose bien entendu un mécanisme de réplication.

Mon choix serait vite fait : SQL Server ou mieux et pire à la fois, Oracle.

A +

[Fabien Celaia]

Enfin, le point fondamental à mon avis dans ta demande, concerne la solution de continuité. Là la seule parade est de prévoir deux serveurs de bases de données en cluster actif/passif, afin que l'un preenne automatiquement le reelai de l'autre en cas de panne. Ceci suppose bien entendu un mécanisme de réplication.

Mon choix serait vite fait : SQL Server ou mieux et pire à la fois, Oracle.

A +

... donc, pour un environement sous Unix, la meme chose, en remplacant MS-SQL pour Sybase ASE (avec module HA ou/et replication)

[ovh]

Et PostgreSQL, à votre avis ? C'est en tout cas mieux que MySQL, d'après ce que j'avais lu dans un bouquin que j'ai à la maison, il serait adapté même pour les grosses quantités de données.
http://advocacy.postgresql.org/advantages/?lang=fr
Le bouquin en question était un de ceux conseillés par Frédéric Brouard (SQLPro), que je remercie au passage pour ses excellents articles !
"Le guide du développeur - PostgreSQL", chez CampusPress.

[mathll65]

A bon gout, postgres est beaucoup mieux que mysql. Il propose les avantages de transactions par exemple... De plus mysql sauf dans la toute derniere version ne gere pas l'intégrité et les clés etrangeres !!