Discussion :

[Hinault Romaric]

MemSQL : un SGBD résidant en mémoire
30 fois plus rapide que les systèmes existants, développé par des anciens de Facebook

Deux anciens développeurs de Facebook ont créé un nouveau gestionnaire de bases de données qui serait, selon eux, le plus rapide du monde.

Baptisé MemSQL, le système s’appuie essentiellement sur le stockage des données en mémoire afin de réduire le temps de latence en évitant les lectures et écritures sur les disques durs. Cette caractéristique permet au SGBD, d’après ses créateurs, d’être 30 fois plus rapide que les SGBD standards.

Une vidéo de présentation a été publiée par ses auteurs, fournissant une démonstration des performances de MemSQL par rapport à MySQL. Alors que MySQL exécute 3 500 requêtes par seconde pour une séquence de requêtes, MemSQL en exécute environ 80 000 par seconde.

MemSQL s’affranchit de la lenteur d’un interpréteur SQL en transformant les requêtes SQL en code C++, qui est ensuite compilé dans un « squelette » ou tous les littéraux sont remplacés par des espaces réservés. Si la même requête est exécutée une seconde fois avec des paramètres différents, le serveur accède au modèle existant et remplace les espaces réservés par leurs valeurs réelles.

MemSQL est entièrement compatible avec MySQL, et peut être interrogé à partir des interfaces disponibles pour celui-ci. L’outil mysqldump peut également être utilisé pour exporter les données, et les importations se font par la lecture d’un fichier d’exportation.

L’édition développeur est disponible gratuitement en téléchargement pour Linux 64 bit, et le SGBD est décrit comme idéal pour les machines disposant d’un processeur multi-cœur et au moins 8 Go de RAM. L’outil manque encore pour l’instant des fonctionnalités comme les vues, les procédures stockées et les triggers.


Télécharger MemSQL


Source : MemSQL.com


Et vous ?

Que pensez-vous de MemSQL ? Et du concept de stockage en mémoire utilisé par le SGBD ?

[blbird]

J'avoue ne pas avoir très bien compris le concept. On est pas simplement dans un système de cache mémoire?

[grunk]

MemSQL s’affranchit de la lenteur d’un interpréteur SQL en transformant les requêtes SQL en code C++, qui est ensuite compilé dans un « squelette » ou tous les littéraux sont remplacés par des espaces réservés. Si la même requête est exécutée une seconde fois avec des paramètres différents, le serveur accède au modèle existant et remplace les espaces réservés par leurs valeurs réelles.

Ça ressemble quand même beaucoup aux requêtes préparées que l'on trouve sur à peut près tous les autres SGBD non ?

Une vidéo de présentation a été publiée par ses auteurs, fournissant une démonstration des performances de MemSQL par rapport à MySQL. Alors que MySQL exécute 3 500 requêtes par seconde pour une séquence de requêtes, MemSQL en exécute environ 80 000 par seconde.

Le test à donc été évidemment été effectué avec requête préparées et base MEMORY pour mysql ?

[tomlev]

Seul "petit" problème : quand on coupe le courant, on perd les données
Enfin, j'ose espérer qu'ils ont quand même prévu un système de persistance...

[amezghal]

mysql dispose d'un moteur de stockage MEMORY, ca serait bien de comparer les perfs avec. (surtout que memsql ne supporte pas les triggers ni procedures stockées).
l'avantage c'est que il compile les requêtes en code c++, et évite les phases lexing/parsing.

A tester en tout cas.

[spyserver]

Et voila l'article qui démonte cette techno qui se rélève au final pas encore mature, incapable d'être ACID et performante à la fois et surtout benchmarkée un peu n'importe comment, tout est dit ici : http://dom.as/2012/06/26/memsql-rage/

[Mr_Exal]

Seul "petit" problème : quand on coupe le courant, on perd les données
Enfin, j'ose espérer qu'ils ont quand même prévu un système de persistance...

