La persistance

Introduction

Il est fréquent de voir dans les articles de presse la métaphore qui dépeint la donnée en carburant. C’est une métaphore intéressante, certes, mais qui porte surtout sur la nécessité de transformer une énergie brute - comme le pétrole - vers une énergie utilisable comme un carburant de voiture par exemple. Il est une autre caractéristique de la donnée qui est tout aussi importante. Cette dernière est liée à la volatilité de la plupart de nos données : le stockage. En cela, la métaphore d’électricité est sans doute plus adéquate, finalement. En effet, la volatilité mais aussi les limitations (comme celles induites par le Big Data) imposées par le stockage de nos données dans certaines conditions amènent à concevoir des solutions qui doivent s’adapter sans cesse et à tout type de besoin.

Le stockage (ou la persistance) des données est donc une composante importante, voire vitale, dans la gestion des données. Quel que soit le profil (expert, analyste ou simple consommateur des informations), il est en effet indispensable de pouvoir accéder aux données. Or qui dit accès aux données dit aussi connaissance du mode de stockage sous-jacent. On verra dans ce chapitre les différents modes de stockage et la façon dont ces derniers influent sur les modalités d’accès ou d’utilisation des données.

Le premier type de support auquel on pense immédiatement est bien sûr le fichier, ou du moins un ensemble de fichiers. Mais dès lors que les aspects partage...

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. En effet, que ce soient les bases de données, les entrepôts de données (Data Warehouse) ou les lacs de données (Data Lake), tous fonctionnent avec des fichiers. Mais fermons la parenthèse ici et parlons de fichier comme une unité de stockage sur un support.

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.). Ils ne sont, en fin de compte, qu’un ensemble de données reliées de manière logique afin de pouvoir être stockées de manière physique sur un support.

À noter aussi :

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 ou informations dans un même endroit (pas nécessairement physique).

Aujourd’hui, il existe de nombreuses bases de données. Bien sûr lorsque l’on parle de base de données, on pense immédiatement à Oracle, Microsoft SQL Server, IBM DB2, etc. Pour faire simple, les premières qui nous viennent à l’esprit sont les bases de données "historiques" dites relationnelles que l’on nomme SGBD-R (Systèmes de Gestion de Base de Données Relationnelles).

Depuis quelques années, avec la quantité grandissante des données à stocker (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 verra 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. 

Les bases de données relationnelles (SGBD-R)

Système distribué et théorème CAP

Ce théorème CAP vient du constat (démontré de manière empirique) qu’Éric Brower a posé et qui confirme qu’à un instant donné il est impossible pour un système de gestion de données qui fonctionne comme un cluster (fonctionnement distribué) de respecter les trois contraintes suivantes :

Critères CAP

Les études d’Éric Bower ont aussi montré qu’il est possible de respecter deux contraintes au maximum (à un instant donné) mais jamais les trois. Cela impose donc certains compromis.

Ce théorème aura des impacts sur les typologies de bases de données orientées cluster que nous allons voir par la suite. Ce théorème influence particulièrement l’architecture...

Les bases NoSQL

Au cours des années 2010, et face à une boulimie inéluctable de données mais aussi à cause de la diversité des structures de données à exploiter, les bases de données atteignent, dans certains cas, très vite leurs limites. Un nouveau paradigme qui va redistribuer les critères CAP tout en regroupant plusieurs initiatives autour de la donnée va naître de cette déviance. Il faut donc faire certains choix et en effet 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 avec les bases de données relationnelles. Au contraire, il vient combler les lacunes de ces derniers dans les deux autres volets du théorème CAP (tolérance au morcellement et disponibilité), cela bien sûr au détriment de la cohérence.

Voici quelques exemples d’implémentations NoSQL :

Le Big Data

La réelle limite des bases de données traditionnelles 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 type de chiffre ne cesse de fluctuer à la hausse. Au cours des années 2000, des entreprises telles que Facebook ou Google ont 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). Mais, avant tout, il était important de positionner les priorités de ce que le nouveau type de système de stockage devait proposer.

À la genèse du Big Data on trouve donc les 3 V.

Les tendances actuelles