mackwic Posté(e) le 22 juin 2009 Partager Posté(e) le 22 juin 2009 Bonjour à tous, Je me suis lancé avec un ami dans un projet de jeu en ligne. Nous connaissions déjà le PHP et le SQL mais nous n'avions encore jamais eu l'occasion de les pratiquer vraiment. Là l'occasion s'est présentée et nous l'avons saisie au vol. :) Pour situer plus exactemement, il se trouve que les admins d'un jeu que j'appréciait beaucoup ont laissé le navire à la dérive et au large. Or, comme vous le savez si vous avez déjà fait de le navigation, même avec une ancre flottante et des relevés quodiens, pas possible de rester comme ça longtemps! Et là ça va faire 1 an... Le dit jeu a possédé une communauté assez impressionante de 800 joueurs (à son apogée...), à la version gamma en plus! Il s'agissait d'un truc SF wargame - Role Play assez sympa. Mais je m'écarte du sujet. Je suis pas là pour faire de la pub... Après une (trop) longue préparation sur des (centaines de) milliers de feuilles de papier, où s'étalent sans discontinuer organigrammes et tableaux croisés, listes et descriptions, j'ai commencé à faire les maquettes. Et, au hasard de mes pérégrinations sur devellopez.com, je tombe sur l'excelllent article "SQL de A à Z" où ils expliquent la différence entre un SGBD (systè_me de gestion de base de données) fichier et C/S (client / serveur ). Et là... je vois que MySQL est un SGBD fichier et que c'est peut-être pas une bonne idée de continuer avec ça... Je me vois mal bloquer les users à partir de 25 sous prétexte qu'il y a plius de bande passante... Ah, et puis me pomper tout mon internet aussi, parce que mon hébergement est totalement privé sur un petit serveur perso. Pourriez vous m'aider à choisir un SGBD adapté? Je ne vois pas trop les différences entre Firebird, Oracle et PostGreSQl (d'autant plus qu'on m'a déconseillé ce dernier qui serait "pas assez abouti"). Autre question: quelle puissance serveur est nécessaire? Actuellement j'ai pas grand chose... 1Go de DDR2 (y'a de la place encore), et un Sempron 2,2GHz (le moins cher quoi...). Quels seraient les amméliorations nécessaires? J'ai cru comprendre que les disques SCSI étaient franchement recommandés. Oui mais bon... SCSI... 500¤ quoi... Pour 150Go ça fait mal. Merci beaucoup pour votre attention. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Shtong Posté(e) le 22 juin 2009 Partager Posté(e) le 22 juin 2009 Hello Tout d'abord une petite clarification : MySql, contrairement à ce que soutient ton article, n'est PAS un SGBD "fichier", mais bien "C/S". Mettre MySql dans le même sac que Access, j'en connais qui se seraient fait lyncher pour moins que ça Je pense que MySql peut très bien faire l'affaire si c'est ce que tu voulais utiliser à la base Lien vers le commentaire Partager sur d’autres sites More sharing options...
Mephisto Posté(e) le 23 juin 2009 Partager Posté(e) le 23 juin 2009 mysql est probablement le plus user-friendly des langages SQL (qui se respectent) et +1 pour le SGBD fichier mais par contre, au sujet de PgSQL: c'est pas parcequ'on est passé à côté du principal qu'on peu se permettre de dire de la merde comme ça. pour ta culture (et celle de ton con**rd d'informateur): http://www-css.fnal.gov/dsg/external/freew...l-vs-mysql.html sans parler de pl/pgsql, qui n'a rien à envier aux procédures mysql. et pour la peine, tu devrais le faire en PgSQL, histoire de comprendre la puissance du bazard. bref. niveau perfs, ta machine tient la route (si vos 800 membres ne sont pas tous connectés simultanéments à faire de la merde) précise-nous plutôt où et comment ton serv est relié au net Lien vers le commentaire Partager sur d’autres sites More sharing options...
mackwic Posté(e) le 24 juin 2009 Auteur Partager Posté(e) le 24 juin 2009 Merci pour vos réponses! :) Tout d'abord une petite clarification : MySql, contrairement à ce que soutient ton article, n'est *PAS* un SGBD "fichier", mais bien "C/S". Mettre MySql dans le même sac que Access, j'en connais qui se seraient fait lyncher pour moins que ça Ah bon? Nan parce que, autant Acces pour avoir été forcé de l'utiliser personnellement je l'exècre, autant MySQL je tiens ça par deux sources. Une que j'ai perdu (faute à google tout ça... ) et une autre qui n'est quand même pas moindre: develloppez.net ! Tenez un petit screen: Parce que si ils se sont trompés et que c'est bien un C/S, et qu'il intègre toutes les fonctionalités d'un autre serveur C/S plus "pro" moi il me va bien ce petit bonhomme. Ouais enfin bon maintenant que j'ai regardé les autres trucs comme Oracle ou Firebird, j'avoue que y'a des fonctions qui seraient indispensables. Pouvoir différer des requêtes surtout. Je n'ai rien vu qui y correspondait dans MySQL, mais j'ai probablement mal cherché en partant du principe que çay étais pas... mais par contre, au sujet de PgSQL: c'est pas parcequ'on est passé à côté du principal qu'on peu se permettre de dire de la merde comme ça.pour ta culture (et celle de ton con**rd d'informateur): http://www-css.fnal.gov/dsg/external/freew...l-vs-mysql.html sans parler de pl/pgsql, qui n'a rien à envier aux procédures mysql. Même chose ici. J'ai lu que PostGreSQL avait un potentiel certain mal exploité, qu'il était mal finalisé et au final pas intéressant. Qu'il vallait mieux faire, l'impasse et passer directement à un Firebird qui serait bien plus respectueux des normes et plus efficace (je te sors ça de tête mais c'était peu ou prou la phrase). D'ailleurs la comparaison n'était pas entre PostGreSQL mais entre PGSQL et d'autres serveurs SQL C/S. et pour la peine, tu devrais le faire en PgSQL, histoire de comprendre la puissance du bazard Je pense que je n'y manquerait pas. Il faut toujours tout essayer par soi même. Mais faut voir avec le temps disponible... niveau perfs, ta machine tient la route (si vos 800 membres ne sont pas tous connectés simultanéments à faire de la merde)précise-nous plutôt où et comment ton serv est relié au net Cool! Bon à savoir ça! :) Pour l'instant, la machine est reliée à une ADSL free aux perf assez moyennes. Je ne sais pas si ça va durer... On va surement passer à la fibre dès qu'elle arrivera. Ils sont en train de fibrer les immeubles chez nous là. Tenez une estimation made by free pedant que la ligne est utilisée par 5 ordinateurs: Débit descendant (download) 8,78 Mbit/s (1,1 Mo/s) Débit montant (upload) 819,84 kbit/s (102,48 ko/s) Merci en tout cas pour votre attention Lien vers le commentaire Partager sur d’autres sites More sharing options...
Shtong Posté(e) le 24 juin 2009 Partager Posté(e) le 24 juin 2009 Pour le débit au pire si tu as des problèmes même après avoir optimisé ton bazar, ça sera la bonne excuse pour t'offrir une petite double ligne Nerim Pour la place de MySql je persiste et signe : l'article sur lequel tu te base n'est pas correct. MySql est une base de données qui se respecte, non mais. Ceci étant dit elle est moins fournie en fonctionnalités que des moteurs plus lourds comme Oracle ou SQL Server (connais pas assez Firebird pour me prononcer), mais reste utilisable pour la plupart des utilisations. Qu'entends tu par des requêtes différées ? Plutôt comme l'option DELAYED ou plutôt comme les évènements ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
mackwic Posté(e) le 24 juin 2009 Auteur Partager Posté(e) le 24 juin 2009 Une autre ADSl nerim? Hmm pour 20¤/mois on va y réfléchir... Bon, et sinon wiki tout puissant semble confirmer ce que tu dis... Je pense que je vais envoyer un MP à un ou deux sois disant professionnels. Au fait, Firebird est une version gratuite de interbase 6. S'tout. Pour les requetes différées, je pense utiliser l'évènementielle, je crois pas que Delay me sera d'une quelconque utilité! Il s'agira par exemple de produire avec l'utilisateur un rapport toutes les x heures à partir d'une action sur des données de la BDD. Je ne sais pas si c'est possible avec MySQl... ou avec n'importe quel autre moteur. Je cherche... Lien vers le commentaire Partager sur d’autres sites More sharing options...
theocrite Posté(e) le 24 juin 2009 Partager Posté(e) le 24 juin 2009 autant MySQL je tiens ça par deux sources. Une que j'ai perdu (faute à google tout ça... ) et une autre qui n'est quand même pas moindre: develloppez.net ! Heu... joker. developpez.com, c'est pas franchement follichon. Mieux vaut se tourner vers les acteurs qui savent de quoi ils parlent (en l'occurrence le site officiel de mysql). Quand au fait que mysql ne pourrait pas supporter plus de 25 utilisateurs... hahaha. Juste pour rigoler : Slashdot : [...]5.5 million user visits per month. Over 9 million pages views daily.[...] Wikipedia : The master database servers run MySQL and store the article metadata. * The databases are subdivided over 3 clusters. See database clusters for more information + http://stats.wikimedia.org/FR/PlotsPngUsageVisits.htm http://stats.wikimedia.org/FR/PlotsPngDatabaseSize.htm Lien vers le commentaire Partager sur d’autres sites More sharing options...
mackwic Posté(e) le 24 juin 2009 Auteur Partager Posté(e) le 24 juin 2009 J'avoue. La preuve par l'exemple. Bon ben merci alors plus besoin de penser à une quelconque migration. Pis ça m'aprendra à surestimer mes sources... Au moins ça confirme une chose: j'ai bien fait de venir! vraiment merci les gars! Lien vers le commentaire Partager sur d’autres sites More sharing options...
RaphAstronome Posté(e) le 30 juin 2009 Partager Posté(e) le 30 juin 2009 Pour le serveur j'aurais tendance à dire que n'importe quel ordi convient si ton code est un minimum optimisé. Genre Pentium 2, 256Mo RAM, DD IDE : avec ça tu peut avoir plusieurs connectés simultanés sans pépin. La RAM à beaucoup plus d'importance que le CPU. Autre chose : regarde bien les inconvenants d'avoir un serveur chez toi (consommation, bruit, bande passante, fiabilité douteuse). Par rapport à un petit dédié c'est pas forcément si rentable. En plus ça dépend de ton site mais un mutualisé peux peut être convenir. Ta BDD fait quelle taille ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
mackwic Posté(e) le 30 juin 2009 Auteur Partager Posté(e) le 30 juin 2009 Personnellement après avoir essayé les deux types je toruve que y'a pas photo: pour un petit projet le serveur maison c'est l'idéal! Conso: pas plus de 100 watts Bruit: pas plus que mon ventilateur (le gros celui qui brasse l'air chaud de la hambre pour refroidir un peu le propriétaire des lieux ) BP: je survis... vu que nous sommes actuellement 12 à travailler dessus. Température dégagée: presque nulle (45 W de TDP processeur) Fiabilité: Bon ok seul point noir du tableau... Mais tous les serveurs bas prix ne proposent pas du RAID Puis bon, suffit de mettre les sous et ça s'upgrade facilement les DD. Suffit de payer quoi. ^^ Les petits plus bien pratique: un simple cp pour tout uploader possibilité de brancher n'importe quel périphérique en plus, du DD e-Sata à la simple clé USB. possibilité de tout controler au niveau du matos Après c'est clair que dès qu'on aura passsé les béta test et qu'on s'approchera d'un truc grand public il faudra peut-être penser vraiment à payer un serveur. Mais bon entre 20¤/mois la ligne ADSL supplémentaire et le prix pour un serveur équivalent... Je me demande si c'est vraiment intéressant. Lien vers le commentaire Partager sur d’autres sites More sharing options...
SnipX Posté(e) le 1 juillet 2009 Partager Posté(e) le 1 juillet 2009 En général, tu ne paies pas une ligne supplémentaire chez toi, ce n'est vraiment pas une bonne solution. Pour un serveur de dev, c'est parfait, pas pour de la prod. Tu loues un (ou plusieurs) serveurs dédiés, mais les prix varient de 20euros à ...très cher . Mais clairement, si tu veux un truc "pro", oublies le serveur chez toi Et si tu n'as pas énormément de visites, peut-être pourrais-tu commencer sur un serveur dédié virtuel, avec des prix encore plus attractifs. De nombreuses sociétés font ça aujourd'hui, cela t'assure que ton serveur est dans un datacenter, une BP assurée, et s'il y a un problème sur ton serveur (hard), ce n'est pas toi qui t'en occupe. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.