Discussion :

[pascalCH]

Un SGBD fonctionnant "100%" en mémoire, ce n'est pas le premier, ni le dernier; en 1998, pour les besoins d'un logiciel de généalogie, j'en avais développé un de toutes pièces en c++, il a été porté en 32 puis 64 bits sous Windows et Mac, capable de s'adapter à la quantité de RAM disponible et de maintenir des statistiques sur l'utilisation potentielle des données; en fait, seules les données actives sont en mémoire, le reste est remisé sur disque, au bout du compte c'est un cache "intelligent" travaillant sur les contenus et non les fichiers disques, performant - 97% de hits réussis.
Ces solutions avec utilisation massive de mémoire sont pratiques quand l'application ne gère pas des terra octets de données, ce qui est très souvent le cas.

[SQLpro]

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 +

[Klaim]

Voilà ce que ça fait d'écrire un article qui ne pointe pas sur la vrai information du systeme...

Allez voir sur le site du projet, ils disent eux-même que le point fort c'est la compilation des requetes en C++, pas la persistence en mémoire. C'est de ça qu'on devrais discuter.

Toutes ces réactions sont à coté de la plaque.

[CinePhil]

le point fort c'est la compilation des requetes en C++.

Je ne suis pas un grand spécialiste du fonctionnement intime des SGBD mais il me semble qu'ils commencent par interpréter le bout de texte, appelé requête SQL, qu'on leur envoie et le triturent à leur sauce dans un langage ultra rapide (C ? C++ ? carrément Assembleur ?) pour exécuter la requête.
Autrement dit, et sauf erreur par ignorance de ma part, on peut dire en quelque sorte que tout SGBDR qui se respecte "compile" votre requête SQL.
Rien de nouveau là non plus !

De plus, dans un bon SGBD, Oracle par exemple, si vous soumettez exactement la même requête, des étapes de "compilation" - analyse syntaxique puis passage à l'optimiseur - seront sautées, ce qui rendra l'exécution de la requête plus rapide. Et je crois que si, en plus, les tables interrogées n'ont pas changé depuis la dernière soumission de la requête, le SGBD n'ira pas les rechercher sur le disque s'il les a encore en mémoire.

[Jester]

Les SGBD interprètent la requête souvent j'imagine ne passant par une structure mémoire (AST - abstract syntax tree pour un compilateur classique, j'imagine de même pour les SGBD, i.e. les plans d'exécutions). Je doute qu'ils compilent ensuite.

Dans le cas de MemSQL, ils doivent faire un hash de la requête en transformant les littéraux par des paramètres puis voir si ça a déjà été compilé. Dans le cas de MemSQL je doute que la translation de l'AST en code machine soit très utile. Il ne s'agit que d'appeler ensuite des primitives de haut niveau de toute façon.

Naturellement, ça n'a de sens que pour des requêtes qui s'exécutent vite. Si une requête de complexité classique met plus de 10ms à s'exécuter je pense qu'il n'y a plus d'intérêt à compiler.

La proposition de StringBuilder sur Linq est intéressante, en effet ce n'est plus du script donc il n'y a pas l'interprétation à faire. Sauf que j'imagine que pour le link à une base SQL, Linq regénère le SQL derrière. Dans tous les cas, Linq étant une techno sur le client, il faut bien communiquer avec le serveur.

[Klaim]

Je ne suis pas un grand spécialiste du fonctionnement intime des SGBD mais il me semble qu'ils commencent par interpréter le bout de texte, appelé requête SQL, qu'on leur envoie et le triturent à leur sauce dans un langage ultra rapide (C ? C++ ? carrément Assembleur ?) pour exécuter la requête.
Autrement dit, et sauf erreur par ignorance de ma part, on peut dire en quelque sorte que tout SGBDR qui se respecte "compile" votre requête SQL.
Rien de nouveau là non plus !

Je pense qu'il doit y avoir le même genre de rapport performance/flexibilité qu'il y a entre, par exemple, Lua et C++. Le même algorithme en C++ sera moins rapide en Lua (qui est tres proche de ce que tu décris, mais reste de l'interpreté, même sous forme de bytecode) mais beaucoup plus facile a manupuler au runtime.

Donc, en gros, je me dis que ça peut faire une différence, mais c'est vrai que c'est difficile de se rendre compte quoi exactement sans des tests concrets. En fait je trouve ça interessant justement parceque l'idée m'apparait saugrenue et en même temps "pourquoi pas?".

En tout cas eux ce qu'ils affirment, c'est que c'est la principale source des performances.

[StringBuilder]

En fait, le vrai seul intérêt du bignou, j'ai l'impression que c'est le remplacement systématique de littéraux par des variables.
Mais quand le programmeur n'est pas un goret, il utilise des requêtes paramétrées, et l'intérêt est alors caduque.

[Linunix]

C'est une SGBD à tester, elle m'a l'air extremement interessant