Base de données pour un serveur (de jeu)

Bonjour,

J'ai un jeu en C++ sur lequel il est courant d'avoir 150 joueurs connectés sur le serveur principal, et j'en attend plus dans le futur (aux environ de 500, voire plus) ^^. Le problème est que je ne suis pas sûr que les moyens mis en place conviennent toujours avec cette croissance.

J'ai pour l'instant un fichier de 15000 utilisateurs, comprenant peu d'info sur chaque joueur (login, salt du mdp, hash du mdp, ip, derniere date de login, + 3 octets). En gros, environ 100 octets par utilisateur.

La solution que j'utilise maintenant est d'avoir toute la base de données en mémoire (pour info le fichier texte/csv fait 1,5 MO). Pour les mises à jour du fichier, la position de chaque utilisateur est stockée en mémoire et le fichier est constamment ouvert pour effectuer tout ça rapidement.

Mais j'aimerais éviter d'avoir un stockage en mémoire proportionnel au nombre d'utilisateurs stockés.

J'ai pensé à faire d'autre systèmes comme un cache des derniers 10000 utilisateurs, gérer le reste dans des fichiers triés tous les jours avec des index pour éviter de parcourir tout le fichier à la fois, etc. Mais je me suis dit qu'il serait peut-être plus judicieux d'utiliser quelque chose de déjà existant et maintenu, dont je n'ai plus à m'occuper.

