Choix techniques liés à la création d'un site
Fermé
christophe78
Messages postés
3
Date d'inscription
jeudi 21 septembre 2006
Statut
Membre
Dernière intervention
26 septembre 2006
-
21 sept. 2006 à 14:42
phunk Messages postés 497 Date d'inscription lundi 31 juillet 2006 Statut Membre Dernière intervention 30 novembre 2006 - 26 sept. 2006 à 15:33
phunk Messages postés 497 Date d'inscription lundi 31 juillet 2006 Statut Membre Dernière intervention 30 novembre 2006 - 26 sept. 2006 à 15:33
A voir également:
- Choix techniques liés à la création d'un site
- Site de telechargement - Guide
- Liste déroulante de choix excel - Guide
- Site inaccessible - Guide
- Site de vente entre particulier - Guide
- Creation compte gmail - Guide
3 réponses
phunk
Messages postés
497
Date d'inscription
lundi 31 juillet 2006
Statut
Membre
Dernière intervention
30 novembre 2006
193
21 sept. 2006 à 16:36
21 sept. 2006 à 16:36
Salut totophe,
Dans un premier temps avant le choix d'une solution technique il est important de bien concevoir la base : jointures "intelligentes" et stratégie d'indexation. Je dis ça mais je pense que ça fait partie de ton métier :)
1) De façon générale, il faut faire un examen des tables/filtres/index et procéder à une estimation des coûts par paire jointe. Cela permet de trouver le meilleur moyen d'exécuter une requête donnée (chemin optimal = chemin le moins couteux). Il faut commencer par là pour accélérer les temps de réponses.
2) Pour le choix MySQL, je suis assez dubitatif; il faudrait tester la charge en dev avec un émulateur. Pour Postgres je ne pourrai pas te renseigner, je ne connais pas beaucoup.
Certes Oracle est très cher (12000 euros ? plus que ça si plusieurs serveurs :)), mais il n'existe pas mieux pour la tenue de charge. Informix bien aussi, mais cher aussi ^^
3) Si plusieurs serveurs BD, la solution du clustering est excellente. Après ça dépend de la structure même de ta base et des requetes que les users seront amenés à faire sur les tables. C'est une balance de charge pour les données, au même titre que le frontal pour le web. Donc il faut y réfléchir. Je n'ai pas de solution de clustering en tête, avec Oracle la question ne se pose pas. Google t'apportera surement des pistes.
4) Eventuellement mettre en place une fragmentation. C'est une bonne optimisation, mais qui est couteuse (comme le clustering). Pour une même table, les données sont réparties dans plusieurs dbspaces, à chacun est attribué un disque (tête de lecture). Je te raconte pas les perfs :)
Pour le RAID, ça dépend de la stratégie de sécurité/redondance des données..
Mais en principe toutes ces questions sont analysées et traitées par le chef de projet avec l'architecte syst/réseau et l'admin base de données, ton projet à l'air d'envergure en plus !
Dans un premier temps avant le choix d'une solution technique il est important de bien concevoir la base : jointures "intelligentes" et stratégie d'indexation. Je dis ça mais je pense que ça fait partie de ton métier :)
1) De façon générale, il faut faire un examen des tables/filtres/index et procéder à une estimation des coûts par paire jointe. Cela permet de trouver le meilleur moyen d'exécuter une requête donnée (chemin optimal = chemin le moins couteux). Il faut commencer par là pour accélérer les temps de réponses.
2) Pour le choix MySQL, je suis assez dubitatif; il faudrait tester la charge en dev avec un émulateur. Pour Postgres je ne pourrai pas te renseigner, je ne connais pas beaucoup.
Certes Oracle est très cher (12000 euros ? plus que ça si plusieurs serveurs :)), mais il n'existe pas mieux pour la tenue de charge. Informix bien aussi, mais cher aussi ^^
3) Si plusieurs serveurs BD, la solution du clustering est excellente. Après ça dépend de la structure même de ta base et des requetes que les users seront amenés à faire sur les tables. C'est une balance de charge pour les données, au même titre que le frontal pour le web. Donc il faut y réfléchir. Je n'ai pas de solution de clustering en tête, avec Oracle la question ne se pose pas. Google t'apportera surement des pistes.
4) Eventuellement mettre en place une fragmentation. C'est une bonne optimisation, mais qui est couteuse (comme le clustering). Pour une même table, les données sont réparties dans plusieurs dbspaces, à chacun est attribué un disque (tête de lecture). Je te raconte pas les perfs :)
Pour le RAID, ça dépend de la stratégie de sécurité/redondance des données..
Mais en principe toutes ces questions sont analysées et traitées par le chef de projet avec l'architecte syst/réseau et l'admin base de données, ton projet à l'air d'envergure en plus !
christophe78
Messages postés
3
Date d'inscription
jeudi 21 septembre 2006
Statut
Membre
Dernière intervention
26 septembre 2006
25 sept. 2006 à 14:27
25 sept. 2006 à 14:27
Salut,
D’abord merci de ta réponse, ensuite je vais peut être préciser 2 ou 3 points. D’abord, nous sommes une petite équipe et je suis en même temps administrateur base de données et architecte système/réseau, c’est pour cela que, entrant dans le monde du web, je pose quelques questions.
Pour la base de données, on essaie déjà d’optimiser celle-ci.
Après quelques tests entre MySQL et PostgresQL sur une base de 100000 lignes, on a pu constater que PostgresQL était plus performant au niveau temps d’exécution. Pour les SGBD coûteux comme Oracle ou Informix, les critères de coût sont toujours valables, c'est-à-dire de préférence peu coûteux ou OpenSource.
A propos du clustering, que veux tu dire par « ca dépend de la structure … » le clustering est il plus performant par rapport a un certain type de BD ?
Au niveau du RAID, mon chef serait plus tenté par rapport au coût des disques durs à chosir plus la sécurité des données plus que la performance, donc plus un RAID 1 ou ce qui se peut s’approcher le plus.
D’abord merci de ta réponse, ensuite je vais peut être préciser 2 ou 3 points. D’abord, nous sommes une petite équipe et je suis en même temps administrateur base de données et architecte système/réseau, c’est pour cela que, entrant dans le monde du web, je pose quelques questions.
Pour la base de données, on essaie déjà d’optimiser celle-ci.
Après quelques tests entre MySQL et PostgresQL sur une base de 100000 lignes, on a pu constater que PostgresQL était plus performant au niveau temps d’exécution. Pour les SGBD coûteux comme Oracle ou Informix, les critères de coût sont toujours valables, c'est-à-dire de préférence peu coûteux ou OpenSource.
A propos du clustering, que veux tu dire par « ca dépend de la structure … » le clustering est il plus performant par rapport a un certain type de BD ?
Au niveau du RAID, mon chef serait plus tenté par rapport au coût des disques durs à chosir plus la sécurité des données plus que la performance, donc plus un RAID 1 ou ce qui se peut s’approcher le plus.
phunk
Messages postés
497
Date d'inscription
lundi 31 juillet 2006
Statut
Membre
Dernière intervention
30 novembre 2006
193
25 sept. 2006 à 16:11
25 sept. 2006 à 16:11
Ok, donc effectivement le RAID 1 (mirroring) est adapté. Si tu as constaté de meilleurs perfs avec PostgresQL par rapport à tes besoins, je penses qu'il ne faut pas hésiter.
En fait pour le clustering ça ne dépend pas de la structure (pourquoi j'ai écrit ça ?), c'est vraiment la balance de charge. En fait il est plus efficace notamment s'il y a beaucoup de sous-requetes / union / conditions complexes : le frontal dispatche les différentes parties de la requete sur différents serveurs, récupère le résultat et le renvoie. Après faut voir sur quels tables vont taper principalement les utilisateurs, et quelles seront les requêtes qui seront faites.
De toutes façons dans tous les cas c'est une bonne optimisation, mais couteuse donc à analyser.
Bon courage :)
En fait pour le clustering ça ne dépend pas de la structure (pourquoi j'ai écrit ça ?), c'est vraiment la balance de charge. En fait il est plus efficace notamment s'il y a beaucoup de sous-requetes / union / conditions complexes : le frontal dispatche les différentes parties de la requete sur différents serveurs, récupère le résultat et le renvoie. Après faut voir sur quels tables vont taper principalement les utilisateurs, et quelles seront les requêtes qui seront faites.
De toutes façons dans tous les cas c'est une bonne optimisation, mais couteuse donc à analyser.
Bon courage :)
christophe78
Messages postés
3
Date d'inscription
jeudi 21 septembre 2006
Statut
Membre
Dernière intervention
26 septembre 2006
26 sept. 2006 à 12:42
26 sept. 2006 à 12:42
Disons que je ne m’arrête pas a PostgresQL. En cherchant un SGBD sous linux à un coût moindre, je suis arrivé sur les OpenSOurce, j’ai testé. Maintenant il en existe bien d’autres connus ou moins connus que je testerai aussi. Et si vous en connaissez je suis preneur.
Au niveau du clustering, au niveau de la base, elle sera orientée fonctionnelle. Il y aura donc 2 ou 3 redondances entre tables, mais cela permet de diminuer la complexité des requêtes, donc peu ou pas de sous requêtes, jointure ou autres.
De plus, les utilisateurs se connecteront plus sur 3 ou 4 tables qui seront très grosses (dans les 10 millions de lignes) et le type de requête sera alors plus des « insert,update, select ».
Donc le clustering pour dispatcher les parties de requêtes n’est pas intéressant dans mon cas, mais est il performant pour les requêtes simples ?
Le clustering peut il diminuer la file d’attente des requêtes utilisateurs en les dispatchant sur les différents serveurs de base de données ?
Au niveau du clustering, au niveau de la base, elle sera orientée fonctionnelle. Il y aura donc 2 ou 3 redondances entre tables, mais cela permet de diminuer la complexité des requêtes, donc peu ou pas de sous requêtes, jointure ou autres.
De plus, les utilisateurs se connecteront plus sur 3 ou 4 tables qui seront très grosses (dans les 10 millions de lignes) et le type de requête sera alors plus des « insert,update, select ».
Donc le clustering pour dispatcher les parties de requêtes n’est pas intéressant dans mon cas, mais est il performant pour les requêtes simples ?
Le clustering peut il diminuer la file d’attente des requêtes utilisateurs en les dispatchant sur les différents serveurs de base de données ?
phunk
Messages postés
497
Date d'inscription
lundi 31 juillet 2006
Statut
Membre
Dernière intervention
30 novembre 2006
193
26 sept. 2006 à 15:33
26 sept. 2006 à 15:33
Pour le clustering il faudrait vérifier mais il me semble que oui.
