Hana : le tout est plus que la somme des parties

On parle maintenant à nouveau de plus en plus de "stockage à chaud" (Dynamic Tiering et Native Storage Extensions). SAP fait-il donc le chemin inverse et se retrouve-t-il finalement là d'où viennent les bases de données classiques - avec des bases de données sur disque et de la mémoire comme cache ?

Rows pour OLTP Columns pour OLAP

On entend souvent dire qu'un stockage par rangée, pour lire des phrases entières, est préférable. Même Hasso Plattner l'a sous-entendu lors de la dernière keynote de Sapphire. Argument habituel :

Les données d'un enregistrement sont rassemblées dans une base de données basée sur les lignes. Un argument accrocheur, mais trop réducteur. La distance topologique n'est pas prise en compte.

Cet argument remonte à l'époque des disques durs, où la tête de lecture plus la vitesse angulaire du disque en rotation déterminaient le temps d'accès et où des secteurs de 4 ko étaient lus en une seule fois.

Avec les SSD, il n'y a plus de mécanique, une adresse est envoyée et un secteur de 4 ko est renvoyé. Le temps d'accès à un secteur est donc nettement plus court, mais les données devraient toujours être proches les unes des autres, dans le même secteur de 4 ko.

Au lieu de cela, Memory ne renvoie que 16 octets par accès, mais bien sûr beaucoup plus rapidement, et l'adresse mémoire demandée ensuite n'a aucune importance.

En d'autres termes, pour lire 4 ko à la vitesse maximale, les données des disques durs et des disques SSD doivent se trouver dans un secteur. La mémoire s'en fiche complètement, elle effectue de toute façon 256 accès de 16 octets pour lire 4 kB.

De ce point de vue, et si toutes les données sont déjà en mémoire, une sauvegarde orientée Row ou Column est aussi rapide. L'adresse mémoire est différente, mais cela n'a pas d'influence sur la vitesse.

Ce n'est que pour les opérations sur disque que l'affirmation selon laquelle la lecture d'une ligne exige un stockage orienté par rangée et les analyses OLAP une orientation par colonne est valable. J'ai ainsi réfuté le raisonnement lui-même, mais l'affirmation "avec suffisamment de mémoire, même une base de données normale est une base de données en mémoire" reste encore sans réponse.

Cette justification découle de l'orientation des colonnes : un ensemble de données contient les informations les plus diverses, le numéro d'article, du texte et de nombreux indicateurs tels que la couleur, le type, la taille, etc.

Ces informations divergentes ne peuvent certainement pas être aussi bien comprimées que chaque colonne isolée avec des modèles plutôt répétitifs. L'approche est même plus intelligente, puisque chaque valeur d'une telle colonne est considérée séparément.

Par exemple, pour le champ Taille, il n'y a que les valeurs M, S, L, XL, donc quatre chaînes sont créées. La chaîne pour M peut ressembler à ceci : 0100-0000-0000-1000 ; et elle indique que la valeur M apparaît dans les enregistrements 2 et 13.

Ce genre de choses peut être très bien compressé par un ordinateur et aussi très rapidement. Pour d'autres colonnes, comme le numéro d'article, qui est différent pour chaque article, d'autres méthodes sont utilisées.

Chercher et trouver

Dans un système ERP, l'accès aux données se fait soit par clé primaire, soit par une recherche. "afficher la commande de vente 1234" ou "rechercher tous les éléments de vente relatifs à la commande de vente 1234".

Le premier processus est le même pour les deux types de bases de données. Une base de données classique utilise l'index, y trouve l'adresse de la ligne et lit cet enregistrement à cette adresse. Dans Hana, on lit l'index, on y trouve le numéro de l'enregistrement et on récupère dans chaque colonne la valeur à cette position.

Il existe à nouveau des différences dans la recherche : dans le cas d'une orientation par rangée, on espère qu'il existe un deuxième index dans lequel se trouvent toutes les adresses des enregistrements d'items de vente qui appartiennent à un ordre de vente.

Dans le cas contraire, la base de données n'a aucune chance et doit parcourir toute la table. Avec Hana, l'indexation est déjà assurée par le mode de stockage. C'est un immense avantage pratique.

Chacun de ces points - orientation des colonnes, compression, indexation et in-memory - présente en soi des avantages et des inconvénients. La caractéristique unique de SAP Hana est que, même aujourd'hui, cette base de données est la seule à combiner intelligemment tous ces points, de sorte que les avantages se combinent.

Tout garder en mémoire est possible si l'on comprime. Organiser les données en colonnes permet de mieux les compresser. Hormis les clés primaires, on n'a plus besoin d'index grâce à l'organisation en colonnes et à la compression.

Comme toutes les données se trouvent en mémoire, les requêtes sur un ensemble complet de tables sont aussi rapides qu'avec un stockage orienté par rangée, on peut donc utiliser un stockage par colonne même pour de telles requêtes.

