Cet article fait partie de notre guide: Ces nouveaux moteurs de l’analytique moderne

GPU, RAM et SSD : des turbos pour l’analytique

Les start-ups californiennes MapD, AeroSpike et GridGain ont développé une technologie de base de données ou de moteur SQL qui exploitent les caractéristiques de vélocité propre à la mémoire RAM, au SSD ou encore au GPU.

RAM, SSD ou pas, GPU ou CPU…lorsqu’il s’agit de raccourcir les délais pour générer les résultats de requêtes sur un grand volume de données (structurées ou pas), certains fournisseurs de technologies se reposent sur des méthodes d’accélération qui usent de contournements hardware.. C’est par exemple le cas d’AeroSpike, GridGain ou encore de MapD qui ont tous trois fait le choix d’architecturer leur solution autour d’un support hybride de la mémoire et/ ou du SSD et des accélérateurs graphiques ultra-parallélisés (pour MapD)

Tous ont fait le constat suivant : les solutions en place ne sont pas forcément adaptées à la volonté des entreprises qui ont aussi évolué dans leurs usages de l’analytique et des données. Ils y ont vu la nécessité de placer au cœur de leur architecture un moyen d’accélérer les requêtes les rendus, l’accès aux données sur de grandes quantités de données, qu’elles soient issues du monde transactionnel ou du monde déstructuré et ramifié du Big Data.

MapD : un moteur SQL gonflé aux GPU

Né au MIT,  MapD montre que les processeurs graphiques (GPU – Graphic Processing Unit) peuvent aussi s’appliquer au monde de l’analytique. La société a développé un socle Open Source, le MapD Core, qui est un fait une base de données en colonne et In-Memory douée d’un moteur de requêtes SQL adapté aux GPU. Ce moteur permet, selon la société, d’interroger des milliards de lignes en quelques millisecondes à partir de requêtes SQL.  Avec des résultats « 100x supérieurs » à ceux réalisés sur des traditionnels CPU.  Même si finalement, MapD Core fonctionne également sur les CPU : une technologie de VM de bas niveau compile en effet les requêtes pour de multiples architectures.

Evidemment, l’intérêt est de pouvoir parcourir et d’interroger de très grands volumes de données en un temps record, y compris celles qui nécessitent également un traitement particulier. Les données géospatiales sont d’ailleurs des invités de marques de MapD qui en a fait une des spécialités. Les autres cas d’usages sont l’analytique opérationnelle et bien sûr la data science. « Placer les données au plus proche du compute est aujourd’hui critique, d’où une gestion fine de la mémoire au niveau du GPU », explique le Tood Mostak, le Pdg de MapD.

Si on l’imagine que la parallélisation des flottes GPU constitue logiquement un gain de puissance inestimable pour la plateforme de MapD, cette capacité de compute permet aussi à la société de se passer d’index, a-t-il rappelé. Sans pré-aggrégat ni index, l’exploration des données et leur interrogation sont accélérées, au rythme de leur ingestion, elle-même considérablement renforcée.

MapD Core est aujourd’hui la fondation d’un projet Open Source, le GPU Open Analytics Initiative (GOAI) dont l’ambition est de travailler à un framework pour faciliter la data science sur les GPU.

A ce cœur est ouvert, MapD a associé un outil de visualisation de données (MapD Immerse), qui exploite au mieux les performances musclées des GPU. L’idée est ici d’accélérer les rendus – d’où l’intérêt de l’analyse des données géospatiales. Grâce au GPU, les images sont rendues directement sur le serveur. Mais MapD peut également se connecter aux outils tiers comme Tableau ou Qlik.

Enfin, MapD affirme être agnostique en termes de technologies GPU. La société a toutefois attiré l’attention de Nvidia. Celui-ci est même entré au capital de la société.

AeroSpike : une architecture hybride mémoire / SSD

