Le moteur de requête interactif DiNoDB

À un niveau élevé (voir la figure A.3), le moteur de requêtes interactif DiNoDB se com- pose d’un ensemble de noeuds db, orchestrés à l’aide d’un cadre de traitement parallèle massivement (MPP). Dans notre implémentation de prototype, nous utilisons le frame- work MPD de Stado [14], qui intègre bien les moteurs de base de données PostgreSQL. DiNoDB assure la localisation des données en co-localisant DiNoDB nœuds avec DataN- odes HDFS. Dans ce qui suit, nous décrivons d’abord le client DiNoDB et les nœuds DiNoDB.

106 APPENDIX A. SUMMARY IN FRENCH

...

...

...

Figure A.3 – Architecture du moteur de requêtes interactif DiNoDB.

A.2.5.1 Clients DiNoDB

Un client DiNoDB sert de point d’entrée pour les requêtes interactives DiNoDB. Il fournit une interface de commande shell standard, cachant la disposition du réseau et l’architecture du système distribué à partir des utilisateurs. En tant que tel, les applica- tions peuvent utiliser DiNoDB comme un SGBD traditionnel.

DiNoDB clients acceptent les requêtes d’application (requêtes) et communiquent avec les nœuds DiNoDB. Lorsqu’un client DiNoDB reçoit une requête, il récupère les méta- données pour les “tables” (fichiers de sortie de la phase de lot) indiqués dans la requête en utilisant le moduleMetaConnector. Le MetaConnector (voir la figure A.3) fonctionne comme un proxy entre DiNoDB et le NameNode HDFS et est responsable de la récupéra- tion des informations de métadonnées HDFS comme des partitions et des emplacements de blocs de fichiers de données brutes. En utilisant les métadonnées HDFS, MetaCon- nector guide les clients DiNoDB pour interroger les nœuds DiNoDB qui contiennent des fichiers de données brutes en rapport avec les requêtes des utilisateurs. En outre, Meta- Connector configure à distance les nœuds DiNoDB afin qu’ils puissent créer le mappage entre les “tables” et les blocs HDFS connexes, y compris tous les blocs de fichiers de don- nées et blocs de métadonnées, par exemple, les blocs de positional maps et les blocs de

A.2. DINODB: UN MOTEUR DE REQUÊTE À VITESSE INTERACTIVE POUR

LES DONNÉES TEMPORAIRES 107

vertical indexes. En résumé, l’anatomie d’une exécution de requête est la suivante: i) en utilisant MetaConnector, un client DiNoDB apprend l’emplacement de chaque bloc de fichier brut et pousse la requête aux noeuds DiNoDB respectifs; ii) les nœuds DiNoDB traitent la requête en parallèle; et enfin, iii) le client DiNoDB agrège le résultat.

A.2.5.2 Nœuds DiNoDB

Les noeuds DiNoDB sont basés sur PostgresRaw [41], un moteur de requête optimisé pour les requêtes in situ. Nœuds DiNoDB instancent des bases de données personnal- isées PostgresRaw qui exécutent des requêtes d’utilisateurs, et sont localisés avec des DataNodes HDFS. Dans la mise en œuvre de la vanilla PostgresRaw [41], une “ table ” correspond à un seul fichier de données. Étant donné que les fichiers HDFS sont di- visés en plusieurs blocs, les nœuds DiNoDB utilisent un nouveau mécanisme de lecture de fichiers qui peut accéder à des données sur HDFS et mappe une “ table ” à une liste de blocs de fichiers de données. En outre, l’implémentation vanilla PostgresRaw est un serveur à processus multiples, qui forge un nouveau processus pour chaque nouvelle ses- sion client, avec des métadonnées individuelles et un cache de données par processus. Au lieu de cela, nœuds DiNoDB place les métadonnées et les données dansshared mem- ory, de sorte que les requêtes des utilisateurs - qui sont envoyées via le client DiNoDB- peuvent en bénéficier dans plusieurs sessions.

Nœuds DiNoDB peut profiter du fait que les données sont naturellement partitionnées en blocs HDFS pour tirer parti des processeurs multi-core modernes. Par conséquent, les données et les métadonnées associées peuvent être facilement accessibles par plusieurs instances de PostgresRaw, pour permettre le parallélisme au niveau des nœuds. Les utilisateurs DiNoDB peuvent indiquer sélectivement si les fichiers de données brutes sont placés sur le disque ou en mémoire. Par conséquent, les nœuds DiNoDB peuvent bénéficier de manière transparente d’un système de fichiers sauvegardé par mémoire pour améliorer considérablement les temps d’exécution des requêtes. Nœuds DiNoDB peut profiter du fait que les données sont naturellement partitionnées en blocs HDFS pour tirer parti des processeurs multi-core modernes. Par conséquent, les données et les métadonnées associées peuvent être facilement accessibles par plusieurs instances de PostgresRaw, pour permettre le parallélisme au niveau des nœuds. Les utilisateurs DiNoDB peuvent indiquer sélectivement si les fichiers de données brutes sont placés sur le disque ou en mémoire. Par conséquent, les nœuds DiNoDB peuvent bénéficier de manière transparente d’un système de fichiers sauvegardé par mémoire pour améliorer considérablement les temps d’exécution des requêtes.

108 APPENDIX A. SUMMARY IN FRENCH

A.2.6

Conclusion

Dans ce travail, nous avons présenté l’architecture de DiNoDB, un système distribué pour les requêtes de vitesse interactive sur les fichiers de données temporaires générés par des cadres de traitement par lots à grande échelle. Comme le montre notre évaluation expérimentale approfondie, pour les caisses d’utilisation DiNoDB- requêtes ad hoc sur une fenêtre de traitement étroite, notre système surpasse les solutions actuelles SQL- on-Hadoop. DiNoDB utilise un mécanisme de décorateur qui améliore Hadoop I/O API standard et permet de créer des métadonnées auxiliaires requises pour la performance des requêtes à vitesse interactive. De plus, DiNoDB I/O decorators s’intègre parfaitement aux cadres existants et aux systèmes de stockage distribués.

Notre évaluation expérimentale, que nous faisons à la fois sur les bases de données syn- thétiques et sur le monde réel, souligne les principaux avantages de DiNoDB dans un certain nombre de cas d’utilisation importants, ce qui le rend adapté à une large gamme de charges de travail analytiques ad hoc.