MemSQL : un SGBD résidant en mémoire

[StringBuilder]

A partir du moment où :
- On doit conserver les données en mémoire
- Qu'on se moque de la persistance/intégrité des données

Utiliser un SGBD est une preuve d'incompréhension totale de l'outil qu'on a sous la main.

Si on veut travailler en mémoire avec des objets mémoire, on travaille pas avec un SGBD.

D'autant que LINQ de Microsoft permet déjà de "requêter" avec un langage "proche du SQL" des objets en mémoire, et que c'est extrêmement performant. Certainement bien plus que cette infâmie, qui nécessite un outil tierce au logiciel consommateur.

[Jester]

MemSQL me semble répondre correctement à une problématique simple. Beaucoup d'application webs sont basé sur MySQL avec MemCache par dessus. Les interfaces étant différentes ce n'était pas super pratique. Ils proposent de remplacer MemCache par MemSQL, voire le couple mySQL+MemCache par MemSQL.

On remarque que d'autres solutions "à la mode" comme MongoDB ont une durabilité équivalente à MemSQL.

Ce n'est probablement pas une solution à vos problématiques ou usages usuels de SGBD, mais ça peut servir pour d'autres personnes.

[StringBuilder]

Je persiste à dire que dans ces cas là, le choix d'un SGBD pour stocker les données étaient une erreur à l'origine.

Le SGBD peut éventuellement servir à stocker de façon persistante les données "après traitement", ou lors de "milestones", mais en aucun cas pour gérer les données en mémoire. A ce moment, il sera toujours performant et plus logique de tout charger en mémoire dans des objets et utiliser les algo adéquat pour les interroger.

[Jester]

Comme il est toujours plus performance de faire son propre SGBD spécifique à ses besoins.

Par exemple dans un cas de service web stateless, le serveur web ne peut stocker aucune donnée dans son espace d'adressage. Il faut bien stocker les données quelques part. MemSQL serait tout indiqué pour ces données, par exemple un panier d'achat en cours de constitution.

De même dans pas mal de cas perdre la dernière seconde d'enregistrement une fois par an n'est pas dramatique. En général dans les entreprises ils y a des erreurs opérationnelles de coût similaires plusieurs fois par an. Il faut l'éviter mais pas à n'importe quel coût.

[StringBuilder]

Je maintiens que pour les cas que tu donnes, utiliser un langage orienté objet, implémenter une sérialisation correcte (soit dans des fichiers, soit dans un SGBD), et requêter les objets en mémoire soit avec des algos "maison", soit avec LINQ ou équivalent, ça sera bien plus performant et maintenable que d'utiliser un SGBD mémoire.

[transgohan]

Mémoire dans des fichiers... Mais dites moi ? C'est pas justement pour s'affranchir de cette perte de temps d'accès qu'on part sur de la RAM ?
Désolé StringBuilder mais je ne suis pas du tout d'accord avec toi, pour ce que j'en conclue cela revient à redévelopper la roue et en moins bien.

Quand à LINQ que tu nous vends il serait bien intéressant de voir des benchmarks comparatifs sur d'énormes jeux de données justement... Car je ne suis absolument pas convaincu !

[Jester]

Juste pour qu'on soit sur la même problématique, je précise un peu de quoi je parle car j'ai du mal à voir en quoi c'est facile d'accéder à de la mémoire sur dans un processus différent sur un serveur distant de façon un peu safe avec plusieurs accès simultané.

J'entend une application web répartie sur des serveurs web front end et avec une base de données derrière (ou un cluster qu'importe).

On peu prendre une application de type Wooga décrite ici:

1,000,000 daily users and no cache (Splash 2011)

1,000,000 daily users and no cache (Splash 2011)

qui utilise in fine MySQL + Redis (très similaire à MemSQL).

On sent bien qu'avoir MemSQL dans ce cas aurait beaucoup de sens, histoire de ne pas avoir une interface type MySQL et une interface type Redi mais deux interface de type MySQL avec des implémentations différentes (basé fichier pour MySQL et mémoire pour MemSQL).

[StringBuilder]

