Developpez.com - Algorithmique

Le Club des Développeurs et IT Pro

Les systèmes de JIT améliorent la performance des requêtes SQL complexes

Une extension de PostgreSQL intègre LLVM et diminue les temps de traitement

Le 2016-10-11 22:48:21, par dourouc05, Responsable Qt & Livres
Les systèmes de gestion de bases de données traitent des volumes de données de plus en plus gros, avec des requêtes de plus en plus complexes, notamment pour la prise de décision. Les problèmes de performance du modèle relationnel ne viennent plus seulement de l’accès aux données sur les disques durs ou SSD, mais également du processeur, qui doit effectuer les opérations complexes.

Chaque système optimise les requêtes SQL avant de les exécuter… et ces systèmes ont permis de garder un très bon niveau de performance jusqu’à présent. C’est d’ailleurs la raison pour laquelle SQL a pu s’imposer par rapport à des langages d’interrogation de plus bas niveau : ces requêtes peuvent s’exécuter plus vite que du code écrit spécifiquement pour chaque requête (à moins que chaque développeur passe énormément de temps à optimiser ce code). La requête est analysée, puis l’optimiseur détermine un plan d’exécution de la requête : comment itérer à travers les éléments d’une table, les filtrer, les agréger, mais surtout l’ordre de ces opérations.

Cependant, quand les accès au disque ne sont plus prépondérants dans les temps de réaction, repenser cette partie devient important. La situation actuelle revient à utiliser un interpréteur pour un langage de programmation avec des optimisations simples (comme Python). Les dernières expériences de la communauté LLVM (plus connue pour le compilateur C et C++ Clang) montrent que, en changeant de paradigme, on peut diminuer les temps d’exécution des requêtes les plus complexes d’un facteur cinq à sept (sur des tests synthétiques).

Pour ce faire, les développeurs ont utilisé des techniques similaires à celles utilisées pour les implémentations rapides de Python ou pour les machines virtuelles Java et .Net : la compilation juste à temps. Il s’agit donc de générer du code qui effectue la requête, puis de l’optimiser avec les mêmes techniques que les compilateurs C et C++, notamment : elles sont éprouvées et donnent d’excellents résultats sur n’importe quel type de programme.

L’extension développée pour PostgreSQL exploite une bonne partie du code d’exécution déjà développé. Ainsi, les fonctions de base d’accès à la base de données sont réutilisés (comme pour itérer dans une table), puis appelées depuis le code de la requête : le tout est passé au moteur de compilation juste à temps (JIT). Il inclut automatiquement le code des primitives de PostgreSQL dans celui de la requête, ce qui lui permet d’optimiser fortement le fonctionnement du code complet.

Ces premiers développements sont assez partiels, toutes les opérations ne sont pas accélérées de la sorte, mais les résultats actuels sont prometteurs. Le fonctionnement global est améliorable, puisque l’implémentation est loin d’être peaufinée. Notamment, la compilation peut s’effectuer de manière parallèle. Après ces étapes de nettoyage, cette extension pourra être distribuée au plus grand nombre sous une licence libre.


Source : Speeding up query execution in PostgreSQL using LLVM JIT compiler.
  Discussion forum
5 commentaires
  • TiranusKBX
    Expert confirmé
    Une approche intéressante, je demande à voir par la suite ce que ça donne
  • Max Lothaire
    Membre confirmé
    Avec quel type de requête a-t-on un gain significatif ?
    Est-ce que ça change quelque chose sur de très grosses bases de données ?
  • dourouc05
    Responsable Qt & Livres
    Dans http://llvm.org/devmtg/2016-09/slide...greSQLLLVM.pdf, pages 20 et 21, ils parlent de bons gains (facteur cinq en moyenne) sur des bases de données de 100 Go — ce qui n'est pas rien, mais pas vraiment énorme non plus… — sur à peu près toutes les requêtes TCP-H. Maintenant, tu ne peux t'attendre à de vrais gains que dans les cas où les accès au disque ne sont pas limitants (et ces tests sont relativement préliminaires, leur code semble loin d'être finalisé et utilisable en production).
  • SQLpro
    Rédacteur
    Cela fait déjà plusieurs années que la concurrence (Oracle ou SQL Server) est allé nettement plus loin en offrant notamment le In Memory et la compilation native en C des procédures et requêtes...

    A +
  • Dhafer1
    Membre habitué
    ça a l'ai très prometteur pour PostgreSQL, surtout pour un base Open-source et très abordable. Je pense qu'on peut dire que mySQL(et ses Fork) devrait être enterré maintenant.