Dans l’ensemble, les progiciels d’historisation peuvent être caractérisés par : • un structure de schéma hiérarchique simple, basée sur les repères,
14. Par serveur et par an ; plusieurs offres commerciales sont définies, incluant des outils supplémentaires et dif-férentes options de support technique.
• une architecture centralisée,
• une intégration facilitée par le support de protocoles de communication industriels et une configuration originale adaptée,
• une conception optimisée pour l’archivage long-terme d’un grand volume de données ordonnées chronologiquement, où la date joue un rôle fondamental,
• des algorithmes de compression adaptés,
• une “interface NoSQL” pour les insertions, mais également pour la récupération des données de séries temporelles, éventuellement avec filtrage, ré-échantillonnage ou calcul d’agrégats,
• une interface SQL étendue, • pas de transactions,
• des applications intégrées spécialisées pour les données industrielles, • une politique tarifaire basée sur le nombre de repères,
2.3 Positionnement parmi les SGBD
2.3.1 Progiciels d’historisation et SGBDR
Les progiciels d’historisation sont principalement conçus pour acquérir des données de sé-ries temporelles : ils peuvent difficilement être utilisés pour des bases de données relationnelles. D’ailleurs, même si ils peuvent traiter des requêtes SQL, ils peuvent avoir des limitations avec leur optimiseur de requêtes et leur conformité avec la norme SQL dans son ensemble. Pour ces raisons, certains progiciels d’historisation peuvent être associés à un SGBDR. PI par exemple peut être lié à Microsoft SQL Server pour gérer des données suivant le modèle relationnel ; le modèle hiérarchique étant quant à lui plus proche de la structuration physique des installations. De nombreux SGBDR supportent les transactions, ce qui n’est pas le cas des progiciels d’his-torisation. Pour les SGBDR, ces transactions permettent en particulier de garantir la durabilité des données en cas de défaillance. Pour les progiciels d’historisation, plusieurs niveaux de cache distribués sur le réseau limitent les pertes de données, mais assurent également, de manière transparente, une certaine continuité de service.
2.3.2 Progiciels d’historisation et systèmes NoSQL
Les progiciels d’historisation fournissent une interface dédiée, différente du SQL, pour les insertions, mises à jour et récupération des données. Les insertions sont fonctionnellement com-parable aux requêtes SQL “INSERT”, avec des performances améliorées : ces procédures évitent l’analyse syntaxique et les conversions de types. L’interface de récupération des données cepen-dant diffère significativement du SQL. Les extractions peuvent être définies avec des conditions de filtrage (typiquement avec des seuils de valeur ou des vérifications du champ qualité), du ré-échantillonnage ou des calculs d’agrégats sur des intervalles temporels – par exemple pour cal-culer la moyenne horaire. Bien que les conditions de filtrage et la définition d’intervalles soient traduisibles simplement en SQL, l’interpolation de valeurs (avec divers algorithmes d’interpo-lation : par pallier, linéaire, etc.) peut être fastidieuse à définir, tant en SQL qu’avec des interfaces NoSQL usuelles, en particulier lorsque plusieurs séries temporelles – possédant leur propre pé-riode d’échantillonnage – sont concernées, comme pour le produit de deux séries par exemple. Néanmoins, les entrepôts de paires clé-valeur ordonnées fournissent des méthodes d’accès NoSQL proches, comme les curseurs de Berkeley DB [Olson et al., 1999]. Ces curseurs peuvent être positionnés sur une valeur de clé, et être incrémentés ou décrémentés suivant l’ordre des clés – pour récupérer les valeurs consécutives d’une série temporelle dans ce contexte.
Mal-gré tout, l’interface des progiciels d’historisation est spécialisée, et donc combine de nombreux algorithmes et traitements usuels adaptés aux besoins industriels, en plus de l’extraction de données brutes.
Les systèmes NoSQL sont généralement conçus pour être distribués sur de nombreux nœuds. Pour les progiciels d’historisation, cette extensibilité horizontale est séparée entre la réplication et la distribution. L’équilibrage de charge est fourni par la réplication, où plusieurs serveurs possèdent les même données, et sont individuellement capables d’exécuter des re-quêtes d’extraction. Cependant, cette architecture ne diminue pas la charge liée aux insertions : la distribution des données est obtenue déclarativement, en associant un repère à un serveur donné – qui peu à son tour être répliqué. En conséquence, les progiciels d’historisation four-nissent seulement un équilibrage de charge et une extensibilité limités par rapport à la majorité des systèmes NoSQL. Cependant, la récupération des données repose sur un interface efficace pour traiter les requêtes sur des intervalles (range queries). Typiquement, les entrepôts de paires clé-valeur basés sur les tables de hachage distribuées (DHT) ne sont pas adaptées, ce qui fait de l’extensibilité un problème complexe.
2.3.3 Progiciels d’historisation et DSMS
Les systèmes de gestion de flux de données (Data Stream Management Systems ou DSMS) fournissent des capacités de traitement de requêtes continues en étendant le langage SQL [Arasu
et al., 2003] ou par des extensions des SGBDR classiques, comme Oracle. Ces systèmes traitent typiquement les données sur une fenêtre temporelle relativement courte pour exécuter ces re-quêtes continues.
En ce qui concerne les insertions, les progiciels d’historisation possèdent des mécanismes similaires car ils associent leur buffer d’écriture à une fenêtre temporelle, rejetant ou insérant avec des performances dégradées les données hors de cet intervalle. Cependant, à EDF, les re-quêtes continues sont gérées par des systèmes de surveillance et de contrôle dédiés, avec des contraintes temps réel du fait de leur caractère critique ; tandis que le progiciel d’historisation se charge de l’archivage long terme.
Pourtant, une nouvelle génération de DSMS permet l’analyse à long terme de données his-toriques en entreposant les flux de données. Ces entrepôts de flux de données se focalisent toujours sur les requêtes continues, ce qui n’est pas l’objectif des progiciels d’historisation.
2.3.4 Synthèse
Les progiciels d’historisation sont des produits conçus et vendus pour un usage industriel spécifique. Les autres SGBD peuvent avoir des cadres d’application plus variés, pour un coût potentiellement moins important, mais n’incluent généralement pas la plupart des fonctionnali-tés métier que possèdent les progiciels d’historisation. Ces systèmes ne supportent typiquement pas les protocoles de communication industriels, ni la compression avec perte, l’interpolation ou le ré-échantillonnage.
En quelque sorte, les progiciels d’historisation sont des SGBD non relationnels – donc « NoSQL » – qui ont su s’imposer sur un marché de niche. Pour autant, ils ne correspondent à aucune des catégories de SGBD existantes :
• modèle hierarchique,
• pas de distribution des données, • pas de transactions,
Ces critères fonctionnels sont importants mais ne permettent pas d’avoir une idée quantita-tive sur les capacités de traitement de chaque système. Pour cela, nous avons défini un bench-mark pour avoir une base objective de comparaison.
2.4 Benchmark adapté à l’historisation de données
Les éditeurs des progiciels d’historisation ne publient pas les capacités de traitement de leurs solutions. L’utilisation d’un benchmark est donc le seul moyen d’évaluer les différences de performances entre ces systèmes. Cependant, cette comparaison ne s’avère pas si facile, les fonctionnalités, les interfaces et le modèle de données sous-jacents étant différents.
Pour cela, nous nous concentrons sur des opérations (requêtes) simples sur un schéma de base de données générique. Nous proposons donc un benchmark et l’utilisons pour évaluer un progiciel d’historisation, un entrepôt de paires clé-valeur ordonnées et un SGBDR, que nous avons optimisés pour ce cas d’utilisation.
Alors que de nombreux benchmarks existent pour les systèmes de gestion de base de don-nées relationnels, comme TPC-C ou TPC-H [Transaction Processing Performance Council, 2007, 2008], il n’en existe, à notre connaissance, pas pour les progiciels d’historisation. L’idée de com-parer ces systèmes à l’aide d’un benchmark existant – adapté aux SGBDR – est donc naturelle. Cependant, dans le contexte des applications d’historisation de données d’EDF, il ne nous a pas semblé possible de mettre en oeuvre un benchmark du Transaction Processing Performance Council (TPC) pour les raisons suivantes :
• Les progiciels d’historisation ne respectent pas nécessairement les contraintes ACID et ne permettent généralement pas les transactions.
• L’insertion est une opération primordiale pour les systèmes d’historisation. Cette opéra-tion est effectuée de manière continue, ce qui exclut d’utiliser des benchmarks insérant les données par groupements, comme TPC-H.
• Les progiciels d’historisation sont conçus pour traiter des séries temporelles. Il est né-cessaire que le benchmark manipule ce type de données pour que les résultats soient significatifs.
Les benchmarks pour les DSMS, comme Linear Road [Arasu et al., 2004] auraient aussi pu être envisagés ; mais les progiciels d’historisation ne supportant pas les requêtes continues, leurs mises en œuvre auraient été impossibles. Ces systèmes – et les SGBDR d’ailleurs – fonctionnent différemment en stockant les données pour répondre aux requêtes ultérieures. Dans les bench-marks des DSMS, même les requêtes sur l’historique utilisent un premier niveau d’agrégation sur les données brutes, ce qui n’est pas représentatif de l’utilisation des systèmes d’historisation à EDF.
Pour comparer les performances des progiciels d’historisation avec d’autres SGBD, nous dé-finissons un benchmark basé sur un scénario reprenant le fonctionnement de l’historisation des données des centrales nucléaires d’EDF. Dans ce contexte, les données sont issues de capteurs répartis sur le site d’exploitation et agrégées par un démon servant d’interface avec le système d’historisation. Pour les insertions, ce benchmark simule le fonctionnement de ce démon et gé-nère pseudo-aléatoirement les données à insérer.
Ces données sont alors accessibles par des applications ou utilisateurs distants, qui peuvent envoyer des requêtes pour mettre à jour, récupérer ou analyser ces données. Après la phase d’insertion, ce benchmark génère un ensemble simple mais représentatif de ce type de requêtes.
ana anavalues AnaId INT ←Ð AnaId INT
Label CHAR(40) Date TIMESTAMP CreationDate TIMESTAMP Value FLOAT DestructionDate TIMESTAMP Quality TINYINT Unit INT
Interval INT Threshold1 FLOAT Threshold2 FLOAT
bool boolvalues BoolId INT ←Ð BoolId INT
Label CHAR(40) Date TIMESTAMP CreationDate TIMESTAMP Value BOOLEAN DestructionDate TIMESTAMP Quality TINYINT Label0 CHAR(60)
Label1 CHAR(60)
Figure 2.1: Schéma logique de la base de données
2.4.1 Modèle de données
Ce benchmark manipule les données selon un schéma minimal, centré sur les données de séries temporelles. Pour chaque type de variable – analogique ou booléen – une table de descrip-tion est définie (resp.anaetbool). Les mesures sont stockées dans des tables différentes (resp.
anavaluesetboolvalues). La figure 2.1 présente le schéma logique utilisé pour ce benchmark. Chaque repère est associé à un identifiant (AnaId ou BoolId), une courte description – ou nom – (Label), une date de création (CreationDate) et une date de destruction (DestructionDate). Pour les données analogiques, la table de description contient également l’unité de la mesure (Unit), qui est normalement décrite dans une table distincte abandonnée pour ce benchmark, une période d’échantillonnage théorique (Interval) et deux seuils dé-limitant les valeurs critiques basses (Threshold1) ou hautes (Threshold2). Pour les valeurs booléennes, la table de description contient deux courtes descriptions associées à la valeur 0 (Label0) et 1 (Label1).
Les séries temporelles sont stockées dans les tablesanavaluesetboolvalues, qui contien-nent l’identifiant (AnaIdouBoolId), la date de la mesure avec une précision à la milliseconde (Date), la valeur (Value) et un tableau de huit bits pour les méta données – des informations sur la qualité – (Quality). Pour les tablesanavaluesetboolvalues,AnaIdetBoolIdsont des clés étrangères. On aanavalues[AnaId]⊆ana[AnaId] etboolvalues[BoolId]⊆bool[BoolId]. Pour que ce benchmark soit compatible avec les modèles de données hiérarchiques utilisés par les progiciels d’historisation, le modèle relationnel défini précédemment ne peut pas être imposé. Dans la figure 2.2, nous proposons un modèle hiérarchique équivalent, permettant de représenter les même données et d’exécuter des requêtes fonctionnellement équivalentes. La base de données définie précédemment utilise plusieurs types de données :
• INTcorrespond à un entier signé sur 32 bits.
• FLOATcorrespond à un nombre à virgule flottante sur 32 bits. • CHAR(N)correspond à une chaîne de n caractères.
ana AnaId Label CreationDate DestructionDate Unit Interval Threshold1 Threshold2 anavalues Date Value Quality bool BoolId Label CreationDate DestructionDate Label0 Label1 boolvalues Date Value Quality
Figure 2.2: Schéma logique équivalent pour le modèle hiérarchique des progiciels d’historisa-tion
• TIMESTAMPcorrespond à un horodatage avec une précision à la milliseconde sur un in-tervalle d’au moins trente ans.
• TINYINTcorrespond à un entier signé ou non signé sur 8 bits. • BOOLEANcorrespond à une valeur binaire sur 1 bit.
Les types présentés dans cette section donnent une précision minimale des données mani-pulées, la substitution d’un type par un autre plus précis est autorisée. Le schéma de la base peut également être adapté pour décomposer un type : un TIMESTAMP peut par exemple être divisé en deux valeurs, une date avec une précision à la seconde et un entier représentant les millisecondes. De plus, les dates ne requièrent pas de format spécifique. Il est par exemple pos-sible d’utiliser des entiers pour stocker ces informations.
2.4.2 Requêtes
Ce benchmark définit douze requêtes représentatives de l’usage d’EDF. Les paramètres de ces requêtes sont notés entre crochets. Ceux-ci doivent être les mêmes entre chaque exécution du benchmark, pour obtenir des données et des requêtes identiques.
Pour conserver une définition simple et faciliter l’analyse des performances, les interactions entre les requêtes ne sont pas prises en comptes : les requêtes sont exécutées une par une dans un ordre établi. En particulier, l’évaluation des performances malgré une charge continue en insertion n’est pas considérée, même si cela correspond à une situation plus réaliste. De même, les traitements spécifiques aux séries temporelles proposés par les progiciels d’historisation ne font pas partie des requêtes exécutées par le benchmark, car leur équivalent en SQL standard peut s’avérer compliqué à définir (par exemple pour calculer une moyenne pondérée par les intervalles temporels – variables – des mesures).
2.4.2.1 Insertion des données
L’insertion de données est une opération primordiale pour les systèmes d’historisation. Pour optimiser ces requêtes, l’interface et le langage ne sont pas imposés (ces requêtes peuvent être traduites du SQL en n’importe quel langage ou appel de fonction de l’API, quel que soit celui qui maximise les performances).
R0.1 Insertion de valeur analogique. ParamètresID,DATE,VALetQUALITY.
INSERT INTO anavalues VALUES
([ID],[DATE],[VAL],[QUALITY]);
R0.2 Insertion de valeur booléenne. ParamètresID,Date,VALetQUALITY.
INSERT INTO boolvalues VALUES
([ID],[DATE],[VAL],[QUALITY]);
2.4.2.2 Modification des données
Au contraire de l’insertion, les mises à jour, récupérations et analyses des données sont géné-ralement effectuées manuellement par les utilisateurs finaux ; les contraintes de performances sont plus flexibles.
Ce benchmark définit dix de ces requêtes pour évaluer les performances de chaque système, et identifier les optimisations spécifiques à certains types de requêtes. Les équivalents NoSQL doivent fournir les mêmes résultats. Nous proposons deux exemples, pour les requêtes R2.1 et R9, en utilisant une interface basée sur les curseurs, qui peuvent être positionnés sur une valeur de clé (position) et incrémentés (readnext).
La mise à jour de données est une opération rare pour les systèmes d’historisation. Le bench-mark considère cependant l’impact des mises à jour sur les performances. Les identifiants et les dates doivent correspondre à des données existantes.
R1.1 Mise à jour d’une valeur analogique et de son champ qualité. ParamètresVAL,IDetDATE.
UPDATE anavalues
SET Value = [VAL],
Quality = (Quality | 128)
WHERE AnaId = [ID]
AND Date = [DATE];
R1.2 Mise à jour d’une valeur booléenne et de son champ qualité. ParamètresVAL,IDetDATE.
UPDATE boolvalues
SET Value = [VAL],
Quality = (Quality | 128)
WHERE BoolId = [ID]
AND Date = [DATE];
2.4.2.3 Extraction de données brutes R2.1 Valeurs analogiques brutes. ParamètresID,STARTetEND.
SELECT *
FROM anavalues
WHERE AnaId = [ID]
AND Date BETWEEN [START] AND [END]
ORDER BY Date ASC;
Algorithme 2.1: Traitement NoSQL de R2.1
input : id, start, end
1 POSITION((id, start))
2 key, value ← READNEXT()
3 while key < (id, end) do
4 key, value ← READNEXT()
R2.2 Valeurs booléennes brutes. ParamètresID,STARTetEND.
SELECT *
FROM boolvalues
WHERE BoolId = [ID]
AND Date BETWEEN [START] AND [END]
ORDER BY Date ASC;
2.4.2.4 Calcul d’agrégats
R3.1 Quantité de données analogiques. ParamètresID,STARTetEND.
SELECT count(*)
FROM anavalues
WHERE AnaId = [ID]
AND Date BETWEEN [START] AND [END]
R3.2 Quantité de données booléennes. ParamètresID,STARTetEND.
SELECT count(*)
FROM boolvalues
WHERE BoolId = [ID]
AND Date BETWEEN [START] AND [END]
R4 Somme de valeurs analogiques.
ParamètresID,STARTetEND.
SELECT sum(Value)
FROM anavalues
WHERE AnaId = [ID]
R5 Moyenne de valeurs analogiques. ParamètresID,STARTetEND.
SELECT avg(Value)
FROM anavalues
WHERE AnaId = [ID]
AND Date BETWEEN [START] AND [END]
R6 Minimum et Maximum de valeurs analogiques.
ParamètresID,STARTetEND.
SELECT min(Value), max(Value)
FROM anavalues
WHERE AnaId = [ID]
AND Date BETWEEN [START] AND [END]
2.4.2.5 Filtrage sur la valeur R7 Dépassement de seuil critique. ParamètresID,STARTetEND.
SELECT Date, Value
FROM ana, anavalues
WHERE ana.AnaId = anavalues.AnaId
AND ana.AnaId = [ID]
AND Date BETWEEN [START] AND [END]
AND Value > ana.Threshold2;
R8 Dépassement de valeur.
ParamètresID,START,ENDetTHRESHOLD.
SELECT Date, Value
FROM anavalues
WHERE AnaId = [ID]
AND Date BETWEEN [START] AND [END]
AND Value > [THRESHOLD];
2.4.2.6 Calcul d’agrégats avec filtrage sur plusieurs séries R9 Repère avec valeurs anormales.
Récupère le repère dont les valeurs ne sont, le plus souvent, pas comprises entre ses deux seuils critiques entre deux dates.
ParamètresSTARTetEND.
SELECT Label, count(*) as count
FROM ana, anavalues
WHERE ana.AnaId = anavalues.AnaId
AND Date BETWEEN [START] AND [END]
AND (Value > Threshold2 OR Value < Threshold1)
GROUP BY ana.AnaId
ORDER BY count DESC
Algorithme 2.2: Traitement NoSQL de R9
input : start, end
1 foreach id in ana.AnaId do
2 count[id] ← 0
3 threshold1 ← ana[id].Threshold1
4 threshold2 ← ana[id].Threshold2
5 POSITION((id, start))
6 key, value ← READNEXT()
7 while key < (id, end) do
8 if value.Value < threshold1 or value.Value > threshold2 then 9 count[id]++
10 key, value ← READNEXT()
11 result_id ← i: ∀ id, count[id] ≤ count[i]
12 RETURN(ana[result_id].Label, count[result_id])
2.4.2.7 Opérations sur les dates
R10 Vérification de la période d’échantillonnage.
Récupère les repères dont la période d’échantillonnage ne respecte pas la valeurInterval don-née dans la tableana.
ParamètresSTARTetEND.
SELECT values.AnaId, count(*) as count
FROM ana,
(
SELECT D1.AnaId, D1.Date,
min(D2.Date-D1.Date) as Interval
FROM anavalues D1, anavalues D2
WHERE D2.Date > D1.Date
AND D1.AnaId = D2.AnaId
AND D1.Date BETWEEN [START] AND [END]
GROUP BY D1.AnaId, D1.Date
) as values
WHERE values.AnaId = ana.AnaId
AND values.Interval > ana.Interval
GROUP BY values.AnaId
ORDER BY count DESC
LIMIT 1;
2.4.2.8 Extraction de valeurs courantes
Ces deux requêtes ne possédant pas de paramètre, elles ne sont exécutées qu’une seule fois pour éviter d’utiliser le cache sur les requêtes – stocker leur résultats pour ne pas avoir à les réévaluer. Elles permettent de récupérer les valeurs les plus récentes pour chaque repère de la base.
R11.1 Valeurs analogiques courantes.
FROM anavalues, (
SELECT AnaId, max(Date) as latest
FROM anavalues
GROUP BY AnaId
) as currentdates
WHERE Date = currentdates.latest
AND anavalues.AnaId = currentdates.AnaId
ORDER BY anavalues.AnaId;
R11.2 Valeurs booléennes courantes.
SELECT boolvalues.BoolId, Value
FROM boolvalues, (
SELECT BoolId, max(Date) as latest
FROM boolvalues
GROUP BY BoolId
) as currentdates
WHERE Date = currentdates.latest
AND boolvalues.BoolId = currentdates.BoolId
ORDER BY boolvalues.BoolId;
2.5 Expérimentation du benchmark
Ce benchmark a été exécuté avec le progiciel d’historisation InfoPlus.21, le SGBDR MySQL et le SGBD NoSQL Berkeley DB.
Les progiciels d’historisation sont des solutions propriétaires avec des conceptions distinctes et donc des performances différentes. Nous avons choisi l’un des plus répandus, InfoPlus.21, utilisé à EDF dans le domaine nucléaire.
Nous avons retenu MySQL pour sa facilité d’utilisation et sa pérennité avec une commu-nauté d’utilisateurs importante, essentiels pour un usage industriel. Dans notre contexte, les tuples sont relativement petit (17 octets pour la tableanavalues), et la majorité des colonnes sont généralement accédées. De plus la sélectivité des requêtes est faible – la plupart des tuples remplissent les critères – dans l’intervalle de temps considéré. Ces propriétés réduisent l’intérêt d’utiliser un SGBD orienté colonnes.
Enfin, nous avons choisi l’entrepôt de paires clé-valeur ordonnées Berkeley DB pour nos expérimentations. Cette catégorie de système NoSQL est particulièrement adaptée aux requêtes usuelles basées sur des intervalles de clés (range queries).
Optimisation de MySQL Les résultats suivants ont été obtenus avec le moteur de stockage