La principale crainte que j'ai avec MySQL est que ce puisse être lent, beaucoup plus lent que mon système actuel. De plus je n'ai pas besoin du modèle relationnel du tout, c'est pour ça que je vous demande si vous connaissez un système de base de données, performant :p, et qui ne s'appuie pas forcément sur un modèle relationnel (car j'en ai pas vraiment besoin, je veux juste récupérer les infos d'un membre à partir de son nom, c'est tout ce que je demande au système), interfaceable facilement avec du C++ et multi-plateforme. Si vous me dites que MySQL est le meilleur choix, je serais forcé de vous croire, mais je suis pas convaincu...

J'ai entendu parler de systèmes comme Cassandra ou No Couch DB, c'est pour cela que je m'interroge sur la nécessité du SQL dans ce cas-ci.

Merci d'avance!!

Citation:

---

Envoyé par coyotte507

De plus je n'ai pas besoin du modèle relationnel du tout

---

Nuance : vous ne savez pas vraiment ce que c'est et vous déduisez ne pas en avoir besoin.

Dès qu'une application travaille sur une donnée stockée, il y a un MCD lié à l'applicatif et donc un MLD / MPD.

Un modèle simpliste (une table), c'est déjà un modèle, et si vous expliquiez votre application je suis quasiment certain qu'on passerait déjà à un modèle toujours simple mais avec trois ou quatre relations.

Vu les volumétries en jeu, vous pouvez utiliser n'importe quel moteur de base de donnée, ça fonctionnera.

Citation:

---

La solution que j'utilise maintenant est d'avoir toute la base de données en mémoire (pour info le fichier texte/csv fait 1,5 MO). Pour les mises à jour du fichier, la position de chaque utilisateur est stockée en mémoire et le fichier est constamment ouvert pour effectuer tout ça rapidement.

---

Un SGBDR travaille exclusivement en RAM. Toutes les requêtes sont faites sur des données mémoire, jamais sur le disque. Le disque ne sert qu'à gérer la couche de persistance. A partir de là, il suffit de prévoir la RAM du serveur en adéquation avec le volume des données exploitées.
Si vous avec 1,5 Mo de données pour 150 user, cela fait pour 500 : 5 Mo, ce qui est très faible pour un SGBDR...

Citation:

---

Mais j'aimerais éviter d'avoir un stockage en mémoire proportionnel au nombre d'utilisateurs stockés.

---

Dans ce cas, restez en au fichier et n'utilisez pas de SGBDR !

Citation:

---

J'ai pensé à faire d'autre systèmes comme un cache des derniers 10000 utilisateurs, gérer le reste dans des fichiers triés tous les jours avec des index pour éviter de parcourir tout le fichier à la fois, etc. Mais je me suis dit qu'il serait peut-être plus judicieux d'utiliser quelque chose de déjà existant et maintenu, dont je n'ai plus à m'occuper.

---

Le SGBDR fait du cache avec des algorithmes intelligent, de manière native, avec des technique beaucoup plus pointues que ce que vous pourriez fairfe à la main en passant quelques dizaines d'année homme à développer !

Citation:

---

La principale crainte que j'ai avec MySQL est que ce puisse être lent,

---

MySQL est un SGBDR parmi d'autre et le plus mauvais en matière de concurrence d'accès. Les performances s'effondrent dès que plus d'une dizaine d'utilisateur veulent mettre à jour la même table.
Préférez donc un vrai SGBDR comme PostGreSQL (qui d'ailleur est du vrai libre, car MySQL en dépit de ce que tout le monde raconte est payant !).

Citation:

---

La principale crainte que j'ai avec MySQL est que ce puisse être lent, beaucoup plus lent que mon système actuel. De plus je n'ai pas besoin du modèle relationnel du tout, c'est pour ça que je vous demande si vous connaissez un système de base de données, performant :p, et qui ne s'appuie pas forcément sur un modèle relationnel (car j'en ai pas vraiment besoin, je veux juste récupérer les infos d'un membre à partir de son nom, c'est tout ce que je demande au système), interfaceable facilement avec du C++ et multi-plateforme. Si vous me dites que MySQL est le meilleur choix, je serais forcé de vous croire, mais je suis pas convaincu...

---

Les SGBDR travaillant en RAM sont beaucoup moins lente que toute solution à base de fichier... Vous vous méprenez totalement sur le sujet.
D'autre part qui dit SGBDR dit modèle relationnel. Si vous vous contentez de reproduire votre principe de fichier sur un SGBDR, cela nuira aux perfmances beaucoup plus que si vous faites les choses correctement. En effet utiliser un outil quel qu'il soit à contre emploi est contre productif. Mais dans ce cas ce n'est pas l'outil qui est contre productif, c'est celui qui a mis au point la méthode qui l'a rendu sciemment contre productif !!!

Citation:

---

J'ai entendu parler de systèmes comme Cassandra ou No Couch DB, c'est pour cela que je m'interroge sur la nécessité du SQL dans ce cas-ci.

---

Avant de commencer à contourner telle ou telle technologie il faut savoir de quoi retourne cette technologie... Sinon, vous serez comme une grande majorité d'informaticiens une "techno victime". Vous utiliserez tel ou tel produit parce que c'est à la mode et non pas parce que c'est adapté à votre problématique...

A +

PS : désolé d'avoir fait disparaitre quelques instant votre post original...

D'accord... Je ne savais pas que tout étais mis en RAM (je ne connais pas grand chose au sujet, c'est d'ailleurs pour ça que je poste :). Mais dans ce cas pourquoi VBulletin met les posts des derniers jours en cache dans des fichiers pour être plus rapide??). Enfin, si tout est mis en RAM, ça veut dire que je n'ai pas besoin de bases de données du tout, car je doute que MySQL puisse me récupérer les info plus rapidement que moi en mémoire avec un Hash (O(1)).

J'ai 15 000 utilisateurs stockés, mais au fil du temps ça pourra facilement passer à 200 000 (d'après un autre projet similaire), d'où mes craintes. J'ai aussi oublié de préciser que j'utilise un autre fichier, qui contient les scores de chaque utilisateurs, et qui est mis à jour rapidement (comptez une fin de combat environ toutes les 3 secondes, ce qui fait une mise à jour des scores avec cettes fréquences), et je me demandais si justement un système de bases de données comme MySQL était adapté (comme m'a dit un ami "a single MySQL query is cheap, a bunch of them not really"). Le fichiers des utilisateurs en lui-même (pas celui des scores) n'est mis à jour que quand quelqu'un se connecte avec un nouveau login, son IP ou sa dernière date de login change.

En tout cas déjà merci pour le conseil d'utiliser PostGreSQL au lieu de MySQL.

Merci pour votre aide!

---
Edit: Les 150 users c'est ceux connectés simultanément, la base de données en a 15000, de même, @Wadar, j'ai expliqué le stockage des utilisateurs: (login, salt du mdp, hash du mdp, ip, derniere date de login, + 3 octets)

Les SGBD peuvent gèrer plusieurs milliers de transactions par secondes...

Citation:

---

J'ai 15 000 utilisateurs stockés, mais au fil du temps ça pourra facilement passer à 200 000 (d'après un autre projet similaire), d'où mes craintes.

