{"id":62754,"date":"2019-11-28T08:00:32","date_gmt":"2019-11-28T07:00:32","guid":{"rendered":"http:\/\/e3mag.com\/?p=62754"},"modified":"2020-02-07T22:12:14","modified_gmt":"2020-02-07T21:12:14","slug":"hana-lensemble-est-plus-que-la-somme-des-parties","status":"publish","type":"post","link":"https:\/\/e3mag.com\/fr\/hana-das-ganze-ist-mehr-als-die-summe-der-einzelteile\/","title":{"rendered":"Hana : le tout est plus que la somme des parties"},"content":{"rendered":"

On parle maintenant \u00e0 nouveau de plus en plus de \"stockage \u00e0 chaud\" (Dynamic Tiering et Native Storage Extensions). SAP fait-il donc le chemin inverse et se retrouve-t-il finalement l\u00e0 d'o\u00f9 viennent les bases de donn\u00e9es classiques - avec des bases de donn\u00e9es sur disque et de la m\u00e9moire comme cache ?<\/p>\n

Rows pour OLTP Columns pour OLAP<\/h3>\n

On entend souvent dire qu'un stockage par rang\u00e9e, pour lire des phrases enti\u00e8res, est pr\u00e9f\u00e9rable. M\u00eame Hasso Plattner l'a sous-entendu lors de la derni\u00e8re keynote de Sapphire. Argument habituel :<\/p>\n

Les donn\u00e9es d'un enregistrement sont rassembl\u00e9es dans une base de donn\u00e9es bas\u00e9e sur les lignes. Un argument accrocheur, mais trop r\u00e9ducteur. La distance topologique n'est pas prise en compte.<\/p>\n

Cet argument remonte \u00e0 l'\u00e9poque des disques durs, o\u00f9 la t\u00eate de lecture plus la vitesse angulaire du disque en rotation d\u00e9terminaient le temps d'acc\u00e8s et o\u00f9 des secteurs de 4 ko \u00e9taient lus en une seule fois.<\/p>\n

Avec les SSD, il n'y a plus de m\u00e9canique, une adresse est envoy\u00e9e et un secteur de 4 ko est renvoy\u00e9. Le temps d'acc\u00e8s \u00e0 un secteur est donc nettement plus court, mais les donn\u00e9es devraient toujours \u00eatre proches les unes des autres, dans le m\u00eame secteur de 4 ko.<\/p>\n

Au lieu de cela, Memory ne renvoie que 16 octets par acc\u00e8s, mais bien s\u00fbr beaucoup plus rapidement, et l'adresse m\u00e9moire demand\u00e9e ensuite n'a aucune importance.<\/p>\n

En d'autres termes, pour lire 4 ko \u00e0 la vitesse maximale, les donn\u00e9es des disques durs et des disques SSD doivent se trouver dans un secteur. La m\u00e9moire s'en fiche compl\u00e8tement, elle effectue de toute fa\u00e7on 256 acc\u00e8s de 16 octets pour lire 4 kB.<\/p>\n

De ce point de vue, et si toutes les donn\u00e9es sont d\u00e9j\u00e0 en m\u00e9moire, une sauvegarde orient\u00e9e Row ou Column est aussi rapide. L'adresse m\u00e9moire est diff\u00e9rente, mais cela n'a pas d'influence sur la vitesse.<\/p>\n

Ce n'est que pour les op\u00e9rations sur disque que l'affirmation selon laquelle la lecture d'une ligne exige un stockage orient\u00e9 par rang\u00e9e et les analyses OLAP une orientation par colonne est valable. J'ai ainsi r\u00e9fut\u00e9 le raisonnement lui-m\u00eame, mais l'affirmation \"avec suffisamment de m\u00e9moire, m\u00eame une base de donn\u00e9es normale est une base de donn\u00e9es en m\u00e9moire\" reste encore sans r\u00e9ponse.<\/p>\n

Cette justification d\u00e9coule de l'orientation des colonnes : un ensemble de donn\u00e9es contient les informations les plus diverses, le num\u00e9ro d'article, du texte et de nombreux indicateurs tels que la couleur, le type, la taille, etc.<\/p>\n

Ces informations divergentes ne peuvent certainement pas \u00eatre aussi bien comprim\u00e9es que chaque colonne isol\u00e9e avec des mod\u00e8les plut\u00f4t r\u00e9p\u00e9titifs. L'approche est m\u00eame plus intelligente, puisque chaque valeur d'une telle colonne est consid\u00e9r\u00e9e s\u00e9par\u00e9ment.<\/p>\n

Par exemple, pour le champ Taille, il n'y a que les valeurs M, S, L, XL, donc quatre cha\u00eenes sont cr\u00e9\u00e9es. La cha\u00eene pour M peut ressembler \u00e0 ceci : 0100-0000-0000-1000 ; et elle indique que la valeur M appara\u00eet dans les enregistrements 2 et 13.<\/p>\n

Ce genre de choses peut \u00eatre tr\u00e8s bien compress\u00e9 par un ordinateur et aussi tr\u00e8s rapidement. Pour d'autres colonnes, comme le num\u00e9ro d'article, qui est diff\u00e9rent pour chaque article, d'autres m\u00e9thodes sont utilis\u00e9es.<\/p>\n

\"Werner<\/a><\/h3>\n

Chercher et trouver<\/h3>\n

Dans un syst\u00e8me ERP, l'acc\u00e8s aux donn\u00e9es se fait soit par cl\u00e9 primaire, soit par une recherche. \"afficher la commande de vente 1234\" ou \"rechercher tous les \u00e9l\u00e9ments de vente relatifs \u00e0 la commande de vente 1234\".<\/p>\n

Le premier processus est le m\u00eame pour les deux types de bases de donn\u00e9es. Une base de donn\u00e9es classique utilise l'index, y trouve l'adresse de la ligne et lit cet enregistrement \u00e0 cette adresse. Dans Hana, on lit l'index, on y trouve le num\u00e9ro de l'enregistrement et on r\u00e9cup\u00e8re dans chaque colonne la valeur \u00e0 cette position.<\/p>\n

Il existe \u00e0 nouveau des diff\u00e9rences dans la recherche : dans le cas d'une orientation par rang\u00e9e, on esp\u00e8re qu'il existe un deuxi\u00e8me index dans lequel se trouvent toutes les adresses des enregistrements d'items de vente qui appartiennent \u00e0 un ordre de vente.<\/p>\n

Dans le cas contraire, la base de donn\u00e9es n'a aucune chance et doit parcourir toute la table. Avec Hana, l'indexation est d\u00e9j\u00e0 assur\u00e9e par le mode de stockage. C'est un immense avantage pratique.<\/p>\n

Chacun de ces points - orientation des colonnes, compression, indexation et in-memory - pr\u00e9sente en soi des avantages et des inconv\u00e9nients. La caract\u00e9ristique unique de SAP Hana est que, m\u00eame aujourd'hui, cette base de donn\u00e9es est la seule \u00e0 combiner intelligemment tous ces points, de sorte que les avantages se combinent.<\/p>\n

Tout garder en m\u00e9moire est possible si l'on comprime. Organiser les donn\u00e9es en colonnes permet de mieux les compresser. Hormis les cl\u00e9s primaires, on n'a plus besoin d'index gr\u00e2ce \u00e0 l'organisation en colonnes et \u00e0 la compression.<\/p>\n

Comme toutes les donn\u00e9es se trouvent en m\u00e9moire, les requ\u00eates sur un ensemble complet de tables sont aussi rapides qu'avec un stockage orient\u00e9 par rang\u00e9e, on peut donc utiliser un stockage par colonne m\u00eame pour de telles requ\u00eates.<\/p>\n

En revanche, on gagne beaucoup avec Hana pour les cas normaux. Les requ\u00eates OLAP du type \"total des ventes par an\" sont tr\u00e8s rapides, car les donn\u00e9es sont d\u00e9j\u00e0 organis\u00e9es en colonnes.<\/p>\n

Les recherches sur n'importe quel attribut sont beaucoup plus rapides, car chaque colonne repr\u00e9sente en soi un index. Les requ\u00eates qui ne lisent pas 100 % des colonnes de la table sont plus rapides.<\/p>\n

Mais c'est pr\u00e9cis\u00e9ment l\u00e0 que le b\u00e2t blesse : Je suis parti du principe que toutes les donn\u00e9es \u00e9taient d\u00e9j\u00e0 en m\u00e9moire et qu'elles pouvaient y \u00eatre stock\u00e9es.<\/p>\n

N'est-ce pas un gaspillage de m\u00e9moire, et donc d'argent, que de toujours tout garder en m\u00e9moire vive (Random Access Memory), que l'on en ait besoin ou non ?<\/p>\n

SAP donne ici \u00e0 l'administrateur des possibilit\u00e9s d'optimisation : un premier point concerne les types de donn\u00e9es binaires (types de donn\u00e9es LOB, CLOB et NCLOB). Ils ne sont pas stock\u00e9s en m\u00e9moire, mais restent toujours sur disque.<\/p>\n

La m\u00e9moire contient le pointeur vers le fichier, mais pas le contenu. C'est une bonne id\u00e9e, mais elle n'est pas d'une grande aide, car de tels types de donn\u00e9es n'apparaissent gu\u00e8re dans un ERP.<\/p>\n

Premi\u00e8re utilisation<\/h3>\n

Optimisation suivante : les partitions ne sont charg\u00e9es en m\u00e9moire que lorsqu'elles ont \u00e9t\u00e9 utilis\u00e9es pour la premi\u00e8re fois, et non pas de mani\u00e8re pr\u00e9ventive. Ainsi, si une table se compose d'un milliard d'enregistrements, r\u00e9partis en dix partitions pour dix ans, seule la partition pour l'ann\u00e9e en cours serait charg\u00e9e en m\u00e9moire.<\/p>\n

C'est \u00e9galement une bonne id\u00e9e, qui r\u00e9duit le temps de d\u00e9marrage et l'utilisation initiale de la m\u00e9moire, mais au fil du temps, chaque partition aura \u00e9t\u00e9 utilis\u00e9e au moins une fois par quelqu'un. Ainsi, tout se retrouve \u00e0 un moment ou \u00e0 un autre dans la RAM et y reste jusqu'au prochain red\u00e9marrage.<\/p>\n

Il existe une fonction pour cela : la p\u00e9riode de r\u00e9tention. Avec ce param\u00e8tre, de telles partitions sont supprim\u00e9es de la RAM apr\u00e8s un temps d\u00e9fini sans aucun acc\u00e8s. Enfin un param\u00e8tre qui permet de supprimer des choses de la RAM. Attention, ce bouton est d\u00e9sactiv\u00e9 par d\u00e9faut !<\/p>\n

C'est d\u00e9j\u00e0 tr\u00e8s bien, mais il y a deux lacunes. La premi\u00e8re personne qui utilise ne serait-ce qu'un seul enregistrement d\u00e9clenche le chargement complet de cette partition en m\u00e9moire.<\/p>\n

Si une telle partition fait un gigaoctet, cela peut prendre deux secondes. Et tout cela ne sert \u00e0 rien si la base de donn\u00e9es compl\u00e8te n\u00e9cessite 1,1 t\u00e9raoctet de RAM alors qu'il n'y a qu'un t\u00e9raoctet disponible.<\/p>\n

C'est ici que la derni\u00e8re fonctionnalit\u00e9, la Native Storage Extension, vient \u00e0 l'aide. Ainsi, ce n'est plus la partition compl\u00e8te qui est charg\u00e9e, mais uniquement les pages n\u00e9cessaires qui contiennent ces donn\u00e9es.<\/p>\n

Et s'il n'y a pas assez de RAM, les pages inutiles sont supprim\u00e9es. De cette mani\u00e8re, on proc\u00e8de vraiment comme pour une base de donn\u00e9es classique sur disque et on utilise la RAM uniquement comme cache pour les tables avec ce r\u00e9glage.<\/p>\n

Donn\u00e9es multi-temp\u00e9ratures<\/h3>\n

Mais ce n'est pas ainsi que cela a \u00e9t\u00e9 con\u00e7u. Hana est une base de donn\u00e9es in-memory computing, toutes ( !) les donn\u00e9es utilis\u00e9es ( !) doivent donc \u00eatre disponibles en m\u00e9moire. Ce n'est qu'ainsi que les requ\u00eates OLTP et OLAP peuvent \u00eatre trait\u00e9es par la m\u00eame base de donn\u00e9es et que l'on obtient des temps de r\u00e9ponse courts et pr\u00e9visibles.<\/p>\n

Ces fonctions suppl\u00e9mentaires sont uniquement adapt\u00e9es aux donn\u00e9es multi-temp\u00e9ratures. Pour les donn\u00e9es qui sont utilis\u00e9es de temps en temps. Pour lesquelles l'utilisateur ne doit pas \u00eatre envoy\u00e9 dans une base de donn\u00e9es d'archives.<\/p>\n

Si j'utilisais ces fonctionnalit\u00e9s pour tous les tableaux et que je ne disposais pas de suffisamment de RAM, les inconv\u00e9nients du stockage en colonnes commenceraient \u00e0 se faire sentir. Je n'aurais plus tous les avantages sans les inconv\u00e9nients.<\/p>\n

Au lieu de cela, Hana repr\u00e9sente le point d'entr\u00e9e central pour les donn\u00e9es \u00e0 diff\u00e9rentes temp\u00e9ratures et cache les diff\u00e9rences physiques : l'utilisateur place ses commandes, certaines donn\u00e9es proviennent du magasin en m\u00e9moire, d'autres du disque, d'autres encore sont affich\u00e9es via la fonction Hana Smart Data Access d'un syst\u00e8me externe (\"Federated\"). L'utilisateur ne remarque rien, si ce n'est, le cas \u00e9ch\u00e9ant, des temps de r\u00e9ponse plus longs. Hana devient une Data Fabric.<\/p>\n

La physique est cach\u00e9e, mais elle est toujours pr\u00e9sente. La lecture des structures de donn\u00e9es Hana \u00e0 partir de la m\u00e9moire est plus rapide que celle \u00e0 partir du disque avec l'extension de stockage native.<\/p>\n

La rupture avec le Dynamic Tiering avec une base de donn\u00e9es SAP IQ en arri\u00e8re-plan est encore plus grande, car les structures de donn\u00e9es Hana ne sont plus utilis\u00e9es ici. L'interface est donc limit\u00e9e \u00e0 SQL.<\/p>\n

Et si l'utilisateur acc\u00e8de \u00e0 un syst\u00e8me externe par le biais de Smart Data Access, la r\u00e9ponse ne peut \u00eatre qu'aussi rapide que le syst\u00e8me externe le permet.<\/p>","protected":false},"excerpt":{"rendered":"

Reportage : Une br\u00e8ve histoire sur un long chemin - In-memory Computing avec la base de donn\u00e9es Hana :<\/p>\n

Lorsque les concepts de Hana ont \u00e9t\u00e9 pr\u00e9sent\u00e9s pour la premi\u00e8re fois au sein de SAP, je me suis dit que toute base de donn\u00e9es disposant de suffisamment de m\u00e9moire \u00e9tait apr\u00e8s tout une base de donn\u00e9es de calcul en m\u00e9moire et donc rapide. Mais au moins, je n'\u00e9tais pas le seul.<\/p>","protected":false},"author":1891,"featured_media":62755,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"pmpro_default_level":"","footnotes":""},"categories":[5,36593],"tags":[65,428],"coauthors":[36006],"class_list":["post-62754","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-it-management","category-mag-1910","tag-hana","tag-olap","pmpro-has-access"],"acf":[],"featured_image_urls_v2":{"full":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"thumbnail":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-150x150.jpg",150,150,true],"medium":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",400,180,false],"medium_large":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-768x346.jpg",768,346,true],"large":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"image-100":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-100x45.jpg",100,45,true],"image-480":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-480x216.jpg",480,216,true],"image-640":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-640x288.jpg",640,288,true],"image-720":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-720x324.jpg",720,324,true],"image-960":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-960x432.jpg",960,432,true],"image-1168":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"image-1440":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"image-1920":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"1536x1536":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"2048x2048":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"trp-custom-language-flag":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",18,8,false],"bricks_large_16x9":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"bricks_large":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"bricks_large_square":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"bricks_medium":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",600,270,false],"bricks_medium_square":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",600,270,false],"profile_24":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-24x24.jpg",24,24,true],"profile_48":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-48x48.jpg",48,48,true],"profile_96":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-96x96.jpg",96,96,true],"profile_150":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-150x150.jpg",150,150,true],"profile_300":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-300x300.jpg",300,300,true]},"post_excerpt_stackable_v2":"

Reportage: Eine kurze Geschichte zum langen Weg \u2013 In-memory Computing mit der Hana-Datenbank:<\/p>\n

Als die Konzepte von Hana das erste Mal innerhalb von SAP vorgestellt wurden, dachte ich, jede Datenbank mit gen\u00fcgend Memory ist doch eine In-memory-Computing-Datenbank und entsprechend schnell. Aber wenigstens war ich nicht der Einzige.<\/p>\n","category_list_v2":"IT-Management<\/a>, MAG 19-10<\/a>","author_info_v2":{"name":"Werner D\u00e4hn, rtdi.io","url":"https:\/\/e3mag.com\/fr\/author\/werner-daehn\/"},"comments_num_v2":"0 commentaire","_links":{"self":[{"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/posts\/62754","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/users\/1891"}],"replies":[{"embeddable":true,"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/comments?post=62754"}],"version-history":[{"count":0,"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/posts\/62754\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/media\/62755"}],"wp:attachment":[{"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/media?parent=62754"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/categories?post=62754"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/tags?post=62754"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/e3mag.com\/fr\/wp-json\/wp\/v2\/coauthors?post=62754"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}