Les vertus d'une base de données accélérée par GPU

La base de données SQL date des années 1970 et elle est devenue une norme ANSI depuis les années 1980. Mais cela ne veut pas dire que la technologie a cessé d’évoluer. Elle continue à changer, et l’une de ces évolutions se situe dans les bases de données accélérées par GPU. La taille des bases de données relationnelles a beaucoup augmenté : aujourd’hui, les sets de données se mesurent en pétaoctets et au-delà. Même avec l'avènement de l'informatique 64 bits et avec les téraoctets de mémoire pour répondre à ces besoins en calcul, les volumes de données sont très élevés - et les CPU ne sont pas capables de les traiter. C'est là qu’entrent en jeu les GPU. Le rôle des puces graphiques a évolué : de l’accélération 2D/3D, elles sont maintenant impliquées dans l'accélération tout court.

Nvidia a su prendre un virage magistral en faisant de ses puces une référence dans les tâches d'intelligence artificielle. Ces processus nécessitent de traiter de grandes quantités de données en parallèle et d'autres tâches pouvant profiter du traitement parallèle. Et si AMD commence, un peu, à rattraper son retard, Nvidia a pris une bonne longueur d’avance. Sauf que, pour ce qui est des noyaux, AMD reste encore très loin derrière. À titre de comparaison, les puces Xeon sont limités à un maximum de 22 cœurs, la puce Epyc d’AMD atteint 32 cœurs, et l'architecture de Volta de Nvidia compte 5120 noyaux. Quand on imagine plus de 5000 noyaux fonctionnant en parallèle sur des données, on comprend pourquoi les GPU ont eu un tel succès dans les projets de calcul massif. Le potentiel des GPU a aussi suscité l’émergence d’une nouvelle génération de bases de données, écrites à partir de zéro, capables d’exploiter la puissance des GPU et leurs énormes capacités de traitement parallèle. Ces bases de données ouvrent sur de nouveaux niveaux de traitement des données, d'analyse en temps réel et d’analyse big data, car elles peuvent de traiter des ensembles de données que les bases de données classiques animées par CPU ne peuvent tout simplement pas prendre en charge.

Qu’est-ce qu’une base de données GPU ?

Le concept de base de données GPU est assez simple : il met à profit le parallélisme des GPU pour accélérer le traitement des quantités massives de données. Le GPU est idéal pour accélérer le traitement des requêtes SQL, car le SQL effectue la même opération - généralement une requête - sur chaque ligne du set de données. Cependant, il ne s’agit pas simplement d’entasser des cartes Nvidia Tesla dans le serveur hébergeant une base de données Oracle. Les bases de données GPU ont été conçues et écrites à partir de zéro pour effectuer un traitement parallèle, à commencer par les opérations SQL JOIN. Les JOIN établissent une relation entre les colonnes de plusieurs tables d'une base de données et sont essentiels pour effectuer des analyses pertinentes. Les approches JOIN traditionnelles sur les anciens systèmes SGBDR ont été conçues il y a des années pour les CPU mono-core et ne sont même pas parfaitement adaptées au traitement CPU, et encore moins au traitement GPU.

Mis à part les JOIN, les bases de données GPU bénéficient d'un niveau de support conséquent, notamment :

• Des connecteurs pour les frameworks open source populaires, comme Hadoop, Kafka, HBase, Spark, et Storm.

• Des Pilotes ODBC et JDBC pour l'intégration avec les outils de visualisation et de BI existants comme Tableau, Power BI et Spotfire.

• Des API pour communiquer avec les langages de programmation populaires comme C++, SQL, Java, Node.js, et Python.

Dans quel cas utiliser une base de données GPU ?

Les bases de données GPU ne sont pas vraiment en concurrence avec les bases Oracle, SQL Server ou DB2. Elles sont utilisées pour permettre une prise de décisions en temps réel à partir de l’analyse de grandes quantités de données. Des opérations que les entreprises sont dans l'impossibilité de faire elles-mêmes parce qu'il y a trop de données à traiter ou que les outils d'analyse visuelle sont trop lents. Les fournisseurs de bases de données GPU ne veulent pas se substituer aux bases Oracle ou OLTP comme Teradata. D’ailleurs, les bases de données GPU ne ciblent pas les charges de travail SGBDR traditionnelles, mais les environnements OLAP/OLTP (traitement analytique en ligne et traitement transactionnel en ligne) et big data, qui doivent traiter des ensembles de données massifs en temps réel. Au lieu du traitement par lots qui dure plusieurs heures et beaucoup plus, les bases de données GPU permettent de délivrer les données en temps réel ou sur une base horaire.