---

Ne confondez pas utilisateurs, utilisateurs connectés et exécution en //.
Le nombre d'utilisateur intrinsèque d'un système peut être de plusieurs milliard, cela n'a aucune importance.
Sur les meilleurs SGBDR (Oracle, SQL Server, IBM DB2) on peut monter à plus de 30000 utilisateurs connectés. Cela ne vuet pas dire que chacun lance une requête à ce moment là. Dans ce type d'application ou les requêtes sont très minimes en terme,de volume de données, la durée moyenne d'une requête devrait être bien inférieur à la milliseconde.... Même en cliquant à toute allure, 10000 utilisateurs simultanés n'arriverons pas à saturer un tel SGBDR.

Citation:

---

J'ai aussi oublié de préciser que j'utilise un autre fichier, qui contient les scores de chaque utilisateurs, et qui est mis à jour rapidement (comptez une fin de combat environ toutes les 3 secondes, ce qui fait une mise à jour des scores avec cettes fréquences), et je me demandais si justement un système de bases de données comme MySQL était adapté (comme m'a dit un ami "a single MySQL query is cheap, a bunch of them not really"). Le fichiers des utilisateurs en lui-même (pas celui des scores) n'est mis à jour que quand quelqu'un se connecte avec un nouveau login, son IP ou sa dernière date de login change.

---

Comme déjà dit, dans les SGBDR il n'y a pas de fichiers. Il y a des tables et un modèle de données. Abandonnez toute notion de fichier, sinon, vous allez au devant de très sérieux problèmes...
Sachez qu'un SGBDR peut aller jusqu'à 5 millions de transactions complexes (portant sur la mise à jour combinées de multiples données) par MINUTES....
Dans votre cas : une seule table à mettre à jour toutes les 3 secondes, même avec 10000 utilisateurs SIMULTANES (ce qui est rare) cela ne fait que
200 000 transactions par minutes, soit 25 fois moins... Autrement dit avec un serveur de moyenne gamme, vous n'aurez aucun problème.

Mais la première étape est de vous former à ce qu'est un SSGBDR, un modèle de données, les requêtes SQL... ect. Sans cela vous êtes mort !

A =

J'ai des connaissances en SQL (mon site avait un forum fait à la main avant de passer à VBulletin), je connais les concepts de clé primaire, clé étrangère, jointure, ... Je me posais juste des questions sur les performances, et bien sûr le fichier peut ne pas être mis à jour en même temps que les tables. Ici le modèle de données ne sera pas compliqué , juste une table pour les infos "vitales", une table par catégorie pour les scores dans chacune de ces catégories... Ces dernières ayant bien sûr comme clé primaire une clé étrangère vers la table "principale".

Merci d'avoir effacé tous ces doutes sur les performances (un reste de l'époque ou je voulais tout refaire moi-même :aie:), et une dernière petite question ^^

Entre PostGreSQL et SQLLite, à votre avis lequel devrais-je choisir? Sachant que mon programme est en C++, et que je n'ai pas envie que l'utilisateur (le serveur est librement distribué et il y a plusieurs serveurs qui tournent) ait besoin de lancer le serveur SQL, mais que celui-ci se lance en même temps que mon programme, et se ferme en même temps si possible... Et que ce soit multiplateforme (Mac, Linux, Windows). Sachant que le framework que j'utilise permet de se connecter aux deux facilement.

