Editions ENI Livres | Vidéos | e-Formations
La persistance
Introduction
On parle souvent de donnée comme d’un carburant. C’est une métaphore intéressante, certes, mais qui évoque surtout la nécessité de transformer une énergie brute - comme le pétrole - en une énergie utilisable comme le carburant de voiture par exemple. Une autre caractéristique de la donnée est importante : sa volatilité, qui a un lien irrémédiable avec le stockage de la donnée (de manière persistante ou volatile). En cela, la métaphore de l’électricité serait sans doute plus adéquate. En effet, la volatilité des données est, et reste, un enjeu qui, bien souvent, amène à faire des choix entre stockage et distribution immédiate, parfois même les deux.
Le stockage (ou du moins la notion de persistance) des données est donc une composante importante, voire capitale, dans la gestion des données. Quel que soit le profil impliqué dans l’utilisation de ces données (expert, analyste ou développeur), il est en effet indispensable de pouvoir y accéder selon le besoin. Dans certains cas, on devra avoir une donnée disponible à tout moment et dans d’autres celle-ci ne devra être disponible qu’à certains moments (avec une gestion de cache par exemple). Qui dit accès aux données...
Fichiers
De la même manière que le bit est l’unité primaire d’encodage de la donnée, le fichier est en quelque sorte l’unité primaire de stockage d’un ensemble de données sur un support (c’est une question de granularité de stockage).
Les bases de données, les entrepôts de données (Data Warehouse) ou les lacs de données (Data Lake) fonctionnent tous en fin de compte avec des fichiers.
Parlons donc ici de fichier comme une unité de stockage.
|
Qu’est-ce qu’un fichier ? Un fichier est un ensemble de données stocké et encodé de manière structurée sur un support (physique si c’est un disque dur). Un fichier est identifié par un nom et, par convention (car c’est facultatif), peut avoir une extension. |
Les fichiers sont gérés et organisés par le système d’exploitation via le système de fichiers (File System) qui peut lui aussi être de plusieurs natures (NTFS, FAT, FAT32, ext2fs, ext3fs, ext4fs, zfs, etc.). Les fichiers ne sont donc qu’un ensemble de données reliées de manière logique afin de pouvoir être stockées physiquement sur un support.
À noter :
-
Il est possible de stocker plusieurs fichiers dans un seul fichier via des formats de stockage tels que Zip, Tar, etc.
-
Il est possible d’exécuter des fichiers (exécutables) directement dans le système d’exploitation, si ces derniers ne stockent pas à proprement dit de données.
-
Un fichier est attaché à un type de format (structure) qui permet d’identifier sa nature. Par exemple, on sait que les fichiers images sont de type JPG, PNG, etc.
Voyons alors de plus près quelques types de fichiers dont la vocation est de stocker de l’information.
1. Le fichier CSV
Les fichiers de type CSV (Comma Separated Values) sont sans doute ceux que l’on retrouve le plus souvent en gestion de données car ils sont très simples et surtout compréhensibles et accessibles par tous les systèmes. On parle aussi de fichier plat avec séparateur. Le format de ces fichiers est structuré car le formatage des données (ASCII, UTF-x) est tabulaire. Ces fichiers sont donc organisés en lignes et en colonnes et peuvent...
Les bases de données
Comment écrire un guide sur la donnée sans aborder les bases de données ? Une base de données permet de stocker et organiser un ensemble de données dans un même endroit (pas nécessairement physique).
Aujourd’hui, il existe de nombreuses bases de données. Lorsque l’on parle de base de données, on pense immédiatement aux grands noms comme Oracle, Microsoft SQL Server, IBM DB2, etc. Ces dernières sont les bases de données « historiques » dites relationnelles que l’on nomme aussi SGBD-R (Systèmes de Gestion de Base de Données Relationnelles).
Depuis quelques années, avec la quantité grandissante des données à stocker (on parle du phénomène Big Data) et la diversité des usages, il était devenu impératif de repenser la manière de gérer les données. De nouvelles formes de bases de données sont alors apparues, permettant de combler les lacunes des « bonnes vieilles » bases de données relationnelles. On étudiera notamment dans ce chapitre les bases NoSQL qui proposent de nouvelles perspectives dans le stockage de données non structurées.
Avant tout, il est important de parcourir les grandes familles de bases de données.
1. Familles de bases de données
On distingue plusieurs grandes familles de bases de données :
-
Les bases de données relationnelles (SGBD-R). Ce sont les plus utilisées et on y reviendra plus en détail dans la section suivante.
-
Les bases de données hiérarchiques. Comme leur nom l’indique, les informations y sont stockées en arbre (de manière hiérarchique donc). Ce dernier est composé de nœuds (chaque donnée) et de branches (liens entre deux nœuds).
Ce type de système impose quelques contraintes :
-
l’existence d’un nœud racine (parent) ;
-
un nœud (enfant) ne peut avoir qu’un seul nœud parent.
Illustration d’un modèle de données hiérarchique
-
Les bases de données orientées graphes (ou réseaux) : les bases de données réseaux contournent une limitation assez gênante des bases de données hiérarchiques en...
Les bases de données relationnelles (SGBD-R)
1. Le langage SQL
Le langage SQL (Structured Query Language) est le langage normalisé d’interrogation et de mise à jour des données dans une base de données relationnelle. Sa première version date de 1970 (IBM). Ce langage est devenu en quelques décennies la référence absolue en matière d’accès aux données. À tel point que même les autres types de bases de données (NoSQL par exemple) s’en inspirent et surtout cherchent à proposer un mode d’interrogation qui se rapproche au maximum du SQL.
Attention car le langage SQL a beaucoup évolué et changé depuis sa création. Parfois ces changements sont dans les détails, et diffèrent selon les SGBD-R. Sachez qu’officiellement, plusieurs normes ont vu le jour (SQL-1, SQL-2, etc.) qui apportent aussi des différences notables.
Par ailleurs, si le SQL est un standard reconnu, beaucoup d’acteurs ou éditeurs de base de données ont pris des libertés par rapport à ce standard et ont adapté et étendu ce langage en fonction de leurs propres besoins. Aujourd’hui, la portabilité d’instructions SQL d’une base à une autre n’est pas forcément évidente ou garantie.
Impossible d’aborder le SQL sans passer en revue les grands concepts ensemblistes inhérents à ce langage d’interrogation de données. Le SQL est basé sur ce que l’on appelle des requêtes. Une requête est en quelque sorte une instruction envoyée à la base de données qui permet à l’utilisateur de l’interroger ou de communiquer avec elle.
Le langage SQL comporte trois grandes typologies d’instructions :
-
le LMD (Langage de Manipulation de Données) qui permet d’interroger les données. Ce langage permet d’agir directement sur les données stockées ;
-
le LDD ou DDL (Langage de Définition des Données) qui sert à contrôler les données et permet de créer/modifier/supprimer les structures physiques de la base de données comme les index/tables, etc. ;
-
et le LCD (Langage de Contrôle de Données) pour gérer notamment les utilisateurs/groupes...
Les systèmes OLTP et OLAP
Impossible de ne pas évoquer les systèmes OLTP (OnLine Transaction Processing). Ce type de système de gestion de données est en effet capable de prendre en charge les applications orientées transactions (saisie des commandes, transactions financières, gestion de la relation client (CRM) et ventes au détail).
On parle de systèmes opérationnels.
Ces systèmes sont conçus pour gérer des données opérationnelles via des transactions et ont souvent comme caractéristiques :
-
la gestion de petits ensembles de données ;
-
l’indexation de l’accès aux données ;
-
un grand nombre d’utilisateurs/requêtes ;
-
beaucoup de requêtes (CRUD) ;
-
une exigence en matière de temps de réponse ;
-
de grands volumes de données.
Ce type de système est souvent en opposition avec un traitement de type OLAP (Décisionnel/OnLine Analytical Processing) : ce dernier implique par exemple d’interroger de nombreux enregistrements (parfois même tous les enregistrements) dans une base de données à des fins analytiques.
D’ailleurs, si la même base de données peut proposer ces deux types d’utilisations, la modélisation, elle, se doit d’être différente :
-
OLTP -> Modélisation relationnelle
-
OLAP ->...
Système distribué et théorème CAP
Le théorème CAP (acronyme de Consistency, Availability & Partition tolerance) est né du constat (démontré de manière empirique) qu’Éric Brower (chercheur à l’université de Californie à Berkeley) a posé en 2002. Il affirme qu’il est impossible pour un système de gestion de données qui fonctionne comme un cluster (c’est-à-dire en fonctionnement distribué) de respecter les trois contraintes suivantes simultanément :
Critères CAP
-
Cohérence : ce critère certifie que tous les éléments constitutifs du système de gestion de données contiennent exactement les mêmes données au même moment.
-
Disponibilité : c’est un critère simple qui permet d’assurer que toute requête doit recevoir une réponse.
-
Tolérance au morcellement : dans un système fonctionnant avec plusieurs nœuds (cluster), ce critère impose que les données, si elles sont morcelées (éparpillées sur plusieurs nœuds), doivent pouvoir être reconstituées à tout moment, et ce même en cas de panne d’un des éléments/nœuds.
Les études d’Éric Bower ont aussi montré...
Les bases de données NoSQL
Au cours de la décennie 2010, en raison de l’augmentation significative du volume de données à traiter et de la diversification des structures de données à exploiter, certaines bases de données ont rapidement atteint leurs limites. De ce constat va naître un nouveau paradigme dans lequel les critères CAP vont être redistribués, voire remis en question. Il faut dorénavant faire certains choix et proposer des solutions permettant de répondre à la demande de disponibilité, et ce au détriment du maintien de la cohérence (cf. Théorème CAP). Les bases de données dites NoSQL (comme Not Only SQL - pas seulement SQL) font alors leur apparition.
Ces nouveaux systèmes de gestion de données remettent alors en cause certains concepts et principes bien établis jusque-là des bases de données traditionnelles tels que les propriétés ACID. Tout cela dans un but précis : gérer de grands (très grands) volumes de données, de tout type.
Ce courant NoSQL, contrairement à certaines idées reçues, ne s’affirme pas en opposition aux bases de données relationnelles. Au contraire, il vient combler les lacunes de ces dernières dans les deux autres aspects du théorème CAP (tolérance au morcellement...
Le Big Data
La réelle limite des bases de données traditionnelles, comme abordé précédemment est sans aucun doute la gestion de très grosses quantités de données. À titre d’exemple, certains analystes n’hésitent pas à affirmer qu’environ 2,5 trillions d’octets de données sont produits par jour. C’est considérable et ce chiffre ne cesse d’augmenter. Au cours des années 2000, des entreprises telles que Facebook ou Google ont d’ailleurs dû se confronter à ce problème de Big Data afin de pouvoir proposer plus de services avec davantage de données à gérer. Il a alors fallu penser à d’autres modes de gestion de données et proposer une alternative à nos fameuses bases de données relationnelles (SGBD-R). Avant tout, il était important de définir les priorités de ce que le nouveau type de système de stockage devait proposer. C’est la genèse du Big Data avec ce que l’on appelle les 3 V.
1. Les 3 V
La notion de Big Data repose sur le concept des 3 V (introduit par Doug Laney en 2001) : Volume, Variété et Vélocité. Ce concept, dès le début d’Hadoop, a été la loi, ou du moins la voie, que devraient suivre les systèmes dits Big Data.
Mais que veulent dire ces 3 V ?
-
V comme volume. Cela peut paraître évident quand on parle de Big Data mais la qualité première d’un système Big Data est d’être capable de gérer une très grande quantité de données. Cette quantité de données stockées pourra même (très vraisemblablement) ne cesser de croître au fil du temps. À l’heure actuelle, on estime la quantité de données dans le monde à plusieurs dizaines de zettaoctets, soit plusieurs milliards de téraoctets ! Et bien sûr ce n’est que le début...
-
V comme Variété. C’est l’une des caractéristiques des systèmes Big Data. On ne se limite plus aux données structurées. Il devient important d’ingérer toute typologie de données structurées ou non ! Ces données...
Les bases de données vectorielles
1. Introduction aux bases vectorielles
Avec l’apparition récente des LLM (Large Language Models) tels que ChatGPT et Bard AI (pour les précurseurs) émerge rapidement un nouveau type de base de données : les bases de données vectorielles. Ces dernières offrent la possibilité d’interagir avec ces fameux LLM en les enrichissant avec des données qui ne proviennent pas de leur entraînement.
Un cas d’usage de ces bases de données vectorielles est devenu courant dans le cadre de la mise en place d’architecture RAG (Retrieval Augmented Generation). Cette dernière est une approche qui combine des modèles de récupération d’informations externes avec des modèles de génération de langage naturel. Grâce à un calcul de similarité avec les données préalablement chargées dans une base de données vectorielles, le LMM peut alors dynamiquement être enrichi de données externes. On peut voir cette technique comme une manière de spécialiser ou plutôt de contextualiser les LLM.
Les bases de données vectorielles sont également appelées Vector-Based Database Management System (VBDBMS) et constituent une approche novatrice dans le domaine du stockage et de la gestion des données. Contrairement aux bases de données relationnelles ou NoSQL, elles adoptent une méthode de représentation des données sous forme de vecteurs dans un espace multidimensionnel propice aux réseaux de neurones (abordés plus loin dans cet ouvrage).
Cette approche particulière ouvre la porte à des recherches et des analyses basées sur la similarité et la proximité entre les éléments de données, transcendant ainsi les limitations...
La gestion de cache
1. Le cache comme tampon
Une notion très fortement liée à la persistance et qui permet pour autant de s’en détacher d’un point de vue performance est celle de cache. Il s’agit d’un mécanisme qui consiste à stocker temporairement des données fréquemment utilisées dans une mémoire à part, réduisant ainsi le temps d’accès aux données et améliorant les performances globales du système. On peut voir la gestion du cache comme une part optionnelle d’une solution mais elle devient vite indispensable dès lors qu’un système absorbe beaucoup de transactions, ou a tout simplement besoin d’assurer des temps de réponses avec des volumes de données non négligeables. Gérer le cache implique de mettre en place des mécanismes particuliers qui vont devoir s’adapter aux contraintes et besoins des solutions.
Les techniques sous-jacentes en matière de gestion de cache incluent donc souvent l’utilisation d’algorithmes de remplacement (comme LRU - Least Recently Used), la gestion de la cohérence entre le cache et la mémoire principale et une stratégie d’expiration pour garantir la validité des données en cache. Les contraintes comprennent la gestion de l’espace mémoire du cache, le maintien de la cohérence des données entre le cache et la mémoire principale, et la nécessité de gérer efficacement les invalidations de cache lors de la modification des données sous-jacentes.
|
Avantages |
Contraintes |
|
Amélioration des performances La réduction significative des temps d’accès aux données fréquemment utilisées accélère les opérations sur les données. |
Gestion de l’espace La taille... |
Les tendances actuelles
1. Bases de données dans le Cloud (Database as a Service : DBaaS)
Aujourd’hui il est possible d’utiliser les bases de données au travers de fournisseurs externes via des services Cloud. C’est ce que l’on appelle le DBaaS (DataBase as a Service).
Les avantages de ce type d’utilisation sont évidemment très liés à l’exploitation de la solution :
-
Aucune installation ni maintenance logicielle/matérielle (On-Premise) n’est nécessaire.
-
La gestion des ressources (besoin d’espaces, puissance) est plus souple et adaptative. Le gain en flexibilité est notoire car le service est fourni par des Data Center à haut niveau de performance.
-
Le monitoring, l’administration et la surveillance des bases de données sont automatisés par le fournisseur.
-
Des experts dédiés par le fournisseur garantissent la sécurité.
-
Le reporting est automatique et exhaustif.
Les inconvénients potentiels :
-
Les données sont stockées en dehors de l’entreprise.
-
Dans le cas de données confidentielles ou personnelles (RGPD), cela peut poser des interrogations voire des problèmes selon la localisation du Data Center.
-
Selon les contrats de services proposés, les Data Centers peuvent être indisponibles temporairement (maintenance, etc.).
Aujourd’hui, il y a pléthore de fournisseurs...
Bilan
|
À retenir |
|
|
|
Aller plus loin |