La base de données GPU peut résoudre beaucoup de problèmes que le NoSQL essaie de résoudre, mais elle permet aussi d'utiliser les outils de requêtes structurées existants. Le recours au NoSQL implique également pour l’entreprise de réécrire tous ses outils SQL, alors que les bases de données GPU utilisent les outils SQL existants. « Selon nous, les gens vont réaliser qu'ils peuvent créer des systèmes multidimensionnels, appliquer des scénarios multiples aux données et les combiner », a expliqué Steve Worthington, architecte pour les solutions de technologies émergentes chez Datatrend Technologies, une société de conseil informatique qui utilise la base de données GPU SQream. « Les entreprises du secteur de la santé veulent utiliser les données de plusieurs systèmes et effectuer des analyses dans plusieurs bases de données parce qu'auparavant, elles ne pouvaient pas faire de références croisées et n'avaient aucun moyen d'accéder aux bases de données ». C’est le cas également des institutions financières qui utilisent les données d’analyse pour lutter contre la fraude et évaluer les risques. Aujourd’hui, elles font peut-être uniquement des vérifications sur les cartes de crédit, mais elles veulent effectuer des vérifications sur plusieurs comptes. Grâce à la puissance du GPU, elles pourraient croiser leurs données entre toutes les sources d'information en temps réel.

Un milliard de ligne contre 10 000

Pour Rich Sutton, vice-président des données géospatiales chez Skyhook, un fournisseur de services de localisation, la base de données GPU OmniSci utilisée par l’entreprise lui permet de visualiser des ensembles de données géographiques beaucoup plus importants que ce que lui permettrait une base de données CPU. « Je peux charger un milliard de lignes dans OmniSci, avec peu ou pas de latence, alors qu’une base CPU traditionnelle ne me permettait de voir que 10 000 lignes simultanément », a-t-il déclaré. « Les avantages sont énormes en termes de consommation de données et de latence massivement réduite ». Todd Mostak, CEO d'OmniSci, a raconté qu'un client lui avait dit que la vitesse d'OmniSci « réduisait le coût de la curiosité ». Ajoutant : « Ils font des requêtes qu'ils n’auraient pas osé faire auparavant ». Un client du secteur des services financiers lui a également dit qu'une requête de traitement qui prenait 18 heures dans une base de données traditionnelle ne prenait plus qu'une seconde, tandis qu'une entreprise de télécommunications lui a dit que des requêtes qui prenaient des heures s’exécutaient maintenant en moins d'une seconde.

L’autre domaine de choix pour les bases de données GPU est celui du big data en temps réel, domaine où Hadoop a échoué. Ami Gal, CEO de SQream, fournisseur de bases de données GPU, affirme que la promesse big data de Hadoop, à savoir, extraire tout le potentiel d’affaire de dizaines de pétaoctets de lignes données, n'a pas abouti pour cause de lenteur. « Spark est assez bon pour le déplacement et la transformation des données, mais quand il s’agit de traiter d'énormes quantités de données et de les déplacer, il faut activer des centaines de milliers de nœuds de calcul. Ça, c’est au-delà de ses capacités. Mais avec dix ou 15 nœuds, c'est beaucoup plus efficace », a-t-il déclaré. M. Worthington indique que les serveurs basés sur le GPU peuvent exécuter dans une seule unité de traitement l'équivalent de plusieurs unités de traitement massivement parallèle (MPP) alimentées par CPU. « Nous pouvons remplacer les racks de nœuds MPP par une demi-douzaine de nœuds, chacun contenant de deux à quatre GPU. Nous pouvons troquer un investissement de 10 millions de dollars par un investissement inférieur à 1 million de dollars », a-t-il ajouté.

Les bases de données GPU disponibles

Le GPU est également important pour les besoins de visualisation de grands ensembles de données géographiques de Skyhook. « Si vous avez un million d'appareils sur le terrain que vous interrogez une deux ou trois fois par minute, vous récoltez 2 milliards de lignes de données par jour. C'est tout simplement impossible à gérer avec une base de données traditionnelle. Alors qu’une base de données GPU permet de prendre en charge ces quantités de données », a encore déclaré Rich Sutton. Avant d'adopter OmniSci, Skyhook devait « hiérarchiser les données en pyramide » pour les visualiser par segments. Désormais, selon Rich Sutton, il est possible de voir la totalité de l'image. « Aucune autre solution réaliste ne nous permettrait de mettre toutes nos données en forme ».

Les bases de données GPU sont vraiment un phénomène de startups. C’est le cas de Brytlyt, SQream Technologies, OmniSci (ex MapD que nous avons visité en mars dernier), Kinetica (que nous avons rencontré en octobre dernier), PG-Strom, et Blazegraph. Leur mode de fonctionnement varie légèrement d’une solution à l’autre. Par exemple, OmniSci effectue la visualisation des données, tandis que SQream utilise des connecteurs pour les outils de visualisation comme Tableau, de sorte que chaque base doit être évaluée individuellement pour savoir laquelle correspond le mieux à vos besoins. Les grands éditeurs de SGBDR n'ont pas encore pris le relais, à l'exception d'IBM, dont la base DB2 Blu, une version spéciale de DB2 pour les charges de travail analytiques, supporte certains traitements GPU. Oracle et TeraData ont dit qu’ils travaillaient avec Nvidia, mais rien n’est encore sorti de ces partenariats. SQL Server de Microsoft ne supporte pas l'accélération GPU. Mais Ami Gal, le CEO de SQream, a entendu dire, sans pouvoir fournir d’informations plus précises, que tous les éditeurs de SGBDR essayaient d’ajouter une sorte de support GPU à leurs produits.