Exactement ce que j'étais en train de me dire. Enfin, sauf s'ils ont prévu une sauvegarde automatique toutes les x minutes.

[Farnsworse]

Le test à donc été évidemment été effectué avec requête préparées et base MEMORY pour mysql ?

Pour l'enfoncer, j'imagine qu'ils utilisent InnoDB avec un "my-small.cnf"

Mais un "SGBD résidant en mémoire", c'est un peu un pléonasme vu qu'un programme tourne toujours en mémoire. C'est juste la BDD en tant que tel qu'on veux en mémoire afin de réduire la latence d'accès.
Et pour le stockage des "squelettes", ça semble être exactement la même chose que les requêtes préparées...

[Klaim]

l'avantage c'est que il compile les requêtes en code c++, et évite les phases lexing/parsing.

Oui c'est ce qu'ils disent dans la vidéo: c'est la génération de code C++ a partir de la requete SQL qui fait la vrai différence, même si evidemment garantir d'avoir "toute" (j'imagine que non) la BDD en mémoire vive joue aussi un role, avoir la requette executable en natifé optimisé au runtime c'est certainement sacrément efficace.

En revanche avec des BDD immenses ça doit pas mal saturé quand les manips de cache commencent a se faire...

Seul "petit" problème : quand on coupe le courant, on perd les données

Sur le site ils disent que les résultats des transactions sont bien enregistrées sur le disque une fois la transaction validée, donc non.

De ce que je comprends, il faut plutot voir la BDD en mémoire comme le reflet optimisé des données, pas comme une BDD seulement en mémoire.

Autrement dis, c'est un très gros cache optimisé par requete.


Pour la compilation de la requete, dans la vidéo on voit le résultat et effectivement c'est suffisament simple pour que ça compile très vite, surtout si leur systeme se base sur, par exemple, llvm/clang. Du coup je trouve que c'est pas mal interessant.

J'en ai pas besoin actuellement mais je note dans les alternatives a mysql...

[joho]

J'ai quelques interrogations tout de même.
(Attention, SGBD n'est pas ma matière favorite)


Comment garantir des transactions sans aucun Lock ?
Le buffer (ce qui est en RAM) fait 128 Mo. Si pendant que tu écris dans le buffer la machine crashe, tu as perdu au max 128 Mo !

Si tu utilises un autre "mode" de leur buffer qui écrit sur le disque toutes les 50ms. Tu perds l'avantage de l'écriture en RAM puisqu'en fait tu écris sur le disque tout le temps.

Pour les compilations des mêmes requêtes. Je ne suis pas sur de moi mais MS SQL fait ça déja (2 fois la même requêtes, la seconde va plus vite parce que MS SQL l'a gardé quelque part)


Enfin bref, à voir. Mais les annonces sont peut-être un peu trop "youpi c'est la fête ! "
ça marche sûrement dans le contexte Facebook, mais faut bien étudier les autres alternatives à mon avis.


Edit : tombé sur le même lien que skyserver : http://dom.as/2012/06/26/memsql-rage/ à lire.

[rt15]

D'après le lien de spyserver, il y a différent modes pour les transactions.
Dans un premier mode (par défaut), la transaction retourne "ok" avant l'écriture sur disque.
Dans un deuxième mode, la transaction retourne "ok" après l'écriture sur disque.

Dans tout les cas, l'écriture sur disque en elle même est réalisée... Par un thread en background toute les 50ms.

Dans le premier mode, on a pas vraiment des transactions : Si la bdd ou machine plante, on a pas les données sur le disque. Cela dit ça doit être rapide c'est sûr lol (Pas d'accès disque).
Dans le deuxième mode, la transaction est longue, très certainement largement plus longue qu'avec une bdd classique.

Bref, utilisée avec le premier mode, cette base n'est pas fiable, ou du moins pas du tout rigoureuse. Le deuxième mode est sans intérêt niveau perfs.

Dans le secteur banquaire, cette base ne vaudrait rien. Mais c'est sûr que comme précisé dans le blogs, pour stocker des commentaires publiés sur facebook, c'est tout à fait suffisant, lol. Si on en perd deux trois en cas de crash, c'est pas la mort.

Par contre, si elle est si rapide qu'elle le prétend elle aurait pu s'avérer intéressante pour faire passer des tests à un programme sur un poste de développeur par exemple (Hop, les junits dopés). Mais pour ça faudrait qu'elle supporte une bonne partie des fonctionnalités classique comme les vues et les procédures stockées... Ce qui n'est pas le cas.

Bref, à surveiller, mais pour le moment, poubelle.

[Waldar]

Une pâle copie d'une technologie qui a déjà plus de dix ans ?
http://www.oracle.com/technetwork/pr...iew/index.html

[y-ssir]

Si les données sont stockés en mémoire pour longtemps, on risque de perdre un grande volumétrie de données en cas de coupure de courant par exemple.
Il y a déjà des SGBD in Memory tel que HSQLDB.

[Aiekick]

Des BD Memory yen a beaucoup et forcément c'est très rapide genre : http://www.garret.ru/fastdb.html.

De la à dire que leur version est la plus rapide du monde...
Encore un coup de pub sans comparatif exhaustif avec un titre accrocheur

[Klaim]

Le problème c'est que l'argument de rapidité n'est pas lié, sur leur site, à la mémoire, mais à la génération de la requete en C++. L'article ici est trompeur parcequ'il met la mise en mémoire en avant alors que c'est bien cette requete générée qui est censé faire la différence. Il suffit d'aller sur le site, c'est le seul argument qu'ils donnent pour expliquer la différence entre leur BDD et d'autres.

Ca serait cool de voir des benchmarks oui.

[transgohan]

Pour ceux qui ne comprennent pas l'utilité d'un tel SGBD vous pourrez trouver des projets embarqués qui nécessitent du lourd traitement de données auquel le SQL se prête bien (exemple d'actualité : le data-mining des trains de la RATP).
De ce fait pour la rapidité et la taille il est souvent très intéressant d'utiliser ce genre de SGBD.
Ce n'est donc pas utilisé pour du stockage à long terme mais pour du calcul sur des jeux de données.

[_skip]

La comparaison faite avec mySQL ne pourrait vraiment être valide que si les settings étaient comparables ou tout au moins les chances de retrouver un état consistant en cas de panne soient égales (en gros que chaque transaction commitée soit 100% récupérable).

Et il semble, si on se fie à ce qui est avancé dans l'article qu'un autre membre a cité, qu'en fait, dès qu'on veut utiliser memSQL avec des settings qui assure la même sécurité de données en cas de crash que mySQL, on perd tout le gain.

Donc en fait, ce memSQL pourrait être intéressant si on veut privilégier la vitesse au détriment de la sécurité, c'est parfois acceptable sur certains jeux de données qui tournent très vite où l'on peut s'autoriser des pertes mineures en cas de problèmes.

Ainsi donc, il s'agirait plutôt d'un tradeoff mémoire-vitesse-ACIDité différent plutôt que d'une techno révolutionnaire. Enfin sauf peut être pour cette question de requête C++ mais cela m'étonnerait que les performances soient réellement limitées par ça dans la majorité des cas..

[hotcryx]

Toutes les données ne sont pas stockées en ram mais probablement certaines données pertinentes (ref data) et les requêtes compilées, index...

Ca me fait penser à la compilation LINQ.

[transgohan]

Toutes les données ne sont pas stockées en ram mais probablement certaines données pertinentes (ref data) et les requêtes compilées, index...

Ca me fait penser à la compilation LINQ.

Non non c'est bien en mémoire vive, sinon l'auteur aurait du mal à justifier les 8gio de mémoire vive nécessaire au fonctionnement.

[hotcryx]

donc les besoins en RAM augmente avec la taille de la db