[BOLDR] Au delà des frontières entre moteurs d'exécution langages de programmation et bases de données

par Julien Lopez

Projet de thèse en Informatique

Sous la direction de Véronique Benzaken.

Thèses en préparation à Paris Saclay , dans le cadre de Sciences et Technologies de l'Information et de la Communication , en partenariat avec LRI - Laboratoire de Recherche en Informatique (laboratoire) , VALS - Vérification d'Algorithmes, Langages et Systèmes (equipe de recherche) et de Université Paris-Sud (établissement de préparation de la thèse) depuis le 01-10-2015 .


  • Résumé

    Avec l'avènement du phénomène « BigData » ces dernières années, le volume et les formats des données disponibles n'ont cessé de croître. La manipulation de ces données (stockage, interrogation, échange, ...) se fait au moyen d'applications orientées données. La complexité de ces dernières n'a eu de cesse d'augmenter avec la sophistication des usages que nous faisons des données. Le code source d'une application orientée données typique est organisé de la manière suivante : * Une grande partie de l'application (logique de l'application, interface utilisateur, gestion du système, ...) est écrite dans un (ou plusieurs) langages de programmation. Outre les langages généralistes (tels que Java), on retrouve de plus en plus de langages dédiés à l'analyse de données (R en particulier mais aussi Python ou Ruby). * La partie dédiée aux données est souvent écrite dans un langage de requête (comme SQL) et s'évalue dans un « espace séparé » (le système de gestion de base de données ou SGBD, où résident physiquement les données). À cette dualité s'ajoute en plus le fait que les applications récentes n'utilisent pas qu'une source de données, dans un format unique (SQL) mais plusieurs (SQL, données semi structurées comme Json ou XML, bases de données de type column-store dites NoSQL, …). De cet état de fait, découlent deux problématiques principales dans le contexte BigData : * Deux mondes séparés : même en considérant un seul langage hôte et une seule base de données, ces derniers ont chacune leur propre environnement d'évaluation (ils s'exécutent d'ailleurs souvent sur des machines différentes). Le manque d'environnement partagé implique que, le langage de programmation utilise la base de données comme une boîte noire, lui fournissant des commandes sous forme textuelle et récupérant des données (toujours sous forme textuelle). L'impact négatif est ici double. Du point de vue de la sûreté, il est tout à fait possible de former des requêtes incorrectes dans le programme qui ne seront détectées qu'une fois envoyées à la base, lors de l'exécution (provoquant des interruptions pour cause d'erreur et au pire, une corruption des données). Il manque donc une manière d'analyser statiquement ces programmes hétérogènes dans leur totalité et non pas composantes par composantes. Du point de vue de l'efficacité ensuite, la moindre communication entre la base et le langage implique une traduction des données d'un format vers un autre, dramatique du point de vue des performances. Une fonctionnalité demandée depuis longtemps par les programmeurs et jamais encore implémentée de manière satisfaisante est celle des fonctions utilisateurs (user-defined functions ou UDFs), ou la possibilité d'appeler par exemple du code R ou Python depuis une requête SQL; * Pour chaque langage généraliste composant l'application et accédant à des données, il faut écrire un « pont » logiciel avec les bases de données correspondantes. Le nombre de combinaisons de langages X appelant une base Y étant relativement élevé, les développeurs optent pour des solutions sous-optimales (par exemple dupliquer les données dans plusieurs types de bases, réécrire le même code dans deux langages différents, ...). Dans le cadre d'un projet multi-partenaire entre le LRI de l'Université Paris-Sud, le laboratoire PPS de l'Université Paris Diderot et le laboratoire de recherche et développement d'Oracle Corporation, nous souhaitons attaquer frontalement ces problématiques en utilisant l'approche innovante suivante. * Définir un modèle de langage de requête abstrait, capable d'exprimer tous les langages de requêtes utilisés (SQL, langages de requêtes XML, ldots). Nous appelons QIR ce langage (Query Intermediate Language) * Utiliser ce QIR comme interface unique entre les langages hôtes et les bases de données * Proposer un environnement d'évaluation commun pour le QIR et la base de données, de manière à ce que la base et le langages partagent les mêmes ressources, ce qui ouvre la voie à des optimisations nouvelles, encore inexplorée. Le sujet de thèse s'insère dans l'axe de recherche (3) ci-dessus. Le but pour le doctorant sera principalement de concevoir l'environnement d'évaluation partagé, capable en particulier d'évaluer des UDFs d'un langage généraliste au coeur d'une base de données. Les travaux théoriques sur le QIR seront développés par d'autres membres du projet global que le/la doctorant(e), mais ses travaux seront précieux pour valider les choix faits dans la conception du QIR.

  • Titre traduit

    Breaking Boundaries between Language and Database Runtimes


  • Résumé

    With the advent of the "Big Data" phenomenon in recent years, volume and formats of available data never cease to grow. The handling of data (storage, query, exchange, ...) is done by data-oriented applications. Their complexity has continued to increase with the multiplicity of the uses we make of information. The source code of a typical data-oriented application is organized as follows : * A large part of the application (application logic, user interface, system management, ...) is written in one (or more) programming languages. In addition to the general languages (such as Java), there are more and more languages ​​dedicated to data analysis (R in particular but also Python or Ruby). * The part dedicated to data is often written in a query language (such as SQL) and evaluated in a "separate space" (the Database Management System or DBMS, where information physically reside). To this duality adds the fact that recent applications do not use only one data source in a single format (SQL) but several (SQL, semi-structured data such as Json or XML, column-store databases called NoSQL databases, ...). From this fact, two main issues arise in the context of BigData: * Two separate worlds even considering a single host language and a single database, they each have their own evaluation environment (they run also often on different machines). Lack of shared environment implies that the programming language uses the database as a black box, providing commands in text and retrieving data (in text as well). The negative impact here is twofold. From the point of view of safety, it is entirely possible to form incorrect queries in the program which will be detected only when sent to the database, during execution (causing interruptions due to errors or worse, to data corruption). It therefore lacks a way to statically analyze these disparate programs as a whole and not components by components. From the viewpoint of efficiency then the slightest communication between the database and the language implies a translation of data from one format to another, which is a disaster performance-wise. A feature long requested by programmers and never implemented in a satisfactory manner is the use of user functions (user-defined functions or UDFs) in queries, or the ability to call R or Python code from an SQL query; * For each general language that is part of an application and accessing data, a software "bridge" is necessary to link the language to the corresponding databases. The number of combinations of languages ​X calling a base Y being relatively high, developers are opting for sub-optimal solutions (i.e. duplicate data in several types of databases, rewrite the same code in two different languages, ...). As part of a multi-partner project between the LRI of the University Paris-Sud, PPS laboratory of the University Paris Diderot and the laboratory of research and development of Oracle Corporation, we wish to face these problems using the following innovative approach. * Define a query language of abstract model, able to express all used query languages ​​(SQL, XML query languages, ...). We call this language QIR (Query Intermediate Language) * Use this QIR as a single interface between the host languages and the databases * Propose a common evaluation environment for QIR and the database, so that the database and the languages share the same resources, paving the way for new, unexplored optimizations. The thesis fits into the line of research (3) above. The goal for the student will mainly be to design the shared evaluation environment, able in particular to evaluate UDFs from a general-purpose programming language inside a database. Theoretical work on the QIR will be developed by other members of the global project than the PhD student, but his/her work will be valuable to validate the choices made in the QIR design.