Merci.

PS: Votre guide sur le SQL a l'air intéressant, je vais lire tout ça pour me cultiver

Edit:

Justement c'est au niveau des performances pour trouver un utilisateur non connecté (et donc logiquement pas mis dans la RAM si pas connecté depuis très longtemps) dont je m'inquiétais, car d'après ce que vous avez dit même s'il y a un milliard d'utilisateurs, seuls les utilisateur connectés "comptent". Ca ne me dérange pas que le serveur SQL utilise beaucoup de RAM, tant qu'il s'arrête à un moment (en tenant compte peut être de la RAM disponible sur un ordinateur), mais vu le volume des données ce n'est peut-être pas vital.

Edit 2:

D'après votre guide sur le SQL:

Citation:

---

Bien que la clause ORDER BY ne soit pas nécessaire, il est souvent utile de trier la réponse en fonction des colonnes. En revanche le temps de réponse s'en ressent souvent.

---

Justement, pour le classement des joueurs j'utilise une structure de donnée spéciale en mémoire (arbre rouge-noir qui associe score / utilisateur modifié pour pouvoir déterminer le classement de tel noeud en O(log(n)), toutes les opérations restant en O(log(n)), et obtenir le classement de x à x+k se fait en O(log(n) + k) ), et donc je voulais savoir si SQL peut gérer ce type de structure (classement, ou ORDER BY) bien dans le temps (par exemple le serveur SQL conserverait l'ordre en mémoire après une première requête ORDERBY) ou est-ce que je devrais faire des aménagements...

Citation:

---

Envoyé par coyotte507

Merci d'avoir effacé tous ces doutes sur les performances (un reste de l'époque ou je voulais tout refaire moi-même :aie:)

---

sans doute en êtiez vous resté à des bases non C/S, c'est à dire sous forme de fichier comme Access, dbBase ou Windev. Aujourd'hui ces types de SGBDR sont en voie de disparition au profite des SGBDR C/S (Client/server) avec l'avantage de traiter les données exclusivement en mémoire...

Citation:

---

, et une dernière petite question ^^

Entre PostGreSQL et SQLLite, à votre avis lequel devrais-je choisir? Sachant que mon programme est en C++, et que je n'ai pas envie que l'utilisateur (le serveur est librement distribué et il y a plusieurs serveurs qui tournent) ait besoin de lancer le serveur SQL, mais que celui-ci se lance en même temps que mon programme, et se ferme en même temps si possible... Et que ce soit multiplateforme (Mac, Linux, Windows). Sachant que le framework que j'utilise permet de se connecter aux deux facilement.

---

SQLlite et PostGreSQL ne sont pas du tout du même niveau. SQLLite fonctionne sous forme de fichier comme Access ou dBase et est prévu pour fonctionner en mode mono utilisateur dans des processus embarqué (missile par exemple). Ce n'est pas du tout le cas de PostGreSQL qui est en client/serveur et capable d'absorber plusieurs centaines d'utilisateurs simultanément.
Donc le choix est vite fait !

Citation:

---

Justement c'est au niveau des performances pour trouver un utilisateur non connecté (et donc logiquement pas mis dans la RAM si pas connecté depuis très longtemps) dont je m'inquiétais, car d'après ce que vous avez dit même s'il y a un milliard d'utilisateurs, seuls les utilisateur connectés "comptent". Ca ne me dérange pas que le serveur SQL utilise beaucoup de RAM, tant qu'il s'arrête à un moment (en tenant compte peut être de la RAM disponible sur un ordinateur), mais vu le volume des données ce n'est peut-être pas vital.

---

Évidemment si la RAM est limitée, il va s'arrêter de l'utiliser et conserver les données en disque. Mais pour optimiser son cache il collecte des statistiques d'usage des données afin que les plus fréquemment requêtés soient maintenues le plus longtemps possible en cache au détriment des données les moins utilisées (algorithme LLRU)

