Procédé de gestion d`une base de données relationnelle de type

Printed by Jouve, 75001 PARIS (FR)
(19)
EP 2 234 022 A1
&
(11) EP 2 234 022 A1
(12) DEMANDE DE BREVET EUROPEEN
(43) Date de publication:
29.09.2010 Bulletin 2010/39
(21) Numéro de dépôt: 10157412.7
(22) Date de dépôt: 23.03.2010
(51) Int Cl.:
G06F 17/30
(2006.01)
(84) Etats contractants désignés:
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
(30) Priorité: 24.03.2009 FR 0951902
(71) Demandeur: Infovista SA
91940 Les Ulis (FR)
(72) Inventeurs:
• Adda, Serge
92160 Antony (FR)
• Chedru, Olivier
75015 Paris (FR)
(74) Mandataire: Pontet, Bernard
Pontet Allano & Associés
25, rue Jean Rostand
Parc Club Orsay Université
91893 Orsay Cedex (FR)
(54) Procédé de gestion d’une base de données relationnelle de type SQL
(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 sys-
tè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
(« Write Once Read Many ») gérées par le moteur de
stockage ; chaque table comprend une colonne de don-
nées de comptage numérique dite « timestamp » ; cha-
que table est partitionnée par intervalles de temps ; des
fichiers de partition sont regroupés dans des sous-réper-
toires 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
2
5
10
15
20
25
30
35
40
45
50
55
Description
[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 élimi-
nation 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,
-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 arbo-
rescence 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 :
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 :

EP 2 234 022 A1
3
5
10
15
20
25
30
35
40
45
50
55
[0013] 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 :
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.
[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 enregis-
trements 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

EP 2 234 022 A1
4
5
10
15
20
25
30
35
40
45
50
55
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’ corres-
pondent 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
[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.

EP 2 234 022 A1
5
5
10
15
20
25
30
35
40
45
50
55
[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 :
[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