4.2.1 Librairie
En mode librairie, Chronos gère une base de donnée unique associée à un fichier, qui peut être un périphérique d’entrée-sortie, comme une mémoire flash.
Connectors
Native C API, JDBC, ODBC, .NET, PHP, Perl, Python, Ruby, Cobol
Connection Pool
Authentification, Thread Reuse, Connection Limits, Check Memory, Caches
Management Services & Utilities
Backup & Recovery, Security, Replication,
Cluster, Administration,
Configuration, Migration & Metadata
Caches & Buffers
Global and Engine Specific Caches & Buffers
SQL Interface DML, DDL, Stored Procedures, Views, Triggers, etc. Parser Query Translation, Object Privilege Optimizer Acess Paths, Statistics
Files & Logs
Redo, Undo, Data, Index, Binary, Error, Query and Slow
File system
NTFS, ufs, ext2/3, NFS, SAN, NAS
Pluggable Storage Engines
Memory, Index & Storage Management
MySQL Server
MyISAM InnoDB Memory Merge Archive Federated Blackhole Partner Custom Community
Figure 4.3: Architecture globale de MySQL (Oracle, 2011b)
Le premier niveau de gestion de la base concerne les tables. Les opérations possibles sont la création, la suppression, l’ouverture et la fermeture. Chaque table est associée à une chaîne de caractère servant d’identifiant unique.
Après son ouverture, une table permet l’ouverture et la fermeture de curseurs. Ces curseurs peuvent ensuite être utilisés pour insérer, lire ou supprimer des paires clé-valeur, ou mettre à jour la valeur associée à une clé. La lecture permet de parcourir la table par valeurs de clés croissantes ou décroissantes.
4.2.2 Intégration à MySQL
4.2.2.1 Description des moteurs de stockage MySQL
MySQL est un système de gestion de base de données complexe. Bien que ce projet soit open-source, la lecture et l’analyse des centaines de milliers de lignes de codes qui le compose peuvent s’avérer délicates.
Les moteurs de stockage servent principalement d’intermédiaires entre l’optimiseur de re-quêtes de MySQL et le système de fichier (ou éventuellement un périphérique de stockage sans système de fichier). Chaque table de la base de données est associée à un moteur de stockage, instancié à sa création ou à son ouverture. MySQL effectue ensuite des opérations sur la table par l’intermédiaire de l’interface abstraite des moteurs de stockage. La figure 4.3 donne une vue d’ensemble de l’architecture de MySQL.
L’interface des moteurs de stockage définit en particulier des accès pour : • la gestion des tables : création, suppression, ouverture et fermeture ; • la gestion unitaire des tuples, pour :
– delete_row: supprimer un tuple de la table ; – update_row: mettre à jour un tuple de la table ;
• le parcours de la table (full table scan : initialisation et lecture du tuple suivant ; • la gestion des index, pour :
– index_read: récupérer un tuple grâce à une valeur de clé dans l’index ;
– index_read_last: récupérer le dernier tuple dans l’ordre spécifié par l’index, corres-pondant à une valeur de clé donnée (en particulier des préfixes d’index sur des colonnes multiples) ;
– index_first: récupérer le premier élément de l’index ; – index_last: récupérer le dernier élément de l’index ;
– index_next: récupérer le tuple suivant dans l’ordre spécifié par l’index ;
– index_next_same: récupérer le tuple suivant possédant la même valeur de clé ; – index_prev: récupérer le tuple précédent dans l’ordre spécifié par l’index ; • la gestion des transactions.
Le contexte d’historisation de données d’EDF n’imposant pas d’utiliser un moteur de sto-ckage transactionnel, les méthodes associées à cette dernière fonctionnalité ne sont pas dé-taillées.
La commande SQLHANDLERpermet de récupérer les données avec un accès direct aux in-terfaces des moteurs de stockage pour le parcours de la table et la lecture de l’index. Cette commande est décrite en annexe A.2 pour détailler les principes liés à ces accès.
Un moteur de stockage doit informer MySQL de ses fonctionnalités, et reporter des statis-tiques sur les données contenues dans ses tables pour que l’optimiseur puisse établir les plan d’exécution des requêtes le plus efficacement possible. Ces statistiques sont des valeurs approxi-matives pour :
• le nombre de tuples contenus dans la table
• le nombre de tuples contenus dans un intervalle (de clé) donné
• le nombre de blocs de données à lire pour une lecture complète de la table
• le nombre de blocs de données à lire pour lire n tuples à partir de m intervalles d’un index
Cette architecture permet de mutualiser la gestion des communications avec les clients, l’analyse syntaxique des requêtes (parsing), la génération du plan d’exécution, la réplication ainsi que la plupart des commandes d’administration (à l’exception de quelques opérations sur les tables : optimize, analyze, etc.). Les moteurs de stockage se chargent eux de la persistance des données, de la gestion de la concurrence, des transactions, des index et des buffers pour les opérations d’entrée-sortie avec le support de stockage. Cependant, la majorité de ces fonction-nalités sont optionnelles ; au niveau de l’implémentation, on peut obtenir un moteur de stockage minimaliste en surchargeant peu de fonction. Les moteurs de stockage example et blackhole sont des exemples de tels moteurs de stockage.
Blackholeest un moteur de stockage qui accepte des données en entrée sans les conserver. Les sélections retournent systématiquement un ensemble vide. Cette fonctionnalité peut être utile pour les bases de données distribuées où les données sont répliquées automatiquement (ce qui nécessite la définition d’une table) sans être stockées localement.
Exampleest un modèle de moteur de stockage ne faisant rien. Il permet la création de tables, mais aucune donnée ne peut être insérée ou extraite, le moteur refuse ces opérations. Celui-ci sert d’exemple (stub) pour le développement d’un nouveau moteur de stockage.
4.2.2.2 Interface avec MySQL
L’interface des moteurs de stockage est simplement une sur-couche à Chronos, permettant de traduire les appels MySQL. Cette interface est relativement proche des méthodes d’accès de Chronos. La seule différence notable concerne les insertions, pour lesquelles MySQL ne permet pas l’association de curseurs – ces opération sont effectuées de manière unitaire uniquement.
Le moteur de stockage doit donc gérer un ensemble de curseurs d’écriture, et identifier le curseur à utiliser pour chaque insertion. Dans le cas général, il est possible de retrouver le cur-seur à utiliser en les conservant triés par intervalle de validité. Cette opération possède alors une complexité en O(log k), avec k le nombre de curseurs ouverts.
Dans le cas de l’historisation de données, une structure de données plus adaptée permet de retrouver le curseur associé avec une complexité en O(1). En effet, pour les insertions de valeurs horodatées avec la date courante, il suffit de maintenir N curseurs, avec N correspondant au nombre de repères actifs, et de trouver le curseur correspondant à l’aide de l’identifiant du repère – ou, dans un cas plus général, un préfixe de clé. Retrouver le curseur à partir d’un identifiant est faisable en temps constant avec une table de hachage par exemple. Dans un cadre plus général, il n’est pas toujours possible d’extraire un préfixe – associé à un curseur – à partir de la clé à insérer.