Origines
La création de HANA par Hasso Plattner est partie d'un constat simple sur l'évolution de l'informatique : la technologie des disques se meurt. Or, toute la gestion des systèmes de fichiers repose sur gestion des disques et les systèmes de base de données repose sur la gestion de fichiers. Les éditeurs de base de données propose de plus en plus de mettre en cache les données, c'est à dire en mémoire mais les bases du système étant mauvaises, il s'agit juste d'un contournement sur une solution mourante.
La solution ? Changer de paradigme : avoir une base de données basée sur la mémoire et la vitesse des processeurs et ne plus utiliser les disques que pour conservation des données. Cette solution, c'est le "In-Memory".
L'autre caractéristique de HANA est d'être à la fois une base données en colonne et en ligne alors que les bases de données traditionnelles sont des bases de données en ligne. HANA stockera en ligne ou en colonne en fonction de l'efficience pour les données stockées.
Afin de vous expliquer de façon simple la différence entre un stockage en ligne et un stockage en colonne, voici un petit exemple.
Dans une base de données en ligne, les données sont stockées en ligne et chaque ligne a un identifiant ou clé. Dans une base de données en colonne, les informations sont stockées en colonne et l'identifiant unique est la données elle-même. Cela a plusieurs conséquences:
1/ Comme vous pouvez le constater dans le tableau "Données en colonnes optimisées", il y a un gain de place, il y a moins de données redondantes.
2/ Si je dois retrouver un enregistrement à partir d'un nom, ou connaître le nombre d'enregistrement avec le prénom "Marie", avec une base en ligne, je dois lire toute la table, tandis qu'avec une base en colonne, le plus souvent une lecture simple suffit.
3/ Ajouter un champ supplémentaire avec une valeur unique va être beaucoup plus rapide sur base en colonne.
4/ A contrario, Modifier une base de données en colonne, par exemple changer le prénom du quatrième enregistrement de Marie en Julie est beaucoup plus compliqué.
C'est pour cela que des bases de données en mémoire telles que Sybase IQ, maintenant SAP IQ sont très efficaces pour des bases analytiques (OLAP) alors que des bases en ligne telles que Oracle sont plus efficace sur des données Transactionnelles (OLTP). La force de SAP est d'avoir réussi à combiner le meilleur des deux mondes pour avoir une base de données plus efficace et rapide aussi bien pour du transactionnel que du décisionnel.
Flexibilité
D'une part, les requêtes sur une base HANA peuvent être exécutées 400 à 900 fois plus vite que sur une base de données relationnelle classique. D'autre part, les agrégats ont peu d'intérêts sur les bases en colonnes. On voit bien si on reprends l'exemple précédent qu'il est relativement facile d'obtenir la somme des salaire des prénoms "Marie". La conséquence logique est la suppression des agrégats avec HANA. Or, les agrégats s'ils permettent aux bases de données relationnelles d'être plus rapide, ils les obligent à être moins flexible. Prenons l'exemple d'un cube dans SAP BW où vous souhaiteriez rajouter un champ calculé. Sans HANA, vous devez rajouter le champ dans la structure du cube puis recharger le cube. Avec HANA, le cube qui est agrégat, n'existent plus et sont transformés en sorte de cube virtuels, les calculs sont donc effectués en temps réel à la volée sans stockage supplémentaire de données. Il n'y a donc plus de chargement de données à faire. En fonction du volume du cube, cette opération peut durer des heures. Cette opération peut être renouvelée plusieurs fois, en cas d'erreur de calcul, de changement de règle ... On voit bien les gains potentiels d'une solution gérée sous HANA.
De même, on voit bien les bénéfices potentiels sur l'ERP avec les possibilités de faire des clôtures, des consolidations en temps réels.
Licences
Matériel
Plusieurs constructeurs propose maintenant des appliances HANA.On peut citer Fujitsu, HP, IBM, Hitachi, Cisco, Dell pour n'en citer que quelques un. Chaque matériel devant être certifié par SAP, les configurations restent assez similaires mais chaque constructeur peut avoir des particularités. Un serveur HANA se caractérise par beaucoup de mémoire, des processeurs avec de nombreux cœurs, d’ailleurs SAP impose un ratio CPU / Mémoire. Chaque appliance se voit doter de nombreux disques. Si au début, les serveurs intégraient systématiquement des accélérateurs de disques (Cartes Fusion IO) ou disques SSD, certains constructeurs arrivent maintenant à s'en passer. Cela reste une bonne nouvelle car cela devrait permettre de réduire le coût des appliances. Le prix d'une appliance varie fortement en fonction de la mémoire utilisée. En 2014, il faut compter entre 70 K€ et 80K€ pour un serveur 1 To.
Aucun commentaire:
Enregistrer un commentaire