Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

21PARTAGES

4  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de 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...
5  0 
Avatar de 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/
5  0 
Avatar de 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 ?
4  0 
Avatar de Aiekick
Membre extrêmement actif https://www.developpez.com
Le 28/06/2012 à 1:26
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
3  0 
Avatar de blbird
Membre expérimenté 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?
2  0 
Avatar de Waldar
Modérateur https://www.developpez.com
Le 27/06/2012 à 16:58
Une pâle copie d'une technologie qui a déjà plus de dix ans ?
http://www.oracle.com/technetwork/pr...iew/index.html
2  0 
Avatar de Klaim
Membre expert https://www.developpez.com
Le 28/06/2012 à 6:07
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.
2  0 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 28/06/2012 à 9:24
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..
2  0 
Avatar de StringBuilder
Expert éminent https://www.developpez.com
Le 03/07/2012 à 17:36
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.
2  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 06/07/2012 à 15:37
Faut vraiment arrêter l'inculture crasse des informaticiens !
TOUS LES SGBDR fonctionnent exclusivement en RAM. Seule la persistance des données est gérée au niveau disque.
1) par la journalisation des transactions (en mode synchrone), mais potentiellement peu de données et compressées
2) par l'écriture des données (en mode asynchrone), ce qui permet de les regrouper et d'éviter d'écrire de multiples versions intermédiaires

Il est même recommandé pour oracle ou SQL Server de limiter la RAM utilisable par le SGBDR sinon il bouffe toute la RAM disponible.

Pour PG, c'est l'inverse : il faut lui indiquer sa limite.

Bref, rien de nouveau, juste un truc mercatique avec en sus je vais plus vite mais vous aurez des chances de perdre vos données !

A +
2  0