Discussion :

[christophe78]

Bonjour,
Voila j'ai 2 ou 3 problèmes liés à des choix techniques que je ne connais pas forcément.
Je suis en charge de la création d’un site Internet avec beaucoup d'utilisateurs connectés simultanément (environ 10000 en période normale et jusqu'à 20000 en périodes de pointe), sur des sessions d’une durée moyenne de 20 minutes. Ces utilisateurs se connecteront à une base de données ce qui impliquera un fort taux de transferts.
Les activités des utilisateurs sur le site feront qu’il y aura énormément de requêtes SQL basées en premier lien sur les "select" ainsi que les "insert" et dans une moindre mesure sur les "update" et "delete".

De plus on devrait avoir plusieurs serveurs web sous Linux (Debian) avec la techno Apache / PHP, ainsi qu’un frontal pour faire du Load Balancing sur ces serveurs web. Le ou les serveurs SQL seront sur des machines dédiées.

Viennent ensuite les interrogations:

On parle du triplet Apache/php/mysql, mais dans mon cas est ce que MySQL peut tenir le coût niveau performance et rapidité, cela j’en doute vu mes premiers tests ? Ou alors voir du coté de PostgresQL ou y a t il d'autres SGBD intéressant par rapport aux critères cités ci-dessus? (plutôt OpenSource ou pas trop cher, en évitant Oracle à 12000€)
Est-ce que MySQL ou POstgresQL peuvent gérer des tables de plusieurs millions voire centaines de millions de lignes ?
Y a-t-il des options dans MySQL, PostgresQL ou une meilleure base de données, qui permettraient un meilleur temps dans le traitement des Query ?

On pense utiliser une seule base de données, va-t-il y avoir un problème de surcharge et donc obliger d’avoir plusieurs serveurs SQL? en sachant qu’on va purger la base de données au minimum une fois par jour.
Si il y a plusieurs serveurs SQL, la solution du Clustering est elle viable ?
Est-ce performant ? Ou bien ralentit elle le temps de réponses des serveurs de base de données ? Y a-t-il des solutions de « clustering » performantes à faible coût à votre connaissance ?
Et par rapport au choix de la base de données, celle-ci tient elle bien le clustering ?

Quel pourraient être les optimisations possibles pour accélérer les performances au niveau temps de réponses entre les serveurs BD et le client ? J'ai pensé au RAID 5 ou RAID 1+0 comme solution technique pour les disques durs contenant les bases de données, est ce un bon choix de RAID par rapport à votre expérience? Mais y a t il d'autres points que je n'est pas vu ?

Merci de vos réponses et désolé si il y a des infos que j'ai pas vu sur le forum.

[soony]

Slt,

MySQL offre la possiblité de faire du clustering, renseigne toi.
Pour le RAID, regarde aussi le niveau 5+0 qui est intéressante (perf en lect et ecriture, survie si deux disques tombent en panne) mais exige cinq disques durs.

[christophe78]

Salut,
j'ai effectué quelques tests entre MySQL et PostgresQL sur une table de 100000 lignes qui représentent une mini_version de ce que contiendra la base de données. Il en resulte pour différentes requêtes que PostgresQL est plus rapide au niveau du temps d'exécution, moins en temps de connexion, mais au total, PostgresQL est plus rapide.
MySQL semble être à la ramasse pour les grosses bas de données, donc a voir pour le clustering sur PostresQL ou bien si il y a d'autres SGBD avec clustering en opensource ou pas cher ...

Au niveau des RAID, mon patron voudrait plus la sécurité avec du 1 plutot que des perfs (avec le 0 par exemple) à cause du coût de la multiplication des disques.

enfin si vous avez d'autres idées...

[kankrelune]

environ 10000 en période normale et jusqu'à 20000 en périodes de pointe

Mois, semaine, jour, heure, minute... .. ?

Perso j'ais travaillé sur des gros site sous mysql et ils s'en tiraient plus qu'honorablement... il faut voir quelle requete tu fais à ton serveur et surtout comment tu les formule car une bonne partie de l'optimisation du dialogue php/mysql se fait avant tout au niveau des requetes... PostgreSQL est une bonne SGDB mais je ne pourrais t'en dire plus car je n'ais jamais comparé les performances des deux... .. .

@ tchaOo°