Vous entendez parler de SAP HANA chaque jour

Vous savez maintenant que c’est une révolution, mais savez vous exactement ce que recouvre le concept de bases de données en colonnes ?

Même si le concept des bases de données orientées colonne n’est pas récent, puisqu’il date des années 70-80, il a fallu attendre 2004-2005 pour que les acteurs majeurs du Web, et notamment Facebook et Google, le remettent au goût du jour.

Avant cette renaissance, la majorité des DBMS (Database Management System) étaient pensés et optimisés pour l’écriture des données sur disque. Toutefois, le Web et la production massive de données a accru le besoin de lecture rapide des données pour les restituer.

Attendriez-vous des heures, voire des jours, pour avoir le résultat de votre recherche sur Google ?

Concept des bases de données en colonnes

Le concept des bases de données orientées colonne a alors trouvé sa place et, avec lui, la distinction entre les systèmes qui :

    – produisent des données et nécessitent des DBMS optimisés pour l’écriture
    – consomment ou restituent des données et nécessitent des DBMS optimisés pour la lecture.

Nous allons voir que le stockage de l’information est essentiel dans la distinction entre ces deux types de DBMS.

Schématiquement, comment les DBMS orientés ligne stockent-ils l’information ? Pour ces moteurs, une base de données est un ensemble de tables. Chaque table possède une définition qui peut être vue comme la structure de la donnée que cette table contient. La définition de la table détermine les attributs, appelés champs, de la donnée.

Par exemple, une table “utilisateur” simplifiée pourrait avoir la structure suivante :

  • “ID” (un entier) qui contiendra un identifiant unique de l’utilisateur.
  • “NOM” (chaîne de caractères) qui contiendra le nom de l’utilisateur.
  • “PRENOM” (chaîne de caractères) qui contiendra le prénom de l’utilisateur.
  • “HASH” (chaîne de caractères) qui contiendra une empreinte du mot de passe de l’utilisateur.

Les moteurs de base de données orientés ligne écrivent les enregistrements d’une table continûment sur le disque. Schématiquement, nous aurons sur le disque un fichier séquentiel ressemblant à

    0001;DURAND;GISELE;82c16692a7f9040f3a6eb6a6a3f3c141;

0002;DUPONT;JEAN;d5e1971795041e277eb15646b0a0cca3;

00XX;MARCHAND;LEON;11a3e229084349bc25d97e29393ced1d;

Avec une telle structure physique de table, un unique accès disque est suffisant pour écrire une donnée dans une table. La donnée est écrite en une seule fois en fin de table. L’écriture est donc très rapide. En revanche, le classement physique des données sur le disque, selon un ou plusieurs champs, n’est pas concevable. On comprend bien que les données ne sont pas organisées lors de l’écriture sur disque et qu’il faudra parcourir tout ou partie des données pour trouver l’information qui nous intéresse.

Comment les DBMS orientés colonne stockent-ils l’information ?

Pour ces moteurs, une base de données est un ensemble de colonnes. Chaque colonne stocke un type d’attribut de la donnée de manière ordonnée. Si nous reprenons l’exemple précédent, une colonne stockera le “NOM”, une colonne stockera “PRENOM”, etc. L’ID ne sera plus un attribut mais constituera le lien entre chaque attribut d’une donnée particulière. Les colonnes ressembleront à :

    1. colonne 1 –>

DUPONT;0002;

    1. …;DURAND;0001;…;

MARCHAND;00XX

    1. colonne 2 –> GISELE;0001;…;

JEAN ;0002;

    1. …;

LEON ;00XX

    1. colonne 3 –>

11a3e229084349bc25d97e29393ced1d;00XX;

 

    1. ;82c16692a7f9040f3a6eb6a6a3f3c141;0001;…;

d5e1971795041e277eb15646b0a0cca3;0002

Étant donné que les colonnes sont classées, la sélection des données sera extrêmement rapide.

Par exemple, si nous voulons sélectionner tous les gens qui ont un nom commençant par “D” et dont le prénom commence par “G”, le système en colonnes n’a pas besoin de parcourir toutes les données de la colonne “NOM”. Il trouve le premier nom commençant par “D” (le classement des données permet de le trouver très efficacement), puis il lit tous les noms jusqu’à ce que la première lettre du nom devienne “E”. En parallèle, car il n’a pas besoin du sous-ensemble calculé par la première condition, le système détermine de la même manière tous les prénoms commençant par “G”. Ensuite, il calcule le résultat en faisant l’intersection des deux sous-ensemble d’ “ID” pour trouver, dans notre exemple, “Durand Gisèle”. Un DBMS orienté ligne serait pratiquement obligé de parcourir toute la table utilisateur pour répondre à cette requête.

En revanche, on comprend bien que dans le cas d’un DBMS orienté colonne, la difficulté réside dans l’écriture des données sur le disque. Chaque enregistrement d’une donnée demande autant d’écriture disque et de classement que de colonnes. Ce type de DBMS est traditionnellement peu adapté aux systèmes qui demandent une consistance forte et temps réel des données mais c’est une autre histoire (et c’est aussi là que l’exploit SAP HANA réside).

Pour finir sur les avantages de SAP HANA

Nous avons essayé de donner un aperçu très rapide du concept de base de données orientées colonne en restant général mais il faudrait parler également d’administration, de scalabilité, de décentralisation, de hot disponibilité, de consistance des données, de compression, etc. Un ensemble de sujets passionnants qui font autant de différences entre l’organisation en lignes et l’organisation en colonnes.

Cet article a été écrit par P. Luginbuhl d’Intekeo, en collaboration avec Censio

PS : On résume souvent SAP HANA à l’utilisation du in-memory, mais c’est aussi une solution qui travaille avec un DBMS de type colonne, beaucoup (beaucoup) de processeurs pour paralléliser les traitements à l’extrême et enfin, des algorithmes très puissants de compression.

Laisser un commentaire