Dans le dernier article, nous avons vu qu’en remplaçant notre bonne vieille base de données relationnelle par SAP HANA, nous pouvons améliorer sensiblement les performances de notre application. Cependant, avec des gains de l’ordre de six fois, on est loin des possibilités que HANA peut nous offrir (et que SAP annonce dans sa documentation marketing !)

Pour vraiment tirer profit de la puissance de SAP HANA, il ne suffit pas de l’utiliser comme base de données lambda, il faut utiliser les possibilités de modélisation que la base nous propose, ce qui peut impliquer un remaniement totale de notre application métier.

SAP nous conseille, dans la mesure du possible, de traiter les informations au plus près de la base de données. Là où l’on a l’habitude de récupérer les informations dans la base de données et de les traiter dans la couche ABAP, avec HANA il va falloir revoir l’application, pour faire faire un maximum de traitements par HANA directement, et de ne donner que les résultats à la couche ABAP.
Pour ce faire, SAP a développé un langage de programmation natif à la base de données appelé SQLScript, et qui permet de faire des calculs au plus proche des données, pour éviter de devoit les faire transiter par le réseau pour les traiter en ABAP

Prenons par exemple une application BI-IP, ou l’on doit répartir une dépense de 1200€ sur l’année 2012. Par défaut, on prendrait le chiffre à répartir (1200), on diviserait par 12, et on enverrait à la base de données :

CALYEARCALMONTHMontant
2012#-1200
201201.2012100
201202.2012100
201203.2012100
201204.2012100
…etc.

Avec HANA, la fonction de répartition sera réécrite en SQLScript, et permettra de ne donner à la base de données que l’année et le montant. Tout le reste sera exécuté directement au niveau de la base de données – libérant ainsi de la puissance de calcul au niveau du serveur d’application, et du trafic et temps d’attente réseau.

Depuis toujours (pour ceux qui développent sous SAP depuis un moment) SAP nous « conseille » de faire très attention à nos SELECT. Ne pas prendre plus de champs dans la table qu’il n’en faut, ne pas sélectionner plus de lignes dans la table que nécessaire, ne pas faire trop de SELECT – privilégier l’utilisation des tables internes, etc, etc. Il faut dire que bien trop souvent, les conseils de SAP sont ignorés par les développeurs, qui n’hésitent pas à faire des « SELECT * » dans MARA pour trouver un code article, par exemple.

Pourquoi nous déconseiller de telles instructions ? Tout simplement à cause de la charge réseau (c’est vrai, ça n’a, in fine, rien à voir avec la base de données). Plus on sélectionne de colonnes, plus on sélectionne de lignes, plus il y a de données qui transitent par le réseau. Or le réseau est à peu près le système de « stockage » le plus lent qui soit. Bien plus lent que nos disques durs, et bien plus lent encore que la mémoire de nos serveurs. (Je sais, on ne stocke rien sur le réseau, mais quand on demande une information à une base de données qui se trouve sur une autre machine, voire dans une autre baie, c’est bien le réseau le facteur limitant).

Pour pallier à ces manquements, et pour améliorer encore plus une base de données HANA, SAP introduit des vues analytiques. La vue analytique (analogique à une vue SQL standard) sert à HANA à réduire au maximum la quantité de données pour permettre plusieurs choses :

  • Filtrer au plus bas niveau les données (filtrer sur le mandant, par exemple, ou bien ne considérer que les transactions en Euro)
  • Filtrer sur les colonnes – à partir d’une ou plusieurs tables, ne garder que les colonnes qui nous intéressent pour une tâche donnée
  • Réaliser les jointures entre tables au plus bas niveau – encore une fois pour ne pas avoir à véhiculer trop de données vers le serveur d’application.

Un deuxième type de vue proposé par HANA est la vue d’attributs. Un exemple typique est le lien dans BW entre un InfoObjet et son texte. Dans HANA on pourrait créer une vue sur l’InfoObjet qui fournirait automatiquement le texte de la valeur, et ce dans la bonne langue, sans qu’aucun code ABAP ne soit lancé sur le serveur.

Les vues analytiques d’HANA permettent, grâce à l’utilisation de SQLScript, d’effectuer des calculs directement au niveau de la base de données, de façon automatique. Le calcul se fait, sur le jeu de données résultant d’un SELECT, et le résultat du calcul devient une des colonnes du résultat.

Imaginons un rapport qui doit renvoyer pour un restaurant les ventes réalisés. Dans HANA (quelqu’un a déjà vu un restaurant capable de s’offrir un HANA ?) les ventes sont stockées TTC.

On pourrait imaginer une table de ce genre :

DateLibelléAlcoolTTC
20120314Verre de vinX5
20120314Assiette de pates 10

On souhaite que le SELECT nous donne les montants TTC, HT et le montant de la TVA. Sous HANA il suffit de créer une « mesure calculée » de type FLOAT qu’on va appeler ‘TVA’ et de lui attribuer la formule suivante :

If("ALCOOL" = ‘X’, "TTC"-"TTC"/1.196, "TTC"-"TTC"/1.07)

Un SELECT sur notre table de ventes donne maintenant une colonne supplémentaire :

DateLibelléAlcoolTTCTVA
20120314Verre de vinX50.81939799
20120314Assiette de pates 100.65420561

De cette façon nous économisons la quantité de données stockées (ce qui permet à HANA de garder plus de données en mémoire) et les différents calculs se font automatiquement à la lecture.

Nous avons vu ici une vue d’ensemble rapide des différents moyens qu’HANA met à notre disposition pour optimiser toujours plus les accès à nos données afin d’accélérer les applications. Le point principal qui transparait est que pour tirer meilleur profit d’HANA, il ne suffit pas de remplacer notre RDBMS traditionnel avec HANA (même si cela nous ferait gagner déjà pas mal de temps), mais une refonte totale de notre application est nécessaire – il faut revoir nos accès aux données, revoir chaque type de calcul que l’on fait pour essayer de ramener les actions au plus près de la base de données.

Laisser un commentaire