Procédé de gestion d`une base de données relationnelle de type
publicité
(19) & (11) EP 2 234 022 A1 DEMANDE DE BREVET EUROPEEN (12) (43) Date de publication: (51) Int Cl.: G06F 17/30 (2006.01) 29.09.2010 Bulletin 2010/39 (21) Numéro de dépôt: 10157412.7 (22) Date de dépôt: 23.03.2010 (84) Etats contractants désignés: (72) Inventeurs: AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR Etats d’extension désignés: AL BA ME RS • Adda, Serge 92160 Antony (FR) • Chedru, Olivier 75015 Paris (FR) (74) Mandataire: Pontet, Bernard (30) Priorité: 24.03.2009 FR 0951902 Pontet Allano & Associés 25, rue Jean Rostand Parc Club Orsay Université 91893 Orsay Cedex (FR) (71) Demandeur: Infovista SA 91940 Les Ulis (FR) (54) Procédé de gestion d’une base de données relationnelle de type SQL (« Write Once Read Many ») gérées par le moteur de stockage ; chaque table comprend une colonne de données de comptage numérique dite « timestamp » ; chaque table est partitionnée par intervalles de temps ; des fichiers de partition sont regroupés dans des sous-répertoires d’un système de fichiers, ces répertoires formant une arborescence dont chaque noeud est identifié de façon unique à partir d’un timestamp. EP 2 234 022 A1 (57) L’invention concerne un procédé de gestion d’une base de données relationnelle de type SQL pour des informations de service d’infrastructure informatique et réseaux ; dans lequel procédé on crée, dans un système de gestion de base de données de type MySQL, - un moteur de stockage de données en lecture seule, et - des tables non modifiables, par exemple de type WORM Printed by Jouve, 75001 PARIS (FR) EP 2 234 022 A1 Description 5 10 15 [0001] La présente invention se rapporte à un procédé de gestion d’une base de données relationnelle de type SQL pour des informations de service d’infrastructure informatique (serveurs, applications,...) et réseaux. [0002] La convergence technologique des services offerts par les operateurs de télécommunication a mis en évidence le besoin de nouveaux outils (Voix sur IP, SMS...) permettant de gérer la performance d’un grand nombre de transactions simultanées. De plus les réseaux actuels supportent des flux de plusieurs dizaines de Gigabits. Cela se traduit pour les outils de gestion de la performance et de la qualité de services (capture IP directe, Netflow monitoring, gestion de commutateurs logiciels) par des besoins de taux d’insertion très élevé dans des bases de données. [0003] La présente invention a pour but un système de gestion de base de données capable de gérer efficacement un flux important de données. En particulier on recherche un très haut taux d’insertion des données ainsi qu’une élimination des données anciennes au fil de l’eau. Un autre but de l’invention est une génération de rapports en temps réel. La présente invention a encore pour but une création d’index efficaces. [0004] On atteint au moins l’un des objectifs précités avec un procédé de gestion d’une base de données relationnelle de type SQL pour des informations de service d’infrastructure informatique et réseaux ; dans lequel procédé on crée, dans un système de gestion de base de données relationnelle de type MySQL par exemple, - 20 25 30 35 40 45 50 un moteur de stockage de données en lecture seule, et des tables non modifiables gérées par le moteur de stockage ; chaque table comprend une colonne de données de comptage numérique dite « timestamp » ; chaque table est partitionnée par intervalles de temps ; des fichiers de partition sont regroupés dans des sous-répertoires d’un système de fichiers, ces répertoires formant une arborescence dont chaque noeud est identifié de façon unique à partir d’un timestamp. [0005] Les tables selon l’invention sont non modifiables, c’est-à-dire qu’elles permettent l’écriture de données mais ne permettent pas la modification. On peut écrire une fois et lire autant de fois que souhaité sans jamais pouvoir physiquement altérer la donnée écrite. Les données anciennes peuvent cependant être effacées par le système pour laisser la place à des données plus récentes. On peut par exemple, de façon non limitative, utiliser la technologie dite pseudo-WORM (« Write Once Read Many » en anglais, une seule écriture pour de multiples lectures) où le système peut effacer les données anciennes sous certaines conditions. [0006] Avec le procédé selon l’invention, le moteur de stockage en lecture seule permet uniquement de prendre en charge l’insertion de données et non pas la mise à jour de données déjà présentes dans le système. On évite ainsi des fonctionnalités telles que les transactions, les mises à jours,... qui ralentissent le système car consommatrices en temps de calcul. On évite donc toute consommation de ressource inutile. Avantageusement, pour des données indexées, les indexes selon l’invention ne nécessitent aucune maintenance et ne sont jamais reconstruits. Ils peuvent donc être optimaux tant en temps d’accès qu’en place occupée sur le disque. [0007] Selon un mode réalisation avantageux de l’invention, on utilise la colonne dite « timestamp » pour fusionner des partitions entre elles en une nouvelle partition, et on définit un intervalle de temps pour cette nouvelle partition en fonction de l’âge des données contenues dedans. [0008] Afin de permettre notamment la fourniture de rapports en temps réels, les partitions peuvent d’abord être construites en mémoire puis écrites sur un disque, ces partitions en mémoire étant accessibles par des requêtes de type SQL. [0009] Selon une caractéristique de l’invention, chaque partition comporte un fichier de données et au moins un fichier d’index renfermant un arbre binaire parfait, et on utilise une fonction bijective dite TreeOrder pour générer ledit arbre binaire parfait et pour écrire séquentiellement des valeurs dudit arbre binaire parfait dans le fichier d’index en fonction d’une relation d’ordre existant entre les valeurs de l’arbre binaire parfait. [0010] La fonction bijective est avantageusement conçue de façon à faire la correspondance entre d’une part chaque noeud de l’arbre binaire parfait, ces noeuds étant numérotés de haut en bas et de gauche à droite, d’une autre part les valeurs de l’arbre binaire parfait lorsque stockées dans une section du fichier d’index. [0011] De préférence, la correspondance consiste à fournir la position de chaque noeud dans la section du fichier d’index en fonction de la position de la valeur correspondante dans une liste établie selon ladite relation d’ordre et en fonction de la cardinalité de cette même liste. [0012] Selon un mode de mise en oeuvre de l’invention, lorsque l’arbre binaire parfait est incomplet et présente une cardinalité égale à C, on classe les valeurs de cet arbre binaire parfait incomplet par rapport au plus petit arbre binaire parfait complet de cardinal N pouvant contenir C noeuds de la manière suivante : 55 partant d’une position TreeOrderN(i) dans l’arbre binaire parfait complet pour un i < C, avec i un index de cette table, on détermine une position TreeOrderC(i) dans l’arbre binaire parfait incomplet comme suit : 2 EP 2 234 022 A1 5 10 15 [0013] 20 - 25 Selon l’invention, chaque fichier d’index peut comporter : un en-tête, un arbre binaire parfait, une section de chaînes de caractères, et une section optionnelle pour des valeurs de l’index. [0014] En particulier, lorsque l’espace alloué à l’arbre binaire parfait dans le fichier de l’index est complètement utilisé par des valeurs, des valeurs supplémentaires sont alors stockées dans la section optionnelle. [0015] Par ailleurs, lorsqu’une table est destinée à contenir dans une colonne des données de type adresses IP, cette table contient en outre une colonne supplémentaire contenant des résultats de la résolution DNS desdites adresses IP, cette résolution étant réalisée lors de l’intégration desdites adresses IP au sein de la première colonne. Le moteur de stockage peut avantageusement comprendre un module faisant des résolutions DNS en parallèle. [0016] D’autres avantages et caractéristiques de l’invention apparaîtront à l’examen de la description détaillée d’un mode de mise en oeuvre nullement limitatif, et des dessins annexés, sur lesquels : 30 35 40 La figure 1 est une vue illustrant l’arborescence des partitions d’une table selon l’invention ; La figure 2 est un schéma simplifié illustrant un fichier de données et l’un des fichiers d’index associé ; La figure 3 est un schéma simplifié illustrant l’organigramme d’un arbre binaire parfait selon l’invention ; La figure 4 est un schéma simplifié illustrant la numérotation des noeuds de l’arbre binaire parfait de la figure 3 ; La figure 5 est un schéma simplifié illustrant une section de l’arbre binaire parfait de la figure 3 stockée dans le fichier d’index ; La figure 6 est une vue schématique d’un tableau représentant la correspondance opérée par la fonction bijective TreeOrder pour une liste de sept éléments ; La figure 7 est un schéma simplifié illustrant un organigramme d’un arbre binaire parfait incomplet avec douze noeuds numérotés dans l’ordre d’écriture ; La figure 8 est une vue schématique d’un tableau représentant la comparaison des positions entre un arbre binaire parfait complet de cardinal 15 et un arbre binaire parfait incomplet de cardinal 12 ; La figure 9 est une vue illustrant une définition d’une table d’IPDR ; et La figure 10 est une vue illustrant une fenêtre de configuration DNS de la table d’IPDR de la figure 9. 45 50 55 [0017] Le procédé selon la présente invention permet avantageusement de surveiller avec le protocole Netflow un lien d’une capacité de 10Gb avec un simple ordinateur de bureau. Un tel lien génère entre 1 et 3% de données Netflow, soit un trafic entre 100 et 300 Mb/s. En faisant l’hypothèse d’un trafic avec des conversions d’une dizaine de paquets, le nombre d’enregistrements Netflow peut être estimé sur un réseau conventionnel moyen à environ 100 000 enregistrements par seconde. [0018] Bien que l’invention n’y soit pas limitée, on va maintenant décrire le procédé selon l’invention mis en oeuvre dans un système de gestion de base de données MySQL 5.1. [0019] La présente invention s’applique avantageusement à des données relatives à des événements techniques. Ces données sont générées automatiquement avec un « timestamp » ou compteur numérique croissant et ne sont pas modifiées ultérieurement. [0020] Pour gérer efficacement les données, on utilise le partitionnement massif des tables contenues dans la base de données selon l’invention. Le partitionnement permet d’éliminer en un seul appel système des données correspondant à une période de temps. La méthode classique qui consiste à effacer les lignes d’une table est trop couteuse. Mais le 3 EP 2 234 022 A1 5 10 15 20 25 30 35 40 45 partitionnement reste avant tout un moyen de construire les indexes pour une période de temps, sans avoir à revenir par la suite sur une période déjà traitée. Cela permet de transformer un problème d’optimisation globale en un problème d’optimisation local, la localité étant une localité temporelle. [0021] Le partitionnement consiste à diviser une table SQL. Cette division est définie par des règles de segmentation appliquées à un sous-ensemble des valeurs des colonnes. MySQL 5.1 propose un partitionnement standard qui comporte trop de restrictions. En particulier la base doit être capable de lire toutes les partitions en même temps ; cela induit une contrainte forte pour le système d’exploitation sur le nombre de fichiers ouverts simultanément. Cette contrainte ne permet pas de mettre en oeuvre le partitionnement massif selon la présente invention. Ainsi, dans le cas de tables selon l’invention, une table a toujours une colonne ’timestamp’ et la table est partitionnée par intervalles de temps qui peuvent être de l’ordre de la minute ; la politique de rétention peut être de l’ordre d’une ou plusieurs années. [0022] Le partitionnement selon l’invention est géré par le moteur de stockage. Chaque partition possède ses index. Les partitions peuvent être parcourues en parallèle afin de diminuer le temps de réponse sur des systèmes multi-coeurs ou multiprocesseurs. [0023] Les fichiers de partition sont regroupés dans des sous-répertoires d’un système de fichier. Ces répertoires forment un arbre dont chaque noeud est identifié de façon unique à partir d’un timestamp comme indiqué par la figure 1. Cette figure montre l’arborescence des partitions pour la table ’ipp’. Les noms de fichier avec le suffixe ’.spd’ correspondent aux fichiers de données et ceux avec le suffixe ’.spi’ aux fichiers d’indexes. Les fichiers ’spi’ sont au nombre de 7 pour une partition car la table ’ipp’ possède 7 indexes. L’arborescence possède un nombre de niveaux qui dépend de l’intervalle de temps utilisé pour le partitionnement. [0024] La base de données selon l’invention comporte la possibilité de définir un intervalle de temps différent pour le partitionnement en fonction de l’âge des données. Par exemple, les données du mois en cours sont partitionnées à l’heure, puis les données des trois mois suivants sont partitionnées à la journée ; enfin les données plus anciennes sont partitionnées au mois. [0025] Le système a donc la possibilité de fusionner les partitions en partitions plus importantes au fur et à mesure que les données qu’elles contiennent vieillissent. Cette opération est faite en utilisant la colonne ’timestamp’. [0026] Par ailleurs, afin d’optimiser les insertions, on construit les partitions en mémoire avant de les écrire sur disque. Pour fournir un accès temps réel aux données, les requêtes SQL peuvent prendre en compte les données en mémoire avant qu’elles soient écrites sur le disque. Cette fonctionnalité bénéficie de la fusion de partition. Cette dernière permet de garder une taille de partition compatible avec la mémoire disponible pour la construction des partitions. [0027] Chaque partition est composée d’un fichier de données (« data file ») et d’un fichier pour chacun des indexes. La figure 2 décrit la structure d’un fichier d’index pour une partition. Un fichier d’index consiste en un en-tête (« header »), un arbre binaire (« binary tree »), une section de chaines de caractère (« String table »), ainsi qu’une section optionnelle pour les valeurs de l’index (« index values »). L’espace alloué à l’arbre binaire est limité ; si la limite n’est pas atteinte chaque noeud de l’arbre contient les valeurs d’index correspondant à une ligne de la table, sinon les valeurs de l’index sont stockées dans la section optionnelle à la fin du fichier. [0028] Les arbres binaires sont produits grâce une fonction bijective TreeOrder. Cette fonction permet de générer un arbre binaire parfait pour un index et de l’écrire séquentiellement dans un fichier. Un arbre binaire parfait permet d’éliminer la moitié des valeurs restantes à chaque fois que le parcours de l’arbre s’enfonce d’un niveau de profondeur supplémentaire. [0029] Soit (Vi),i ∈ [0,n], une liste de valeurs pour lesquelles il existe une relation d’ordre et soit O, une fonction telle que si O(i) > O(j) alors Vo(i) ≥ Vo(j). [0030] A titre d’exemple, pour une suite de 7 éléments: V0, V1, V2, V3, V4, V5, V6. [0031] Une fois triée selon une relation d’ordre, cette liste est la suivante : V2, V4, V1, V6, V3, V5, V0 50 55 [0032] Donc O(0) = 2, O(1) = 4, O(2) = 1, O(3) = 6, O(4)=3, O(5)=5 et O(6) = 0. Soit V’ la suite définie par V’i = Vo(i), alors la suite (V2, V4, V1, V6, V3, V5, V0) s’écrit aussi (V’0, V’1, V’2, V’3, V’4, V’5, V’6). [0033] L’arbre binaire parfait contenant tous les éléments de la liste (Vi) est décrit par la figure 3. En effet, soit v une valeur pour laquelle la fonction d’ordre est définie. Pour savoir si v est une valeur de la suite V, il suffit de comparer v et V’3. Si v < V’3 alors v doit être comparée à V’1. Si v < V’1, v est comparée V’0. Si v < V’0 alors v n’appartient pas la liste et cela a été trouvé en 3 itérations. Quand v est supérieur à la valeur du noeud, il suffit de comparer v au noeud enfant de droite. [0034] Si on numérote les noeuds de l’arbre de la figure 3 de haut en bas et de gauche à droite on obtient le résultat de la figure 4. 4 EP 2 234 022 A1 5 10 15 [0035] Il s’agit maintenant d’écrire les noeuds dans le fichier d’indexes. Or un fichier est un espace à une seule dimension. Les noeuds sont écrits les uns à la suite des autres en suivant leurs numérotations comme montré par la figure 5. [0036] TreeOrder fournit la position d’un noeud dans la section « arbre binaire » du fichier d’index en fonction du rang de la valeur associée à ce noeud dans la liste triée V’ et de la cardinalité de cette même liste. [0037] Sur la figure 6, on voit la correspondance établie par TreeOrder pour table de 7 éléments. [0038] La fonction TreeOrder étant bijective, il existe la fonction inverse TreeOrder-1 qui permet également de retrouver l’ordre dans la liste à partir de la position de l’enregistrement dans le fichier, ce qui est utile lors du parcours d’index. [0039] Si l’index ne comporte pas 2n-1 valeurs, l’arbre n’est pas complet et il faut modifier le comportement de la fonction TreeOrder pour tenir compte du fait que le dernier niveau de l’arbre comporte moins de feuilles qu’un arbre complet. [0040] Comme montré sur la figure 7 dans le cas d’un arbre incomplet, il faut supprimer une partie des feuilles. [0041] La figure 8 montre la correspondance entre l’index et la position pour un arbre incomplet. On voit que par rapport à l’arbre complet la transformation n’est pas triviale car c’est potentiellement l’ensemble des positions qui peut changer. [0042] Pour une cardinalité quelconque C on trouve la cardinalité de l’arbre complet le plus petit pouvant contenir C noeuds. Soit N = 2roundup(log2(C))-1. [0043] Partant de la position TreeOrderN(i) dans l’arbre complet pour un index i < C, on détermine la position TreeOrderC (i) dans l’arbre incomplet comme suit : 20 25 30 35 40 45 50 55 [0044] En complément notamment de ce qui précède, un des contextes d’utilisation du procédé selon l’invention est l’exploitation d’enregistrements de type « Internet Protocol Detail Record » (IPDR). Il s’agit des enregistrements décrivant l’utilisation de service IP. A ce titre, ces enregistrements comportent une ou plusieurs adresses IP. Ces adresses IP correspondent soit à l’entité qui consomme le service, soit à celle qui le fournit. Mais afin d’utiliser les IPDRs, il est utile de pouvoir résoudre ces adresses IP en noms plus significatifs. Cela se fait grâce au protocole DNS. Or, dans certains cas, si une identité a un nom qui reste inchangé au cours du temps, son adresse IP peut changer. C’est le cas par exemple dans les réseaux utilisant la technologie Dynamic Host Configuration Protocol (DHCP). Afin qu’un IPDR restent exploitable au cours du temps, on prévoit de stocker les adresses IP qu’il contient, mais aussi les noms qui résultent de la résolution de ces adresses au moment de la production de l’IPDR, car retarder la résolution au moment de l’exploitation de l’IPDR pourra conduire à un résultat différent et donc faux. [0045] La résolution DNS faite à l’insertion de l’IPDR dans la base procure d’autres avantages. En particulier, la résolution étant déjà faite, le temps d’interrogation des tables d’IPDRs est plus rapide quand des noms sont nécessaires. Pour ce faire, le système de gestion de base de données selon l’invention comporte un module logiciel capable de faire beaucoup de résolutions DNS en parallèle sans consommer trop de ressources système, car les services fournis par les systèmes d’exploitation ne sont pas conçus pour une telle utilisation. [0046] La présente invention offre donc la possibilité de configurer une table SQL en définissant une colonne comme contenant les résultats de la résolution DNS d’adresses IP contenues dans une autre colonne de la table. Une table peut contenir plusieurs de ces couples IP / Nom. [0047] De plus la configuration de la table permet de choisir une liste spécifique de serveurs DNS en fonction d’une valeur d’une colonne. La figure 10 montre un exemple de configuration. Le champ « DNS Identifier » indique quelle colonne contient la valeur, pour un enregistrement donné, qui permet de sélectionner le groupe de server DNS à interroger 5 EP 2 234 022 A1 5 10 pour faire la résolution. Avec l’exemple de la figure 9 où l’on définit une table d’IPDR, c’est la colonne serviceId qui est utilisée. Si le serviceId est 12, le groupe sera (10.1.13.12, 10.1.13.13), si le serviceId est 13, le groupe sera (10.1.13.14, 10.1.13.15). Pour tout autre valeur, le serveur DNS du système hébergeant la base de données selon l’invention sera interrogé (* :host=@default). Les serveurs dans un groupe sont interrogés à tour de rôle, de façon à lisser la charge sur l’ensemble du groupe et d’optimiser le temps de résolution. [0048] Bien sûr, l’invention n’est pas limitée aux exemples qui viennent d’être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l’invention. Revendications 1. Procédé de gestion d’une base de données relationnelle de type SQL pour des informations de service d’infrastructure informatique et réseaux ; dans lequel procédé on crée, dans un système de gestion de base de données relationnelle, 15 - un moteur de stockage de données en lecture seule, et - des tables non modifiables gérées par le moteur de stockage ; chaque table comprend une colonne de données de comptage numérique dite « timestamp » ; chaque table est partitionnée par intervalles de temps ; des fichiers de partition sont regroupés dans des sous-répertoires d’un système de fichiers, ces répertoires formant une arborescence dont chaque noeud est identifié de façon unique à partir d’un timestamp. 20 2. Procédé selon la revendication 1, caractérisé en ce qu’on utilise la colonne dite « timestamp » pour fusionner des partitions entre elles en une nouvelle partition, et on définit un intervalle de temps pour cette nouvelle partition en fonction de l’âge des données contenues dedans. 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que les partitions sont d’abord construites en mémoire puis écrites sur un disque, ces partitions en mémoire étant accessibles par des requêtes de type SQL. 4. Procédé selon l’une quelconque des revendications précédentes, caractérisé en ce que chaque partition comporte un fichier de données et au moins un fichier d’index renfermant un arbre binaire parfait, et on utilise une fonction bijective dite TreeOrder pour générer ledit arbre binaire parfait et pour écrire séquentiellement des valeurs dudit arbre binaire parfait dans le fichier d’index en fonction d’une relation d’ordre existant entre les valeurs de l’arbre binaire parfait. 35 5. Procédé selon la revendication 4, caractérisé en ce que la fonction bijective est conçue de façon à faire la correspondance entre d’une part chaque noeud de l’arbre binaire parfait, ces noeuds étant numérotés de haut en bas et de gauche à droite, d’une autre part les valeurs de l’arbre binaire parfait lorsque stockées dans une section du fichier d’index. 40 6. Procédé selon la revendication 5, caractérisé en ce que la correspondance consiste à fournir la position de chaque noeud dans la section du fichier d’index en fonction de la position de la valeur correspondante dans une liste établie selon ladite relation d’ordre et en fonction de la cardinalité de cette même liste. 7. Procédé selon la revendication 6, caractérisé en ce que lorsque l’arbre binaire parfait est incomplet et présente une cardinalité égale à C, on classe les valeurs de cet arbre binaire parfait incomplet par rapport au plus petit un arbre binaire parfait complet de cardinal N pouvant contenir C noeuds de la manière suivante : 25 30 45 50 partant d’une position TreeOrderN(i) dans l’arbre binaire parfait complet pour un i < C, avec i un index de cette table, on détermine une position TreeOrderC(i) dans l’arbre binaire parfait incomplet comme suit : 55 6 EP 2 234 022 A1 5 10 8. Procédé selon l’une quelconque des revendications 4 à 7, caractérisé en ce que chaque fichier d’index comporte : 15 - un en-tête, - un arbre binaire parfait, - une section de chaînes de caractères, et - une section optionnelle pour des valeurs de l’index. 20 9. Procédé selon la revendication 8, caractérisé en ce que lorsque l’espace alloué à l’arbre binaire parfait dans le fichier de l’index est complètement utilisé par des valeurs, des valeurs supplémentaires sont alors stockées dans la section optionnelle. 25 10. Procédé selon l’une quelconque des revendications précédentes, caractérisé en ce que lorsqu’une table est destinée à contenir dans une première colonne des données de type adresses IP, cette table contient en outre une seconde colonne contenant des résultats de la résolution DNS desdites adresses IP, cette résolution étant réalisée lors de l’intégration desdites adresses IP au sein de la première colonne. 30 11. Procédé selon la revendication 10, caractérisé en ce que le moteur de stockage comprend un module faisant des résolutions DNS en parallèle. 35 40 45 50 55 7 EP 2 234 022 A1 8 EP 2 234 022 A1 9 EP 2 234 022 A1 10 EP 2 234 022 A1 11 EP 2 234 022 A1 12 EP 2 234 022 A1 13 EP 2 234 022 A1 14