Citation:

---

D'après votre guide sur le SQL:

Justement, pour le classement des joueurs j'utilise une structure de donnée spéciale en mémoire (arbre rouge-noir qui associe score / utilisateur modifié pour pouvoir déterminer le classement de tel noeud en O(log(n)), toutes les opérations restant en O(log(n)), et obtenir le classement de x à x+k se fait en O(log(n) + k) ), et donc je voulais savoir si SQL peut gérer ce type de structure (classement, ou ORDER BY) bien dans le temps (par exemple le serveur SQL conserverait l'ordre en mémoire après une première requête ORDERBY) ou est-ce que je devrais faire des aménagements...

---

Ce que je dis doit être nuancé par deux éléments :
1) il est inutile de trier systématiquement lorsque cela n'est pas nécessaire. C'est juste du bon sens, mais les développeurs oublient trop souvent le bon sens !
2) si l'on a besoin d'un tri systématique de certaines données, alors il existe pour cela des index qui sont justement représentées en interne par le SGBDR par des arbres équilibrés dont la particularité est de fournir un temps de réponse linéaire quelque soit la donnée à retrouver et quelque soit le volume des données. Vous ne pourrez jamais faire plus rapide avec une technique interne....
Lisez par exemple cet article : http://sqlpro.developpez.com/optimisation/indexation/
Il vous montrera comment partant d'une table contenant 12500000 lignes et d'un temps de réponse dégueulasse sur une requête basique, on arrive à un temps de réponse non mesurable simplement par le pose du bon index !

A +

Ok merci, désolé pour le dérangement et toutes les questions et pour n'avoir pas été clair sur certains points.

Si j'ai bien compris pour mon problème de classement, je crée un index sur le score de chaque joueur (de toute façon la table des scores n'aura pas beaucoup de champs), et je fait ensuite un select id, score order by score limit 250, 49. (pour les gens classés 250 à 299)

J'ai aussi pu sembler donner trop d'envergure à mon programme, car même si 500 utilisateurs sont connectés en même temps c'est dans une même "Room" (comme pour un chat IRC, ou même un programme d'échecs en lignes où on peut voir tous les utilisateurs et la liste des matchs en cours), chaque déconnexion / connexion est immédiatement signalée à tous les autres joueurs et le serveur gardera certaines données en mémoires comme les utilisateurs déjà connectés etc. et donc il n'y a en tout cas qu'un seul utilisateur à la base de données, qui est le serveur lui-même. Quand je parlais de modifier plusieurs utilisateurs, ou les scores des utilisateurs, c'est le serveur du programme qui le fait, et donc le serveur SQL ne verrait qu'un seul utilisateur, ou alors est-il préférable de multithreader mon serveur pour faire plusieurs requêtes au serveur SQL simultanément... ? De même les gens qui font des serveurs peuvent être des utilisateurs non-avertis du tout (genre gosse de 14 ans sur son ordi) qui veulent juste que ça marche en lançant le .exe... (Bien sûr dans ce cas ils ne sont pas aussi organisés et ne traitent pas le même volume d'utilisateurs, compter moins de 100 joueurs connectés simultanément) C'est pour ça que j'hésite à installer PostGreSQL si la procédure est compilquée (par exemple SQLLite est juste une DLL à rajouter au programme), enfin demander aux utilisateurs d'installer un autre programme n'est pas si compliqué que ça...

Bref, merci pour tous ces conseils et ces pistes, je vais maintenant essayer ces diverses choses et faire des tests / tests de vitesses pour voir de quoi j'ai besoin :)

voilà le lien d'une part du problème sur le forum d'origine en question, si ça vous intéresse... ou pas. En tout cas le problème est résolu. Merci.

Citation:

---

Envoyé par coyotte507

J'ai aussi pu sembler donner trop d'envergure à mon programme, car même si 500 utilisateurs sont connectés en même temps c'est dans une même "Room" (comme pour un chat IRC, ou même un programme d'échecs en lignes où on peut voir tous les utilisateurs et la liste des matchs en cours), chaque déconnexion / connexion est immédiatement signalée à tous les autres joueurs et le serveur gardera certaines données en mémoires comme les utilisateurs déjà connectés etc. et donc il n'y a en tout cas qu'un seul utilisateur à la base de données, qui est le serveur lui-même. Quand je parlais de modifier plusieurs utilisateurs, ou les scores des utilisateurs, c'est le serveur du programme qui le fait, et donc le serveur SQL ne verrait qu'un seul utilisateur, ou alors est-il préférable de multithreader mon serveur pour faire plusieurs requêtes au serveur SQL simultanément... ?