En revanche, on gagne beaucoup avec Hana pour les cas normaux. Les requêtes OLAP du type "total des ventes par an" sont très rapides, car les données sont déjà organisées en colonnes.

Les recherches sur n'importe quel attribut sont beaucoup plus rapides, car chaque colonne représente en soi un index. Les requêtes qui ne lisent pas 100 % des colonnes de la table sont plus rapides.

Mais c'est précisément là que le bât blesse : Je suis parti du principe que toutes les données étaient déjà en mémoire et qu'elles pouvaient y être stockées.

N'est-ce pas un gaspillage de mémoire, et donc d'argent, que de toujours tout garder en mémoire vive (Random Access Memory), que l'on en ait besoin ou non ?

SAP donne ici à l'administrateur des possibilités d'optimisation : un premier point concerne les types de données binaires (types de données LOB, CLOB et NCLOB). Ils ne sont pas stockés en mémoire, mais restent toujours sur disque.

La mémoire contient le pointeur vers le fichier, mais pas le contenu. C'est une bonne idée, mais elle n'est pas d'une grande aide, car de tels types de données n'apparaissent guère dans un ERP.

Première utilisation

Optimisation suivante : les partitions ne sont chargées en mémoire que lorsqu'elles ont été utilisées pour la première fois, et non pas de manière préventive. Ainsi, si une table se compose d'un milliard d'enregistrements, répartis en dix partitions pour dix ans, seule la partition pour l'année en cours serait chargée en mémoire.

C'est également une bonne idée, qui réduit le temps de démarrage et l'utilisation initiale de la mémoire, mais au fil du temps, chaque partition aura été utilisée au moins une fois par quelqu'un. Ainsi, tout se retrouve à un moment ou à un autre dans la RAM et y reste jusqu'au prochain redémarrage.

Il existe une fonction pour cela : la période de rétention. Avec ce paramètre, de telles partitions sont supprimées de la RAM après un temps défini sans aucun accès. Enfin un paramètre qui permet de supprimer des choses de la RAM. Attention, ce bouton est désactivé par défaut !

C'est déjà très bien, mais il y a deux lacunes. La première personne qui utilise ne serait-ce qu'un seul enregistrement déclenche le chargement complet de cette partition en mémoire.

Si une telle partition fait un gigaoctet, cela peut prendre deux secondes. Et tout cela ne sert à rien si la base de données complète nécessite 1,1 téraoctet de RAM alors qu'il n'y a qu'un téraoctet disponible.

C'est ici que la dernière fonctionnalité, la Native Storage Extension, vient à l'aide. Ainsi, ce n'est plus la partition complète qui est chargée, mais uniquement les pages nécessaires qui contiennent ces données.

Et s'il n'y a pas assez de RAM, les pages inutiles sont supprimées. De cette manière, on procède vraiment comme pour une base de données classique sur disque et on utilise la RAM uniquement comme cache pour les tables avec ce réglage.

Données multi-températures

Mais ce n'est pas ainsi que cela a été conçu. Hana est une base de données in-memory computing, toutes ( !) les données utilisées ( !) doivent donc être disponibles en mémoire. Ce n'est qu'ainsi que les requêtes OLTP et OLAP peuvent être traitées par la même base de données et que l'on obtient des temps de réponse courts et prévisibles.

Ces fonctions supplémentaires sont uniquement adaptées aux données multi-températures. Pour les données qui sont utilisées de temps en temps. Pour lesquelles l'utilisateur ne doit pas être envoyé dans une base de données d'archives.

Si j'utilisais ces fonctionnalités pour tous les tableaux et que je ne disposais pas de suffisamment de RAM, les inconvénients du stockage en colonnes commenceraient à se faire sentir. Je n'aurais plus tous les avantages sans les inconvénients.

Au lieu de cela, Hana représente le point d'entrée central pour les données à différentes températures et cache les différences physiques : l'utilisateur place ses commandes, certaines données proviennent du magasin en mémoire, d'autres du disque, d'autres encore sont affichées via la fonction Hana Smart Data Access d'un système externe ("Federated"). L'utilisateur ne remarque rien, si ce n'est, le cas échéant, des temps de réponse plus longs. Hana devient une Data Fabric.

La physique est cachée, mais elle est toujours présente. La lecture des structures de données Hana à partir de la mémoire est plus rapide que celle à partir du disque avec l'extension de stockage native.

La rupture avec le Dynamic Tiering avec une base de données SAP IQ en arrière-plan est encore plus grande, car les structures de données Hana ne sont plus utilisées ici. L'interface est donc limitée à SQL.

Et si l'utilisateur accède à un système externe par le biais de Smart Data Access, la réponse ne peut être qu'aussi rapide que le système externe le permet.