SAP se penche sur les bases de données en colonnes et en mémoire

Depuis maintenant trente ans, les bases de données relationnelles se sont imposées comme la meilleure solution pour assurer les traitements transactionnels des applications d’entreprise (en particulier des ERP). En parallèle, les bases de données dites « en colonnes » ou « vectorielles », se sont développées pour quelques applications décisionnelles pointues. Ces bases de données vectorielles ont été inventées dès le début des années 70, mais leur performance impressionnante dans la manipulation de données décisionnelles ou statistiques n’a d’égal que leur lenteur dans le support des applications transactionnelles. Cela explique sans doute le succès des bases de données classiques, qui se révèlent généralistes et moyennement efficaces dans tous les domaines.

Aujourd’hui encore des solutions comme Sybase IQ, Vertica ou encore Harry Software s’appuient sur cette technique pour proposer à leurs utilisateurs des temps de réponse largement améliorés dans le traitement des données décisionnelles.
L’idée de SAP est de démocratiser ces bases de données en colonnes pour leur faire prendre en charge l’ensemble des traitements transactionnels de l’ERP. Si l’éditeur y parvient, il aura alors en main une carte majeure pour évincer Oracle de chez ses clients.

La baisse continue du prix des mémoires vives et l’augmentation de la puissance des serveurs permet de combiner l’efficacité des bases vectorielles et la rapidité des traitements en mémoire. A Sapphire, Hasso Plattner a ainsi présenté une base de données vectorielle fonctionnant en mémoire, sur un serveur équipé de 144 Go de mémoire vive. Sur cette configuration, SAP serait parvenu à traiter 280 millions d’enregistrement en moins d’une seconde ! Et le serveur utilisé n’aurait couté que 6000 dollars.

Principal défaut de cette configuration, la dépendance vis à vis de la mémoire. En effet un SGBD classique écrit chaque transaction sur disque et assure un suivi de chaque opération, permettant ainsi de revenir en arrière en cas d’erreur matérielle ou d’incident. Ces processus de contrôle n’existent pas encore dans les bases de données en mémoire et en cas de plantage de la machine ou tout simplement d’incident électrique, il risque d’être difficile de reconstituer l’état de la base juste avant l’incident. C’est une des raisons pour lesquelles les bases en mémoire sont actuellement utilisées pour des applications non critiques qui permettent de recharger la totalité de la base en cas d’incident.

Les autres éditeurs travaillent également sur le sujet. Oracle propose à ses clients la base TimesTen qui fonctionne en mémoire, mais l’éditeur aura du mal à envisager sa généralisation de peur de cannibaliser sa source principale de revenu.
Même si SAP est encore loin de la solution commercialisable, et n’a d’ailleurs rien voulu dévoiler sur le socle technologique de ses recherches, la démonstration de force est intéressante et montre que des progrès majeurs peuvent être attendus en terme de performance dans les prochaines années. Elle montre également que le choc des titans entre les deux concurrents/partenaires que sont Oracle et SAP, va connaître de nouveaux développements dans le même horizon temporel.

Pour creuser le sujet, et si vous parlez couramment la langue de Goethe, fouillez du côté de http://www.hpi.uni-potsdam.de/ où serait développé ce nouveau projet de base de données.
A lire également, en anglais cette fois, le billet de Jeff Nolan qui a suivi la conférence SAP Academic Research 2009 : http://siliconangle.net/ver2/2009/08/21/live-coverage-from-the-sap-academic-research-conference/

Et pour le vivre en différé, vous trouverez ci-dessus une vidéo capturée pendant la présentation de cette piste de recherche.