Et que dire d'une application type MMORPG ?
Les temps de lantence sont bien plus faibles, et les volumes d'information je pense bien plus importants.
Pourtant, y'a pas la trace d'un MySQL derrière, et encore moins d'un memSQL.
Si tu veux de la performance, du massivement multi-threadé/multi-process/cluter, tu t'encombres pas avec un SGBD pour gérer des données PUREMENT MEMOIRE.

[StringBuilder]

Ensuite, tu me parles d'accès disques avec ce que je préconise...
Seulement, lorsqu'on sérialise un objet, on n'est pas obligé de le mettre à jour sur le disque comme un porc à chaque modification.

Habituellement, on va le faire lire sur le disque dans le constructeur de l'objet, et écrire dans le destructeur. Eventuellement, lors de modification de données sensibles, on va flusher manuellement sur le disque une modif, mais ce sera pas le cas la plupart du temps.

Ensuite, le problème d'un memSQL, c'est que si t'as une base de 100 Go, il faut 100 Go de mémoire.

Avec la sérialisation, si t'as 100 Go de données et que tu n'as besoin d'utiliser que 2 Go pour tes traitements, t'as besoin que de 2 Go de mémoire.

Pour un jeu, classiquement, tu vas travailler que sur les utilisateurs qui sont connectés, les autres n'ont rien à faire en mémoire.

Éventuellement, un démon va traiter les utilisateurs offline de temps à autres, mais à nouveau, il peut le faire de façon séquentielle, pas besoin de tous les charger en mémoire en même temps.

D'ailleurs, on préférera remplacer ce démon par un traitement "de rattrapage", qui s'occupera de faire toutes les modifications lors de l'initialisation de l'objet, dans la foulée de son chargement. Ça évite de saturer le système à mettre à jour des utilisateurs qui de toute façon ne viendront plus jamais jouer.

[Jester]

Envoyé par StringBuilder

Et que dire d'une application type MMORPG ?
Les temps de lantence sont bien plus faibles, et les volumes d'information je pense bien plus importants.
Pourtant, y'a pas la trace d'un MySQL derrière,

C'est que tu n'as pas bien regardéun premier indice ici Un MMORPG est stateful par contre donc il load sur un serveur de jeu, sauvegarde de temps en temps ou quand le client s'en va. Si le serveur de jeu crashe, bah les dernières modifs sont perdues. Cela reste des bases de données très chargées. Le stockage est souvent sous forme de blob.

Sur ton 2e post, j'avais bien précisé application stateless, donc la durée de vie de l'object en mémoire est une requête. A chaque requête, y compris Ajax, il faut retrouver les données et les sauvegarder à la fin du traitement si besoin. Chaque requête d'un même utilisateur peut être traité par un autre serveur web.

Clairement on est d'accord qu'avoir un MemSQL qui saurait aussi utiliser le disque pour des données froide serait la réelle solution. Mais au niveau des algo ça ne semble pas évident à merger disque/mémoire en étant ultra performant dans les deux.

[transgohan]

Je n'ai jamais dit qu'il fallait utiliser ce genre de SGBD pour faire du stockage de données permanent. Ce serait même une belle c*nnerie selon moi. Relis un peu mes interventions, je pense avoir énoncé clairement le contraire et ce dès le début.
En administration système on vous bourre le chou en insistant sur le fait que tous les SGBD sont là pour les données persistantes, mais certains outils ne sont clairement pas conçus pour cela et il serait bon de faire sortir des idées préconçues cela.
Après si cela vous gêne tant que cela, libre à vous de ne pas nommer MemSQL comme étant un SGBD.

[StringBuilder]

Mouais.

C'est un peu trop abstrait pour moi je pense.

En tout cas, j'en démord pas : pour les applications qui me viennent en tête, rien ne sera plus rapide qu'une interrogation directement d'objets plutôt que de tables chargées en mémoire.

D'autant que... juste pour rire... les SGBD sont de plus en plus masqués par des framework qui instancient les lignes des tables par des objets, et qui te font 200 000 requêtes là où une bête jointure ferait le travail correctement. Donc quand on travaille aussi mal (c'est le cas d'une large majorité des applications actuelles) le memSQL sera de toute façon plus lent qu'une application correctement réfléchie.