---

Un SGBDR C/S incorpore son propre OS qui est responsable de la ram des disque et des threads. Il est donc nativement conçu pour multithreader l'ensemble des utilisateurs qui lancent simultanément des requêtes.

Citation:

---

De même les gens qui font des serveurs peuvent être des utilisateurs non-avertis du tout (genre gosse de 14 ans sur son ordi) qui veulent juste que ça marche en lançant le .exe... (Bien sûr dans ce cas ils ne sont pas aussi organisés et ne traitent pas le même volume d'utilisateurs, compter moins de 100 joueurs connectés simultanément) C'est pour ça que j'hésite à installer PostGreSQL si la procédure est compilquée (par exemple SQLLite est juste une DLL à rajouter au programme), enfin demander aux utilisateurs d'installer un autre programme n'est pas si compliqué que ça...

---

Non, le serveur SQL reste chez vous et c'est à travers le serveur web, distant lui aussi que les requêtes sont exécutées. Le serveur WEB ne montrant que le résultat des requêtes.

A +

Juste une petite précision:

Tous les serveurs sont indépendants , il ne partagent pas de base de données, et le serveur n'a aucune relation avec un site web. Toutes les bases de données sont donc locales, et uniques par serveur. Et, si je ne thread pas mon programme de serveur, il n'y aura aucun accès concurrent.

Voilà comment je crée la tables des joueurs:

Sous SQLite

Code:

---

create table if not exists trainers (id integer primary key, name varchar(20) unique, laston char(10), auth int, banned boolean, salt varchar(7), hash varchar(32), ip varchar(39)));

---

Sous PostGreSQL

Code:

---

create table trainers (id serial, name varchar(20), laston char(10), auth int, banned boolean, salt varchar(7), hash varchar(32), ip varchar(39), primary key(id), unique(name))

---

Pour les index

Code:

---

create index tname_index on trainers (name)

---

Code:

---

create index tip_index on trainers (ip)

---

Déjà j'apprécie moyen la différence de syntaxe à adopter dans les deux cas pour que le champ de la clé primaire s'incrémente automatiquement, enfin bon ^^

Donc j'ai un fichier de 15000 utilisateurs pour les tests (d'ailleurs maintenant le nombre de personne connectées à mon programme serveur sur leur programme client est souvent au dessus de 200, et monté à 280)

Avec mon système, je lit le fichier et insère le tout dans mes structures en mémoire quasiment instantanément.

Quand j'insère dans les bases de données ça prend plus de temps...

Pour info tous les traitements nécessaires à l'insertion dans la base de données, boucle comprise et requête, mais en étant déconnecté de la base de données, prennent 0.06 secondes. Les temps observés sont donc seulement dû à la base de données ou à la liaison avec la base de données, pas à mon programme.

Avec SQLite:

Code:

---

1 2 3 4

Insertion mémoire -> base de données   Sans les index: 163 secondes Avec les index: 230 secondes

---

Avec PostGreSQL:

Code:

---

1 2 3 4

Insertion mémoire -> base de données   Sans les index: 7.4 secondes Avec les index: 8.2 secondes

---

PostGreSQL remporte donc haut la main le concours ^^

