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

Le , par Hinault Romaric, Responsable .NET
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de blbird blbird - Membre éclairé https://www.developpez.com
le 27/06/2012 à 15:15
J'avoue ne pas avoir très bien compris le concept. On est pas simplement dans un système de cache mémoire?
Avatar de grunk grunk - Modérateur https://www.developpez.com
le 27/06/2012 à 15:36
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 ?
Avatar de tomlev tomlev - Rédacteur/Modérateur https://www.developpez.com
le 27/06/2012 à 15:41
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...
Avatar de amezghal amezghal - Membre habitué https://www.developpez.com
le 27/06/2012 à 15:41
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.
Avatar de spyserver spyserver - Membre averti https://www.developpez.com
le 27/06/2012 à 15:56
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/
Avatar de Mr_Exal Mr_Exal - Membre expert https://www.developpez.com
le 27/06/2012 à 15:58
Citation Envoyé par tomlev  Voir le message
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.
Avatar de Farnsworse Farnsworse - Futur Membre du Club https://www.developpez.com
le 27/06/2012 à 16:00
Citation Envoyé par grunk  Voir le message
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...
Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 27/06/2012 à 16:05
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...
Avatar de joho joho - Membre habitué https://www.developpez.com
le 27/06/2012 à 16:44
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.
Avatar de rt15 rt15 - Membre confirmé https://www.developpez.com
le 27/06/2012 à 16:55
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.
Offres d'emploi IT
Chef projet big data - pse flotte H/F
Safran - Ile de France - Évry (91090)
Ingénieur H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Consultant sap finance/controlling H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil