Hana 3, quoi d'autre ?

Tout le monde sait que Hana n'a pas été conçu pour le cloud. Mais quel est le problème ? C'est là que l'article d'E-3 "Wir sind ERP" de l'auteur "no/name" paru dans E-3 février 2020 enfonce le clou : les coûts d'exploitation de Hana as a Service pour SAP lui-même.

Une base de données qui s'adapte automatiquement à la charge serait la solution optimale. Cela permettrait de maintenir les coûts d'exploitation à 100 % dans la plage optimale et de ne pas gaspiller les ressources.

Le souhait d'une évolutivité infinie est évident et compréhensible. Est-il réalisable, c'est l'autre côté de la médaille. Une anecdote de SAP : "Nous avons besoin de solutions disruptives, alors développez-les.

Allez, allez !" Il faut donc inventer quelque chose d'inédit au pied levé, le mettre en œuvre rapidement et déplacer les lois physiques comme ça, en passant. C'est difficile, non ?

Avec Hana 3, on touche exactement à une telle limite physique. Pour la mise à l'échelle infinie requise, les tâches doivent (a) pouvoir être décomposées en parties infiniment petites, (b) être exécutées en parallèle et - pour qu'il s'agisse toujours d'une base de données - (c) conserver malgré tout un ordre/une transactionnalité globale. Cela n'est pas possible. La contradiction interne des exigences doit être résolue par un compromis à au moins un endroit.

Effort et objectif

Mais si la mise à l'échelle infinie n'est qu'une méthode pour réduire les coûts, il existe peut-être une manière moins coûteuse de le faire ? Cela a déjà été tenté, les administrateurs Hana connaissent cette méthode sous le nom de Multi-Database-Container (MDC).

Le problème a été identifié comme étant le serveur d'index, le processus qui s'occupe de tous les traitements et du stockage des données dans Hana.

Dans le centre de données en nuage, chaque Hana a besoin d'un de ces grands processus de serveur d'index. Alors pourquoi ne pas installer une seule instance Hana par serveur et avoir des conteneurs de base de données indépendants ?

Le développement a donc retiré du serveur d'index tout ce qui n'appartient pas à une base de données et l'a transféré dans le serveur de noms : le stockage des données ? Non, on ne peut pas, c'est le cœur de la base de données.

Les requêtes ? La gestion des sessions ? En fin de compte, rien ne pouvait être supprimé. Résultat : chaque ordinateur exécute la SystemDB plus un serveur d'index par conteneur de base de données. Économie réalisée ? Pratiquement zéro.

Le serveur d'index

Comment pourrait-on réduire la taille du serveur d'index à la place ? Actuellement, il a une taille de 4 Go pour une base de données vide.

Il dispose d'un moteur SQL, d'un moteur Calc, de Spatial Queries, de Time Series et Graph Queries, de Document Store. La méthode la moins chère consisterait à supprimer une partie de ces fonctionnalités.

Mais l'un des avantages de Hana est justement son universalité. C'est ce que l'on trouve à juste titre sur tous les supports marketing. Il faudrait donc découper le serveur d'index d'une manière ou d'une autre, en une petite fonctionnalité de base et un composant dynamique dépendant de la charge.

L'un des principaux messages de Hasso Plattner il y a dix ans était qu'un ensemble de données est créé une fois et interrogé des centaines de fois. Plattner en a déduit qu'une base de données devait plutôt être optimisée pour la vitesse d'interrogation et que la performance d'insertion était secondaire.

L'ensemble de la base de données Hana ainsi que S/4 Hana sont construits autour de cette prémisse et c'est la raison de leur succès.

Pour notre serveur d'index, cela signifie que l'on éjecte tout le code qui s'occupe de la récupération des données. Vraiment tout ! La responsabilité du serveur d'indexation se réduit ainsi à la gestion des données et à l'exécution des modifications de données.

Le processus possède donc la RAM avec les données, il traite les instructions d'insertion, de mise à jour et de suppression. Le serveur d'index ne serait plus que le niveau de stockage en mémoire.

Les requêtes sont la partie complexe avec le Query Optimizer, les différents moteurs et le risque élevé d'avoir un bug. Il suffit à ces fonctions d'avoir un accès en lecture seule à la RAM du serveur d'indexation (mémoire partagée) et elles peuvent travailler de manière totalement indépendante les unes des autres.

Un autre avantage de cette approche : Que se passe-t-il aujourd'hui lorsqu'un utilisateur lance une requête et que le code se déchaîne à cause d'un bug ? Le serveur d'indexation tombe en panne et avec lui la base de données complète.

Si la requête est un processus distinct, peut-être même que chaque requête en cours d'exécution s'exécuterait dans un processus distinct, seule la session utilisateur s'effondre.

Il n'est toutefois pas facile de bien concevoir ce processus de requête.

Conteneur

À quoi cela ressemblerait-il en pratique ? Chaque client possède une image Docker avec Hana. Cette image est démarrée sur un serveur avec les données de performance achetées. Comme le serveur d'index est maintenant si petit, il peut être démarré très rapidement, si rapidement que la plupart des instances de développeurs peuvent même se mettre en veille et que l'image Docker s'arrête en cas d'inactivité.

Si un client a besoin de plus de ressources, son instance Hana est arrêtée et redémarrée sur l'autre matériel. Ou bien on va vers le scale-out, on démarre plusieurs instances Docker sur les mêmes fichiers de base de données et celles-ci se répartissent les données entre elles.

Le lieu d'exécution d'un conteneur, dans le centre de données en nuage ou chez le client, ne fait aucune différence.

Ce que j'ai décrit jusqu'à présent est une connaissance générale de la construction de bases de données. Il sera intéressant de voir quelle sera la base technique de Hana Cloud.