C'est moins rapide que mon système (<1 seconde), mais ça convient. De plus, si je threade mon serveur pour avoir les appels à la base de donnée séparés du thread principal (et éviter les latences, qui bloqueraient l'ensemble du serveur pendant ce laps de temps), alors j'aurais un système qui marche impeccablement.

Enfin si j'avais utilisé la fonctionnalité batch du driver de PostGreSQL pour faire une insertion en masse j'aurais peut être été encore plus rapide.

Je prévois quand même de laisser SQLite par défaut pour les gens qui créent leur serveur sur leur ordinateur personnel et n'y connaissent rien.

Aussi, dans PGAdmin lorsque je veux regarder ma table fraîchment créee il me parle de faire un "VACUUM", je vais regarder ce que c'est. Il me laisse quand même regarder la table.

En tout cas merci beaucoup pour vos conseils, j'ai abouti à un système dont je suis pleinement satisfait :)

Merci encore

@+

Citation:

---

Envoyé par coyotte507

Et, si je ne thread pas mon programme de serveur, il n'y aura aucun accès concurrent.

---

C'est un peu hors sujet, mais un serveur non threadé ça me semble fort peu probable, du moins peu courant. Je vous conseille de vous renseigner sur ce point, soit c'est threadé et vous ne le savez pas (si vous êtes sur un serveur d'application), soit un jour vous aurez des performances médiocres et du lag.

Désolé, je suis renseigné sur ce point, c'est moi qui ait créé le programme à partir de rien :mrgreen:. Après tout, c'est mon jeu.

Le serveur n'est pas threadé pour tous les évènement logins / messages / lancer un défi etc. parceque le traitement est quasiment instantané, et encore plus vu que j'ai ma base de donnée en mémoire (ce qui va bientôt changer). Bien sûr tous les flux réseaux sont lancés dans des connexions non bloquantes. Et les combats sont chacun dans un thread, aussi.

Citation:

---

Envoyé par coyotte507

C'est moins rapide que mon système (<1 seconde)

---

Une base de données, ça se configure, ça s'optimise ;)

Je vais profiter de ce post pour faire un up. :)

En utilisant une transaction , SQLite est en dessous de la seconde et postgresql entre 3 et 4 seconde (donc SQLite est plus rapide)

Sinon, rien ne peut être plus rapide que d'avoir directement tout en RAM et de ne pas avoir à communiquer avec une base de donnée SQL pour récupérer les données. Mais là, les résultat sont déjà bien mieux. Les select * sur toutes la base sont de même rapides (je vous rassure, ils n'arrivent pas en temps normal), aucun souci.

Pour UNE transaction peut être, mais sur un serveur de jeu tu aura généralement plusieurs transactions simultanées, et la tu va souffrir si tu prend SQLITE, c'est pas vraiment conçu pour la concurrence ;)

Essais MySQL si non, c'est un bon équilibre (plus rapide que Postgresql, mais pas aussi complet, tout en supportant aussi bien la chargé que Postgresql voir même plus avec la version 5.4 (qui est je crois encore en beta))

Je supporte les 3 moteurs (SQLite, MySQL, PostGreSQL).

Finalement j'ai décidé de n'avoir que 4 thread pour charger des données et 2 pour en insérer. Et en plus l'exécution du serveur aura toujours lieu de manière normale, car tout est asynchrone : seuls l'utilisateur qui se logge / change de nom ou équipe / veut regarder les classements etc. aura un temps d'attente (celui de la requête) qui sera quand même très faible, 10 requêtes par secondes est un cas vraiment extrême dans l'état actuel des choses amha (vu que je cache pas mal de choses, en plus). Les insertions sont aussi faites de manière asynchrone, pas de problèmes de ce côté là non plus. C-a-d, une insertion ne ralentira jamais le thread principal.

De plus j'ai un système qui me permet d'exporter ma base de données (sous l'ancien format texte, sans les espaces superflus) et donc moyennant un redémarrage du serveur (juste du programme) je peux changer de SGBD, donc pas de problèmes non plus si jamais j'ai envie de changer.

Autrement, merci pour ton comparatif :)