Discussion :

[Oxore]

Bonjour à vous,

Je travaille sur un projet perso de serveur de jeu, pour cela je dois gérer les joueurs (Grade, Permissions, Préférences, Statistiques...) via une BDD. Ces informations devront être accessibles facilement depuis un site Web (PHP), mais surtout en jeu (Java).

Pour ce faire j'utilisais jusqu'à maintenant une BDD MySQL (hébergée chez alwaysdata.com). Pour l'instant je n'en suis qu'aux tests, mais j'ai beaucoup de soucis avec MySQL:
- lenteur des requêtes (dans mon code en Java, j'insère les données sur la BDD et je souhaite les récupérer tout juste après (dans une autre classe par exemple), mais problème, les données n'ont pas eu le temps d'être ajoutées). Ceci dit le problème vient certainement de l'hébergement gratos
- erreurs à gogo (colonne inconnue alors qu'elle existe, je renvoie la requête et ça fonctionne)
- déconnexions intempestives (le programme en Java tourne sur un serveur et se la connexion à la BDD s'effectue au démarrage, et n'est fermée qu'à l'arrêt, si il n'y a pas transfert de données pendant un certains temps, la connexion se ferme. Problème, si à chaque fois que j'effectue une requête je dois vérifier que la connexion est ouverte, cela est extrêmement long!)

Bref, pour mes premiers pas avec un base de données, ça n'a pas été une grande réussite. J'ai donc cherché une alternative à MySQL, et je suis tombé sur PostgreSQL (certes plus complexe, mais d'après certains, plus évolué).
Voilà donc mon problème: pour une infrastructure d'environ 500 joueurs connectés en même temps (100 au début, mais on espère arriver à 1000 constant, et par conséquent une table "globale" recensant tous les joueurs, qui pourra dépasser les 50 000 / 100 000 joueurs à l'avenir), pensez-vous que PostgreSQL est intéressant (j'ai lu que pour les petites bases de données, MySQL est plus rapide) ? Je veux miser sur la rapidité des requêtes qui seront nombreuses, et sur la fiabilité (une erreur SQL est tout le programme foire, et les tous les joueurs sont déconnectés), et moins sur la complexité des tables. Quel est également votre avis sur MariaDB, est-ce une alternative convenable?

Désolé pour toutes ces questions, et merci de m'avoir lu jusqu'ici!

Oxore

[StringBuilder]

Si les données sont principalement à vocation de partage entre joueurs, sans que leur stockage physique soit une priorité (par exemple si 90% des données sont volatiles) alors privilégiez un SGBD qui propose des fonctionnalités InMemory.

Cela résoudra les problèmes de vitesse d'insertion/restitution puisque les données ne transiteront pas sur le disque, mais resteront en mémoire.
Attention, en contrepartie, suite à un arrêt brutal du serveur, toutes les données ne seront pas forcément retrouvées/synchrones. Il faut donc user sans abuser de cette fonctionnalité.

[alassanediakite]

Salut
J'ai pas encore travaillé dans ce genre de projet mais je pense que trop solliciter la BD n'est pas la meilleur façon.
Je m'explique.

• La BD enregistre les paramètres du jeu, les joueurs et leurs étapes.
• lorsqu’un joueur se connecte, il charge son statut sur le client
• lorsqu'un joueur atteint in niveau on enregistre son statut et on le charge au besoin
• lorsqu’un joueur quitte, son statut est enregistrer dans la BD

Avec ce schéma c'est le client qui est beaucoup sollicité et le SGBD sur le serveur n'enregistre que les états. Pour ce qui est de la vérification de la connexion je pense que c'est bon ainsi, cela réduit l'utilisation des ressources.
@+

[Community Management]

Bonjour, je vous propose ici un sondage global sur les SGBD SQL ?

[SQLpro]

Bonjour à vous,

Je travaille sur un projet perso de serveur de jeu, pour cela je dois gérer les joueurs (Grade, Permissions, Préférences, Statistiques...) via une BDD. Ces informations devront être accessibles facilement depuis un site Web (PHP), mais surtout en jeu (Java).

Pour ce faire j'utilisais jusqu'à maintenant une BDD MySQL (hébergée chez alwaysdata.com). Pour l'instant je n'en suis qu'aux tests, mais j'ai beaucoup de soucis avec MySQL:
- lenteur des requêtes (dans mon code en Java, j'insère les données sur la BDD et je souhaite les récupérer tout juste après (dans une autre classe par exemple), mais problème, les données n'ont pas eu le temps d'être ajoutées). Ceci dit le problème vient certainement de l'hébergement gratos
- erreurs à gogo (colonne inconnue alors qu'elle existe, je renvoie la requête et ça fonctionne)
- déconnexions intempestives (le programme en Java tourne sur un serveur et se la connexion à la BDD s'effectue au démarrage, et n'est fermée qu'à l'arrêt, si il n'y a pas transfert de données pendant un certains temps, la connexion se ferme. Problème, si à chaque fois que j'effectue une requête je dois vérifier que la connexion est ouverte, cela est extrêmement long!)

la grande joie de MySQmerde... A lire : http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux

Bref, pour mes premiers pas avec un base de données, ça n'a pas été une grande réussite. J'ai donc cherché une alternative à MySQL, et je suis tombé sur PostgreSQL (certes plus complexe, mais d'après certains, plus évolué).
Voilà donc mon problème: pour une infrastructure d'environ 500 joueurs connectés en même temps (100 au début, mais on espère arriver à 1000 constant, et par conséquent une table "globale" recensant tous les joueurs, qui pourra dépasser les 50 000 / 100 000 joueurs à l'avenir), pensez-vous que PostgreSQL est intéressant (j'ai lu que pour les petites bases de données, MySQL est plus rapide) ? Je veux miser sur la rapidité des requêtes qui seront nombreuses, et sur la fiabilité (une erreur SQL est tout le programme foire, et les tous les joueurs sont déconnectés), et moins sur la complexité des tables. Quel est également votre avis sur MariaDB, est-ce une alternative convenable?

MariaDB c'est la même merde que MySQL mais en plus libre....

Désolé pour toutes ces questions, et merci de m'avoir lu jusqu'ici!

Oxore

PostGreSQL est sans acun doute le meilleur SGBDR libre open source.

Mais tous ces outils OpenSource ont le même inconvénient majeur : leur incapacité en pratique de fonctionner 24h/24 7j/7.
Par exemple leboncoin utilise un batterie de plus de 100 serveurs PostGreSQL pour satisfaire la charge là ou un seul Serveur Oracle ou SQL Server suffit et malgré cela ils arrêtent les serveurs la nuit pour faire la maintenance courante.
Cela n'existe pas sur les serveurs comme oracle ou SQL Server ou tout est fait à chaud et en pleine production...

Donc ta question est : tes utilisateurs vont-ils jouer la nuit ?

Si oui, alors oriente toi vers SQL Server qui est 24 fois moins cher qu'Oracle et présente différentes éditions pour la montée en charge :

• EXPRESS gratuite pour démarrer
• WEB dès qu'il y a quelques dizaines d'utilisateurs (cout : 30 euros par mois)
• AZURE, standard ou Enterprise si la montée en charge est forte

A +


l

[JPLAROCHE]

en bref j'arrive de DB2 IPOWER 2500 user en web 150 user interactif. réponse 3 nanoseconde sur AS400 natif 40 job (instance) a dispos pour le web et je n'arrive pas à saturer.

j'ai fait un bascule de site web de DB2 sur PostgreSql Sur un serveur Linux je n'ai eu aucun problème je tourne avec la 9.5 ---> en attente de validation

je me suis attelé pour tester MariaDB 10.2 j'ai retrouvé tout mes petits , toujours sur le même type de serveur , dans mes testes je n'ai pas remarqué de problème , sauf la doc , elle n'ai pas en français , mais un livre vient de sortir chez eyrolles pour aller beaucoup plus loin. pour mon compte faire de la multi-instance.....

l'un comme l'autre pour passer à un niveau supérieur il faut prendre la version entreprise.

mais pour du gratuits opensource je ne vois pas la différence .

pour moi j'avais besoin de confirmer la possibilité de basculer sur un serveur Linux un site web a grande disponibilité, et des temps de réponse honorable. il n'était pas question de rivaliser avec l'AS400,
mais de répondre a un cahier des charges . c'est du CGI c++ avec tout cela comporte templates... etc ... de plus nous voulons faire du temps réel et l'on s'attaque avec les nouvelles technologies websockets a rendre ("libwebsockets dans Linux mais il y a pendant sur win" puisque c'est un accords de l'ensemble des grands acteurs depuis janvier 2016) pour le moment avec des testes simples cela commence à fonctionner.

donc mon jugement est qu'il faut utiliser avec l'un comme avec l'autre c'est en rentrant vraiment dans le code faire vos lib d'accès et remonter avec des macros afin de n'avoir que le metier dans vos applications . pour C++ PGSQL une interface de programmation très structurer et opérationnel ou la libconnect pour Mariadb en c++ les deux en mode interactif font le même travail. en mode asynchrone avec Apache aussi .
l'un comme l'autre il vous faudra retrousser les manches. aujourd'hui condamnée MariaDB est une erreur pour preuve l'ensemble des distributions on fait le pari sur MariaDB non pas qu'il rejette Posrgresql mais on lâché Mysql et MariaDB s'en vas rejoindre les grands acteurs de base de données . pour cela regarder l'évolution 10.2 --> et allez constater les notes.

des bugs l'un comme l'autre mais n'ont attraits qu'a des chose mineurs souvent sur les betas .... de toutes façons ils y aura toujours un patch soit pour corriger soit pour améliorer.

je ne pense pas qu'il y ai un match entre les deux .

après si vous voulez travailler sur des milliards de données en pathroug ou avec des réplications peut-être si j'ose me permettre avec un Ipower qui incorpore as400 et( Linux et win qui ne sont que des carte dédier) là vous aborder un autre monde par exemple celui de la finances ou la sécurité maximum est exiger la vitesse ... et le prix aussi .....

[JPLAROCHE]

supérieure fonctionnalités richesse et de soutien pour SQL complexe Postgres est seulement utile lorsque vous déplacez une grande partie de votre logique d'application à la base de données. Ceci est un anti-modèle, dans le monde d'aujourd'hui. Cela a été utile à un moment où la plupart de la logique d'application résidait dans la base de données, emballés comme les procédures stockées et les fonctions et les déclencheurs et tout ce que la base de données particulière a été soutenu, et les clients et les serveurs d'applications étaient une couche mince sur le dessus de la base de données. A cette époque, était postgres ans avant toute autre chose, y compris la plupart des offres commerciales.

Mais ce n'est plus le cas. En règle générale, une grande partie de la logique d'application est le code destiné à être exécuté en dehors de la base de données. Ayant divisé logique à travers les deux Java ou C # ou C ++ ou PHP ou tout autre langue que vous utilisez et aussi emballés comme SQL dans la base de données est très difficile à gérer, à terme obtenir votre architecture à s'effondrer, conduisant à un désordre ingérable. Une raison de plus pour aller avec MariaDB - les limites de la base de données agissent vers votre intérêt, ce qui est de garder toute logique liée à un seul endroit - le code source.

[SQLpro]

supérieure fonctionnalités richesse et de soutien pour SQL complexe Postgres est seulement utile lorsque vous déplacez une grande partie de votre logique d'application à la base de données. Ceci est un anti-modèle, dans le monde d'aujourd'hui. Cela a été utile à un moment où la plupart de la logique d'application résidait dans la base de données, emballés comme les procédures stockées et les fonctions et les déclencheurs et tout ce que la base de données particulière a été soutenu, et les clients et les serveurs d'applications étaient une couche mince sur le dessus de la base de données. A cette époque, était postgres ans avant toute autre chose, y compris la plupart des offres commerciales.

Mais ce n'est plus le cas. En règle générale, une grande partie de la logique d'application est le code destiné à être exécuté en dehors de la base de données. Ayant divisé logique à travers les deux Java ou C # ou C ++ ou PHP ou tout autre langue que vous utilisez et aussi emballés comme SQL dans la base de données est très difficile à gérer, à terme obtenir votre architecture à s'effondrer, conduisant à un désordre ingérable. Une raison de plus pour aller avec MariaDB - les limites de la base de données agissent vers votre intérêt, ce qui est de garder toute logique liée à un seul endroit - le code source.

Autant de bétise en si peu de mots, il y a longtemps que je n'avais vu cela...

Expliquez moi donc pourquoi les SGBD relationnels comme SQL Server ont une croissance positive largement supérieure en nombre d'installation aux autres formes de SGDB ???

Pour info (état du marché 2016) étude gartner :
"
The DBMS market had strong growth of 8.1% in 2016, driven by organizations expanding their data management portfolios. The semi-structured DBMS segment continued its strong above-market-rate growth at 76.6%, while RDBMS grew 6.4%. Pre-relational era DBMS continued its decline
"

En nombre d'installation les SGBD relationnels restent en tête devant les "noSQL".

A +

[JPLAROCHE]

Autant de bétise en si peu de mots, il y a longtemps que je n'avais vu cela...

Expliquez moi donc pourquoi les SGBD relationnels comme SQL Server ont une croissance positive largement supérieure en nombre d'installation aux autres formes de SGDB ???

Pour info (état du marché 2016) étude gartner :
"
The DBMS market had strong growth of 8.1% in 2016, driven by organizations expanding their data management portfolios. The semi-structured DBMS segment continued its strong above-market-rate growth at 76.6%, while RDBMS grew 6.4%. Pre-relational era DBMS continued its decline
"

En nombre d'installation les SGBD relationnels restent en tête devant les "noSQL".

A +

votre jugement ????
parce que sur pc il faut des services qui savent géré des données . afin de permettre de faire des études aux grands utilisateurs. (pour cela que noSQL prend du galon)
mais pour les applicatifs fermer (aux utilisateurs) c'est une autre chose.

demain certainement prendre le meilleurs de SQL et de noSQL pour faire une autre approche , ce qui eviterait les exportations .....
@bientôt

[JPLAROCHE]

Autant de bétise en si peu de mots, il y a longtemps que je n'avais vu cela...

Expliquez moi donc pourquoi les SGBD relationnels comme SQL Server ont une croissance positive largement supérieure en nombre d'installation aux autres formes de SGDB ???

Pour info (état du marché 2016) étude gartner :
"
The DBMS market had strong growth of 8.1% in 2016, driven by organizations expanding their data management portfolios. The semi-structured DBMS segment continued its strong above-market-rate growth at 76.6%, while RDBMS grew 6.4%. Pre-relational era DBMS continued its decline
"

En nombre d'installation les SGBD relationnels restent en tête devant les "noSQL".

A +

il n'y a pas que vous qui avez un CV

vos articles sont bien conçu, mais et oui il y a un mais il commence à dater.... ( cela ne remet pas la valeurs de votre implications dans la mise à disposition d'une tel documentation (volumineuse) )
https://eng.uber.com/mysql-migration/ une explication mais remarquez que je ne me suis pas permis de critiquer PostgrEsql car c'est un produit qui pour moi est correct.
ça c'est des sujets intéressant qui aujourd'hui peuvent faire pencher la balance. (ps je n'ai jamais travailler pour UBER) et quand il parle de Mysql il sous entends MariaDB je ne peut pas vous données l'ensemble de l'article

entre autre je comprends pas que l'on ne puisse débattre à bâton rompu sans que les querelles de clochers ce mettent à sonner à tout vas.
car si il y a un lieu pour en discuter et faire avancé le schmilblick c'est bien sur ce forum
et pourquoi pas répondre à un problème bien souvent posé.(pour un temps car tout évolue )

dans votre article il fut un temps ou je vous ne vous aurais pas contredit sur le choix .... mais aujourd'hui on a le droit de ce poser des questions non sans importances

a+

[escartefigue]

En règle générale, une grande partie de la logique d'application est le code destiné à être exécuté en dehors de la base de données. Ayant divisé logique à travers les deux Java ou C # ou C ++ ou PHP ou tout autre langue que vous utilisez et aussi emballés comme SQL dans la base de données est très difficile à gérer, à terme obtenir votre architecture à s'effondrer, conduisant à un désordre ingérable. Une raison de plus pour aller avec MariaDB - les limites de la base de données agissent vers votre intérêt, ce qui est de garder toute logique liée à un seul endroit - le code source.

Vos propos sont pour le moins confus.
Quoi qu'il en soit, affirmer que les limites d'une base de données sont un atout est plus que surprenant !
Aucun code source n'est capable de garantir l'intégrité d'une base de données multi-utilisateurs, seul le SGBD peut le faire, voilà déjà une bonne raison s'il n'en fallait qu'une, de choisir une BDD moderne et performante, or Maria DB a environ 15 ans de retard sur bien des sujets (gestion des verrous, partitionnement, collations, fonctions OLAP, requêtes récursives, normes SQL...)

[JPLAROCHE]

Vos propos sont pour le moins confus.
Quoi qu'il en soit, affirmer que les limites d'une base de données sont un atout est plus que surprenant !
Aucun code source n'est capable de garantir l'intégrité d'une base de données multi-utilisateurs, seul le SGBD peut le faire, voilà déjà une bonne raison s'il n'en fallait qu'une, de choisir une BDD moderne et performante, or Maria DB a environ 15 ans de retard sur bien des sujets (gestion des verrous, partitionnement, collations, fonctions OLAP, requêtes récursives, normes SQL...)

bonjour,
la contrainte référentiel fait partie intégrante d'une BDD . enfin à mon humble avis. sinon ce n'est plus une BDD
mais la logique de programmation ne doit en pâtir sous prétexte de la BD vas tout résoudre.
je ne sais pas mais dans le service tout était testés , et même plus . je ne vends pas à l'entreprise qui m’emploie un service finit a 90% .

vous devriez aller voir MariaDB et leurs dire que cela a quinze ans et que rien n'a été réécrit ni repensé , ni apporté de nouvelle fonction et fonctionnalité,
D'autre part ce n'est pas parce-que vous gardez des mêmes nom de fonctions qu'elle ne peuvent pas être réécrite. dans ma vie d’informaticien j'ai dut reprendre mon métier plusieurs fois pour introduire de fiabilité , de vitesse , de souplesse... , mettre du nouveau code pour améliorer la lisibilité etc....
vous avez la réponse tout est en ligne sur les sujets dont vous abordez.

ces articles sont sur le web
"MariaDB AX est une solution de stockage de données source moderne, ouvert extensible pour les grandes données d' analyse / OLAP : pas besoin de matériel complexe et coûteux"
"Récursivité avec les CTE Afin de parcourir un arbre ... mais cette technique est opérationnelle depuis Maria DB 10.2.2"
"possède de manière native des verrous. Ces verrous sont associés à des connexions à la base de données"
"En MariaDB , le jeu de caractères par défaut est latin1, et la valeur par défaut collation est latin1_swedish_ci (mais cela peut varier dans certains distros, voir par exemple les différences....) mais doit être définis UTF8 enfin sur arche c'est comme ça qu'ils le pensent", d'ailleurs comment ne pas mettre sa DB autrement quand UTF-8 ??? ...
allez sur l'onglet de mariadb "SQL Conformance" ou " Partitioning Overview"

encore une fois tout cela c'est pas le problème ..... aujourd'hui . bien-sur je parle de dernière versions avant cela ne m' intéressait pas .
@bientôt

[aieeeuuuuu]

Ayant divisé logique à travers les deux Java ou C # ou C ++ ou PHP ou tout autre langue que vous utilisez et aussi emballés comme SQL dans la base de données est très difficile à gérer, à terme obtenir votre architecture à s'effondrer,

Non, c'est tout l'inverse. Avoir la logique métier dans le code applicatif, ça oblige parfois (souvent) à dupliquer la même logique métier dans différents langages, en différents endroits, voire par différentes équipes.
Donc plus de code, donc plus de bugs, donc plus de maintenance.

Tout n'est pas cependant binaire, et il faut trouver le bon compromis, mais c'est pour cela que les architectes existent, enfin... quand ils existent...

[JPLAROCHE]

merci d'avoir repondu,

je ne pense pas que vous pouvez me juger ne me connaissant pas. mais pas grave .... quand à écrire des applications je n'ai plus de leçon a recevoir , et je maintiens que la base de données pour moi ce limite a géré des datas , je n'en fait pas un sous langage dans le quel je code des règles , c'est déporter les problèmes, une base de données doit être rapide et fiable ou plus de 2000 connections peuvent être consécutive et des temps de réponse en dessous de la seconde , venant du monde IBM avec DB2 . les cagasses de réglage pour géré les cluster moi ca me gave ou les buffer , sans parler des vacum.
une base de données doit être disponible point barre, lors d'un projet je me concentre sur quel est le besoin pour l'entreprise , comment y répondre tout en restant le plus simple possible et en tenant compte de la maintenance, si je doit aussi inclure un temps non négligeable sur la maintenance d'un serveur ( service ).... par contre je préfère me concentrer sur comment articuler autour de mon dictionnaire de définition et comment attribuer les tables et logique (vue) voir les joins (vue) de tel manières que cela soit le plus rentable dans les applications. Un model de référentiel basé sur la théorie des ensembles .
alors si le gestionnaire de base de données est fiable et reconnue comme tel , et surtout ne me demandez pas de mettre une ou deux personnes pour gérés ce service , le prix n'est pas un problème , le problème est que lorsqu'une base de données finit par invalidé ses tables ??? choses pour moi inadmissible. et par la casse la cohérence avec l'ensemble du transactionnel , qu'il faut passez plus de temps a récupérer (si c'est encore possible) les datas .... pour ça j' invalide le service proposé.

je me fou de savoir si PostgrEsql ou MariaDB est le meilleurs , si je veux confier une taches sur PC (serveur type PC) je me contenterais du solide bien gras.

quand a MariaDB , Amazone , Google , les éditions Linux, l'on pris alors vous pouvez me dire n'importe quoi mais ce sont des références. et si j'ai Défendu MariaDB ce n'est pas pour convaincre qu'il est le meilleurs mais bien pour voir si vous alliez parlez de compétitivité de fiabilité , de simplification de maintenance .... et en tout honnêteté. si vous êtes convaincue et aveugle sur vos choix, moi pas , je n'ai pas d'action chez MariaDB ni de rancune sur PostgrEsql , j'ai pratiqué les deux .

quand à MSsql c'est pareil j'ai été aussi obligé de travaillé avec quand je vois tous le bastring qu'il faut mettre en œuvre.....

bref dans tout cela sans parler des problèmes de dérégulation dut au matériel.... vous m'auriez intéressés si vous m'aviez dit que ACID était un sujet clos aujourd'hui les problème sont réglés, mais vous aviez abordé autre chose.... ce n'est pas la cas.

quand à la déportation de la programmation dans la base de données , sur des applications qui comporte plus d'un millions de lignes , c'est bannis ce genre de trucs .

par contre je conçois parfaitement que l'on puisse ce servir d'un base de données sql avec des regles ou procedure pour bâtir un L4G avec un langage fondamental. mais là c'est une autre histoire.

et encore SQL n'est qu'un moteur . rien d'autre. soit il tourne soit il ne tourne pas. et pourquoi on s'en sert et surtout comment on s'en sert.

@bientôt

[JPLAROCHE]

Non, c'est tout l'inverse. Avoir la logique métier dans le code applicatif, ça oblige parfois (souvent) à dupliquer la même logique métier dans différents langages, en différents endroits, voire par différentes équipes.
Donc plus de code, donc plus de bugs, donc plus de maintenance.

Tout n'est pas cependant binaire, et il faut trouver le bon compromis, mais c'est pour cela que les architectes existent, enfin... quand ils existent...

oui si vous travaillez sur pc et que avez plein de langage .... (moi perso je ne suis pas pour avoir plein de langage).

je suis d'accords avec votre dernière phrase tout n'est pas binaire ....

nous avons utiliser une Méthode AXIAL combiné à Merise c'est une méthode américaine qui permettait de raisonné en introduisant la théorie des ensembles tant sur la définition de la granulation de la base de donnée que sur les modules (programme) et d'avoir une interaction entre eux.

ce qui permettait de n'avoir pas de duplication de logique de métier. ce que je trouve de dommage c'est qu'IBM n'est pas diffusé et gardé jalousement ( puisque propriétaire ) ... bref on peut pas refaire le monde.
merci d'avoir répondu.