Avec In-Memory, SAP pense refaire le coup de R/3, en secouant le monde des bases de données
Futurologie, manière de faire patienter le marché ? Cette semaine, lors de SAPphire, Hasso Plattner, co-fondateur de SAP, a fait taire les sceptiques, en montrant les premières bases de données reposant sur la technologie In-Memory appliquées au transactionnel. Pour l'éditeur d'ERP, cette innovation va changer la donne dans le progiciel, en unifiant le stockage de données pour le transactionnel et le décisionnel.
Dans un discours très attendu en clôture de SAPphire, l'événement du premier éditeur européen qui se déroulait cette semaine simultanément à Francfort et à Orlando (Etats-Unis), Vishal Sikka, le directeur technique de SAP (ci-dessous), et Hasso Plattner, son co-fondateur, ont réservé une surprise à l'auditoire. Alors que le marché - LeMagIT y compris - restait sceptique quant à la capacité de SAP à mettre rapidement sur le marché une base de données utilisant le stockage en colonnes et le chargement de l'intégralité des données en mémoire vive pour les systèmes transactionnels, les deux dirigeants ont dévoilé l'avancée des travaux maison sur le sujet, s'appuyant sur les recherches du Hasso Plattner Institute, un institut de recherche basé à l'Université de Postdam et à Palo Alto et financé par le co-fondateur de l'éditeur.
En ligne de mire directe, un premier produit commercial - une appliance baptisée High Performance Analytic Appliance conçue avec HP et IBM - promis pour la fin de l'année. Et une première implémentation chez un grand client de l'éditeur, dont le nom n'a pas été dévoilé. Tout en précisant - ce qui n'avait pas été fait jusqu'alors - que c'est bien cette nouvelle base, reposant sur du stockage en colonnes, qui motorise SAP Business ByDesign, l'ERP pour PME en mode Saas qui doit être commercialisé en masse à partir de juillet, après plusieurs décalages de calendrier.
Une annonce choc, car la date de commercialisation de ce type de solutions était jusqu'alors plutôt attendue vers 2012 ou 2013. A tel point que le rachat récent de Sybase, qui dans ses activités décisionnelles manie le stockage en colonnes (dans IQ) et le chargement des données en mémoire (dans sa base ASE), avait été interprété comme une façon d'accélérer ce calendrier. Voire simplement de le tenir. Jusqu'à aujourd'hui, les systèmes In-Memory ont en effet été exploités uniquement par des systèmes décisionnels afin d'accélérer les requêtes. Notamment chez SAP dans BW Accelerator ou Explorer.
Sybase n'était pas attendu en renfort
Spécialiste des bases de données et du stockage en colonnes, Sybase, sur lequel SAP a déclaré vouloir mettre la main, pouvait être vu comme un renfort de choix pour la conception de la nouvelle base de données de SAP. Sauf que, comme on le sait maintenant, le travail sur le sujet est plus avancé qu'attendu avec la sortie des premières appliance avant la fin 2010. Si Vishal Sikka, le directeur technique de l'éditeur, a écarté, lors d'une conférence de presse précédant l'annonce, tout lien entre le rachat de Sybase et la sortie de la base In-Memory, d'autres officiels de SAP voyaient encore quelques heures avant la conférence de Vishal Sikka et Hasso Plattner les technologies de Sybase comme une façon d'accélérer sur le sujet des bases de données In-Memory. Le secret était donc bien gardé, y compris en interne.
Rappelons que Sybase est un spécialiste des bases de données et possède au catalogue une technologie éprouvée de stockage en colonnes (IQ), utilisée dans des applications décisionnelles surtout dans la finance, ainsi qu'une base de données relationnelle (ASE). SAP a d'ores et déjà prévu de supporter ASE dans Business Suite, son ERP phare. ASE dispose déjà d'une option In-Memory.
"Beaucoup pensaient que c'était impossible"
"Plusieurs fois ces dernières années, j'ai parlé des travaux que nous menions à l'université de Postdam, visant à transférer ces bases de données In-Memory (littéralement en mémoire, NDLR) et reposant sur du stockage en colonnes vers les systèmes transactionnels. Nombreux sont ceux qui pensaient que c'était impossible", a noté Hasso Plattner. Avant de préciser que l'impulsion décisive a été donnée voici un an, par la fusion de trois équipes travaillant chez SAP sur les bases de données. Dont celle de MaxDB, la base de données relationnelle maison.
Se basant sur les résultats obtenus chez un grand compte test (avec une base de 2,5 To contenant 74 000 tables et 4,7 milliards d'enregistrements, transférée sur une appliance In-Memory renfermant 250 Go de Ram), Vishal Sikka a expliqué que cette nouvelle base supprimait le besoin de créer des agrégats dans des entrepôts de données dédiés au décisionnel, offrait des performances de l'ordre de 2 Mo/ms par cœur processeur (SAP promet des appliance avec 64 cœurs logiques Intel Nehalem et 128 cœurs en 2011), et, grâce à la compression qu'autorise le stockage en colonnes, des volumes de données 10 à 50 fois inférieurs à ceux des bases traditionnelles. Autrement dit, un SGBDR renfermant 10 To se voit réduit à 1 To de mémoire vive au maximum, garantit SAP. La sauvegarde et la persistance étant assurée par des disques SSD (à base de mémoire Flash) dans l'exemple présenté par le co-fondateur du premier éditeur européen.
Une seule base pour transactionnel et décisionnel
La réelle avancée de cette "nouvelle base de données" (qu'on pourrait appeler MaxDB In-Memory) se situe dans sa polyvalence. Elle supporte à la fois les systèmes transactionnels - l'ERP donc -, mais également la partie décisionnelle. Supprimant le besoin de charger les données de la base relationnelle dans des entrepôts via des outils d'ETL. "Avec cette architecture, on effectue les requêtes directement sur le système transactionnel, accélérant les temps de réponse par des facteurs de l'ordre du millier, voire de la dizaine de milliers. Et on peut effectuer des requêtes impossibles auparavant, comme des requêtes directes sur des niveaux de profitabilité", a expliqué Vishal Sikka. "Intellectuellement, je n'ai jamais été satisfait de cette architecture consistant à faire du décisionnel un système séparé", a ajouté Hasso Plattner. La nouvelle MaxDB In-Memory embarque donc directement un moteur OLAP.
Au-delà de la sortie de ces produits - qui pourraient passer pour un nouveau hype technologique pour une base installée qui peine à évoluer -, SAP a garanti que les grands comptes sous Business Suite (son ERP majeur actuel), mais aussi sous R/3 (jusqu'à la version 4.6) pourront tirer parti de In-Memory. Ces appliances accéléreront aussi les entrepôts BO et BW. Le tout sans rupture et sans risque, ont martelé les deux dirigeants. De facto, Hasso Plattner a détaillé un chemin de migration, permettant de passer de la base de données actuelle, suppléée par un entrepôt de données pour le décisionnel, à l'architecture cible de SAP, où ERP et outils de reporting viennent attaquer la même base.
Migration : la politique des petits pas
Démarrant par la mise en place de l'appliance répliquant la base de données en fonctionnement, en parallèle de l'architecture existante, pour aboutir à l'élimination du SGBDR actuel et de l'entrepôt de données, le projet de migration présenté par Hasso Plattner (ci-dessous) privilégie la politique des petits pas. "Les entreprises n'ont ni le temps, ni les ressources en termes de personnel, ni l'argent pour s'engager dans des projets de migration lourds. Et même si elles les avaient, elles ne souhaitent pas prendre de risque avec les systèmes en place", a-t-il justifié. D'où une mise en place par étape et la garantie que l'ERP en place, qu'il s'agisse de Business Suite ou de R/3, ne sera pas affecté par les changements sous-jacents. Reste toutefois à préciser la réelle équation économique de cette migration, même si SAP assure que chacune des 4 étapes détaillées par son co-fondateur amène des gains, même prise isolément.
Pour Hasso Plattner, In-Memory s'apparente à une innovation susceptible de changer les règles du jeu dans l'informatique d'entreprise. Non plus par les apports fonctionnels, mais bien par un bouleversement des architectures, comme l'avait fait R/3 en 1992. Un bouleversement qui remet en cause la place des principales bases relationnelles sur lesquelles reposent aujourd'hui les environnements SAP : IBM DB2, Microsoft SQL Server et surtout Oracle bien sûr. Un partenaire, mais surtout un rival, qui doit son succès notamment aux besoins de performances des grands ERP, donc largement à SAP. Aujourd'hui, Oracle voit ce dernier reprendre son destin en mains en proposant une alternative à ses moteurs de bases de données, qui ont des années durant servi l'expansion des ERP avant, du fait de la complexité des relations entre les deux environnements, d'en geler l'évolution. "Une fois le changement de base de données effectué, je n'arrive pas à penser à une modification qui puisse prendre plus d'une heure, a expliqué Hasso Plattner, faisant référence notamment à l'ajout d'attributs dans des tables. Ce n'est pas que nous voulions chasser les éditeurs de bases de données traditionnelles, mais, avec le temps, ces technologies sont devenues superflues."
En complément :