De son côté, si AeroSpike adosse elle-aussi sa technologie de base de données clé/valeur sur-vitaminée à du In-Memory, la société a souhaité également tirer profit de la Flash et des disques SSD. Le moteur AeroSpike assurant une cohésion naturelle entre ces deux technologies. Cette base de données NoSQL qui s’apparente clairement à Redis – mais avec une architecture de type shared-nothing – s’appuie sur une mécanique optimisée pour stocker les données dans la RAM, sur disques SSD ou même sur disques durs classiques, si besoin. Afin d’accélérer l’accès aux données, les indexes sont placés dans la RAM et les données sont stockées sur les SSD.  Techniquement, explique AeroSpike, la technologie permet d’accéder directement aux blocs des disques pour doper les opérations d’écritures. Le SSD n’est donc pas là uniquement pour assurer le mode de stockage persistant mais s’inscrit en prolongement direct de la RAM. La société a également développé un modèle de donnée personnalisée et flexible qu’elle a souhaité structurer d’une façon proche d’un modèle transactionnel, mais avec sa spécificité clé – valeur, comme l’indique le site de l’éditeur. « C’est une illusion de dire qu’ajouter du SSD à n’importe quelle base va l’accélérer »,  a expliqué le co-fondateur d’AeroSpike, Srini Srinivassan. Vous devez aussi changer la structure des données. »

Si jusqu’alors AeroSpike se positionnait sur le marché des bases NoSQL haute performance et temps réel pour les systèmes hors transactionnels, la société a décidé de doter la version 4 de sa solution de possibilités de cohérence de données. Une avancée clé qui lui permet désormais de se positionner sur des cas d’usage plus transactionnels, voire de s’imposer comme base unique pour motoriser les opérations transactionnels et analytiques, le tout avec une dimension temps réel très marquée. « AeroSpike veut éviter aux entreprises d‘avoir à ajouter plusieurs couches entre les données et l’application. Elles peuvent ainsi supprimer leur étage de cache », reprend le responsable. Il ajoute : « Nous devons éduquer le marché massivement et dire aux entreprises qu’elles n’ont pas besoin de cette couche de cache. » Pour cela, AeroSpike pourra notamment compter sur ses travaux réalisés en collaboration avec Intel dont le but est d’optimiser les SDD Optane de Californien. Pour le moment, précise encore le patron de la société, ces travaux portent sur la réduction de la latence et pour le marché des services financiers ».

Toutefois, AeroSpike liste régulièrement les fournisseurs de SSD qu’il recommande pour fonctionner avec sa technologie. Un outil de benchmark pour évaluer les performances des SSD sur AeroSpike a également été développé.

Avec cette approche In-Memory + SSD, explique Brian Bulkowski, le co-fondateur et CTO de la société, les entreprises vont pouvoir réduire leur empreinte serveurs. Selon lui,  450 nœuds Cassandra deviendraient 60 nœuds AeroSpike.

GridGain : le tout en mémoire

Si SAP avait certes montré la voie – du moins dans le langage – des bases de données In-Memory, GridGain compte bien démocratiser le concept. La société a développé un cœur de base de données In-Memory, rapidement versé à l’Open Source au sein du projet Apache Ignite, autour duquel a été brodée une offre premium de services et de composants dédiés, à travers deux éditions distinctes.

Le principe de GridGain, et donc d’Ignite, est de s’insérer entre les bases et les sources de données – ce que soient des bases transactionnelles, NoSQL ou des clusters Hadoop –et de les monter en mémoire dans sa base afin d’en accélérer l’accès, via une interface SQL. Contrairement à AeroSpike, par exemple, GridGain met en avant son approche uniquement In-Memory, alors que la base NoSQL est aussi optimisée pour le SSD. Il souhaite surtout se voir comme un Hana Open Source, et considère son approche plus proche d’un Google Spanner « dont les jointures sont scalables », si l’on en croit Nikita Ivanov, le fondateur de la société, également CTO. Pour répondre aux desiderata du secteur financier, très présent dans la base client de GridGain, la société avait également ajouté des capacités de stockage persistant sur disque.

 

Pour approfondir sur Base de données

Close