Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 3 sur 3 PremièrePremière 123
Affichage des résultats 41 à 48 sur 48
  1. #41
    Membre régulier
    Inscrit en
    juillet 2006
    Messages
    39
    Détails du profil
    Informations personnelles :
    Âge : 56

    Informations forums :
    Inscription : juillet 2006
    Messages : 39
    Points : 72
    Points
    72

    Par défaut Oui, et alors ?

    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.

  2. #42
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 464
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 464
    Points : 29 829
    Points
    29 829

    Par défaut

    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  3. #43
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 717
    Points : 3 334
    Points
    3 334

    Par défaut

    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.

  4. #44
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 819
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 819
    Points : 24 808
    Points
    24 808

    Par défaut

    Citation Envoyé par Klaim Voir le message
    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  5. #45
    Membre émérite Avatar de Jester
    Inscrit en
    septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : septembre 2003
    Messages : 813
    Points : 967
    Points
    967

    Par défaut

    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.

  6. #46
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 717
    Points : 3 334
    Points
    3 334

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    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.

  7. #47
    Expert Confirmé Avatar de StringBuilder
    Homme Profil pro Sylvain Devidal
    Chef de projets
    Inscrit en
    février 2010
    Messages
    1 903
    Détails du profil
    Informations personnelles :
    Nom : Homme Sylvain Devidal
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 1 903
    Points : 2 983
    Points
    2 983

    Par défaut

    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.

  8. #48
    Membre expérimenté

    Homme Profil pro Linunix Inception
    Etudiant
    Inscrit en
    juillet 2012
    Messages
    108
    Détails du profil
    Informations personnelles :
    Nom : Homme Linunix Inception
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Etudiant
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : juillet 2012
    Messages : 108
    Points : 548
    Points
    548

    Par défaut

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

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •