I. Stockage en colonne ?▲
Pour illustrer le stockage en colonne, considérons la table Hotel suivante :
| Hotel | ||
|---|---|---|
| Nom | Ville | Etoile |
| Icone | Paris | 3 |
| Soft | Paris | 3 |
| Sezz | Paris | 4 |
Le stockage de ces données se fait dans des fichiers décomposés en pages. Pour simplifier, nous considérerons que chaque page stocke une ligne ou une colonne (hypothèse loin de la réalité mais qui permet de bien comprendre l'idée du stockage en colonne).
Dans un SGBD relationnel traditionnel, le stockage se ferait alors dans un fichier selon le schéma suivant :
| Page 1 | Page 2 | Page 3 |
|---|---|---|
| [Icône, Paris, 3] | [Soft, Paris, 3] | [Sezz, Paris, 4] |
Les lignes sont ainsi stockées consécutivement dans le fichier. A l'opposé, un stockage en colonne serait le suivant :
| Page 1 | Page 2 | Page 3 |
|---|---|---|
| [Icône, Soft, Sezz] | [Paris, Paris, Paris] | [3, 3, 4] |
L'approche suivie par les SGBD relationnels en colonne consiste ainsi à stocker les données colonne par colonne.
II. Avantages / Inconvénients du stockage en colonne ?▲
II-A. Requêtes▲
Soit la requête suivante :
SELECT Nom FROM Hotel
Sur l'exemple précédent, on voit que cette requête ne nécessite la lecture que d'une seule page (Page 1) pour le stockage en colonne alors qu'elle en nécessite 3 pour le stockage en ligne. Ceci vient du fait qu'avec le stockage en ligne, on lit des colonnes qui ne sont pas nécessaires à la requête.
Si l'on considère maintenant la requête suivante :
SELECT * FROM Hotel where nom='Soft'
La situation est inversée : le stockage en ligne ne nécessite la lecture que d'une seule page (Page 2) alors que le stockage en colonne en nécessite 3.
Si on généralise ces constatations :
- le stockage en colonne est plus intéressant que le stockage en ligne pour les requêtes recherchant peu de colonnes de nombreuses lignes ;
- le stockage en ligne est plus intéressant que le stockage en colonne pour les requêtes recherchant de nombreuses colonnes de peu de lignes.
II-B. Mises à jour▲
Une comparaison similaire entre les deux stockages se fait sur les mises à jour.
Update Hotel set Etoile = 3
Le stockage en colonne ne nécessite la mise à jour que d'une seule page (page 3) alors que le stockage en ligne en nécessite 3. Cela vient du fait que l'on ne modifie qu'une seule colonne pour toutes les lignes.
Inversement pour la mise à jour suivante :
Insert into Hotel Values ('Carli', 'Bordeaux', 2)
Il ne faut la modification que d'une seule page pour le stockage en ligne alors qu'il en faut 3 pour le stockage en colonne.
En généralisant :
- le stockage en colonne est plus intéressant que le stockage en ligne pour la mise à jour de la valeur de peu colonnes de nombreuses lignes ;
- le stockage en ligne est plus intéressant que le stockage en colonne pour les mises à jour de nombreuses colonnes de peu de lignes.
II-C. Compression▲
Un avantage non négligeable du stockage en colonne est également qu'il résulte en des données qui peuvent être plus facilement compressées (et ainsi qui nécessitent moins de lecture de pages). Par exemple, la colonne Ville peut facilement être compressée par le codage par plage suivant :
[Paris, Paris, Paris] -> [3Paris]
Les données d'une colonne étant similaire (ce qui n'est pas le cas d'une ligne), la compression de ces données est ainsi plus simple.
III. SGBD en colonne existants ?▲
Vous trouverez ci-dessous une liste des SGBD en colonne sur le marché.
- Open source : Monet, LucidDB.
- Industriels : Vertica, ParAccel, Teradata Columnar, Calpont, Infobright, Exasol
IV. Conclusion▲
Le stockage en colonne de données relationnelles est particulièrement adapté au contexte des Entrepôts de Données car :
- les requêtes consistent à la consultation de nombreuses données et l'agrégation de colonnes ;
- les mises à jour sont essentiellement faites en batch. Ces résultats sont confirmés par les très bons résultats d'Exasol et ParAccel au benchmark TPC-H, spécialisé pour les entrepôts de données.