Bon, après, il y a toujours des exceptions. Mais une exception reste une exception, on ne peut en tirer une règle générale.

transgohan > c'est pas moi qui dit que c'est un SGBD, c'est l'outil qui en est un, c'est sa conception qui en fait un SGBD.

Pour moi, il y a deux intérêts à utiliser un SGBD plutôt que des objets en mémoire :
- Le clustering/multi-process, qui peut être natif chez le SGBD, et complexe à mettre en place quand c'est manuellement (point sur lequel insiste Jester)
- Le fait de pouvoir interroger les données en SQL (point sur lequel insiste la publicité de memSQL : et à ça, LINQ répond parfaitement, avec des performances forcément suppérieures, puisqu'il n'y a pas d'intermédiaire entre les données et le programme, contrairement à memSQL.

[transgohan]

Envoyé par StringBuilder

transgohan > c'est pas moi qui dit que c'est un SGBD, c'est l'outil qui en est un, c'est sa conception qui en fait un SGBD.

Evidement puisque c'en est un.
Ce que je reproche ce sont ceux qui disent que ce n'en est pas un car il n'est pas adapté pour gérer des données persistantes. La relation SGBD <=> données persistantes est une fausse idée.

[StringBuilder]

Ben disons que c'est quand même, normalement, fortement lié.
Je n'irai pas jusqu'à te contredire, mais je serait tenté de dire que ce n'est pas le terme SGBD qui est le plus adapté, mais plutôt un SGD (Système de Gestion de Données -tout court-).
Car il n'y a plus de concept de "base", qui, d'un point de vue sémantique, implique quand même un minimum de persistance...

[transgohan]

En fait l'abus de la terminologie (car tu as tout à fait raison dans le fond) vient de l'utilisation anglaise du terme. A savoir DBMS (DataBase Management System) qui ne peut se décliner en DMS qui veut dire tout autre chose (Document Management System qui est GED - Gestion Electronique des Documents - en français). Du coup les anglophones parlent aussi de DBMS pour cela. Et en français on traduit donc les deux de la même façon.

[dpincon]

Effectivement, c'est un début.
Si l'ACID est respecté, pas de soucis pour l'avenir.
Ce qui serait intéressant c'est d'en savoir plus sur les machines virtuelles.
Les sgbd/h/r/o/s (nosql inclus) sont, de fait, en mémoire.
Quid des performances ?

Damien Pinçon
http://about.me/damien.pincon

[StringBuilder]

Euh... C'est pas parce que la machine est virtualisée qu'elle est en mémoire. Il y a toujours des accès disques, et heureusement.

Sans compter que la plupart des SGBD ne supportent pas ou mal la virtualisation, donc attention !

[shenron666]

J'ose espérer qu'ils comparent leur SGBD avec une instance mySQL installée dans un ramdisk ou sur un ssd très performant
parce que si leur mySQL est installée sur un simple HDD standard en 7200, leur comparaison c'est bullshit

de plus, en cas de plantage de la machine, la base est perdue ?

[shenron666]

Envoyé par StringBuilder

Utiliser un SGBD est une preuve d'incompréhension totale de l'outil qu'on a sous la main.

Si on veut travailler en mémoire avec des objets mémoire, on travaille pas avec un SGBD.

à l'heure où le multiprocessing monte en flèche, les accès concurrents au même objet en mémoire est une problématique que l'on peut aborder de manière simple si on a un gestionnaire derrière, comme un SGBD

en résumé, gérer ses objects en mémoire à l'aide d'un SGBD permet de gérer des accès concurrentiels plus facilement avec une application multitaches

[StringBuilder]

Utiliser un SGBD pour gérer le multi-process en mémoire, c'est tout bêtement utiliser une moissonneuse batteuse pour tondre ta pelouse.

Non seulement c'est complètement démesuré comme solution, mais en plus le résultat sera bien en deçà de ce que tu aurais obtenu avec les outils adéquats.

Alors évidement, la tondeuse, faut la pousser, la démarrer à la main, et y'a pas la clim...