Hazelcast veut unifier in-memory et streaming de données

Seul, l’in-memory ne suffit pas

La nouveauté tient dans le fait que les deux technologies sont intégrées dans un cluster Java, optimisé pour assurer la coexistence des charges de travail des grilles de données en mémoire, avec celles réservées au streaming, affirme le CTO. Cette plateforme doit fournir un runtime unique dont le rôle est de répartir les ressources de calcul et de stockage à la hausse ou à la baisse, ce qui est censé apporter de meilleures performances.

« Ce que cela signifie pour les utilisateurs, c’est qu’ils n’ont plus qu’un seul cluster à gérer », souligne John DesJardins.

Avec cette combinaison au sein de la plateforme Hazelcast, il doit être possible d’interroger les données en temps réel ainsi que les données au repos dans une approche unifiée.

Kelly Herrell, PDG d’Hazelcast, explique qu’avec Hazelcast IMDG d’un côté et Jet de l’autre, les utilisateurs doivent encore déplacer les données et composer avec deux moteurs de requêtes SQL possédant leur propre syntaxe, afin de supporter les différents workloads.

Ce ne serait plus le cas avec Hazelcast Platform 5.0, qui dispose d’un moteur de requête et d’un langage ANSI SQL communs pour le streaming d’événements et les données en mémoire. « Avec notre langage de requête dans Hazelcast Platform, peu importe que vous interrogiez les données en temps réel ou les données stockées, il s’agit de la même syntaxe SQL », insiste le PDG.

Kelly Herrell assure que l’unification du streaming d’événements et des données en mémoire réduit également la latence, de sorte que les entreprises peuvent recourir aux données en temps réel dans les applications analytiques, transactionnelles et autres.

Selon John DesJardins, il est possible d’utiliser la plateforme pour l’inférence de modèles de machine learning en temps réel et en batch avec pour avantage de « colocaliser le modèle avec les données ». Surtout, l’éditeur complète ses commandes SQL (et donc ses capacités analytiques) en permettant de faire des inserts, des mises à jour et des suppressions de données. Pour rappel, Hazelcast est à l’origine un data store NoSQL.

Mike Gualtieri, analyste chez Forrester Research, voit d’un bon œil la réunion de ces deux technologies.

« Les applications modernes et notamment les applications d’IA doivent réagir en temps réel », déclare-t-il. « Avec Hazelcast, les entreprises peuvent obtenir un data store in-memory robuste et des fonctions analytiques. Cela simplifie grandement [la mise en place] des architectures temps réel ».

Avec la réunion de ces deux produits, Hazelcast refond également ses cycles de mise à jour pour ne proposer qu’une seule feuille de route imposant une temporalité commune à IMDG et à Jet.

Anticipant les questions des clients existants, Hazelcast assure la compatibilité de la version 5.0 de sa plateforme avec les itérations 4.x d’IMDG et de Jet. IMDG est disponible en version 4.2 depuis mars 2021 et Jet en version 4.5 depuis le mois d’avril.

En revanche, l’entreprise ne dévoile pas la politique tarifaire qui accompagne la disponibilité de Hazelcast Platform.

Prochaine étape pour la plateforme Hazelcast : plus de persistance

Parallèlement à l’intégration de Jet et d’IMDG, l’éditeur entend étendre la nouvelle plateforme Hazelcast au-delà de ses racines in-memory et proposer des options de persistance de données.

Selon John DesJardins, certains clients ont déployé une base de données en parallèle d’IMDG, pour l’unique raison qu’IMDG n’écrit pas les données sur le disque, du fait de son statut de data store in-memory.

Avec Hazelcast Platform, le CTO introduit une capacité de persistance « durable ».

Cela signifie que les utilisateurs peuvent accéder à leurs données, même après avoir redémarré ou arrêté un cluster. Les informations en mémoire sont ainsi stockées au repos afin de réaliser des traitements batch, mais aussi de les récupérer en cas de crash du système.

John DesJardins affirme que Hazelcast prévoit le développement d’autres fonctions de persistance à l’avenir, notamment en proposant un système de stockage hiérarchisé.

Le reste de la feuille de route s’organisera « autour de cinq thèmes principaux : la convergence des données et des cas d’usage, le machine learning à l’échelle, l’automatisation, la démocratisation et le temps réel ».

À ce jeu, l’entreprise suit les traces de SingleStore (ex-MemSQL) qui a introduit en juin dernier un troisième tiers de stockage pour les données persistantes en sus des traitements OLTP et OLAP déjà pris en charge par sa plateforme de base de données. GridGain a fait de même en janvier 2021. Tout comme SingleStore, Redis affirme également avoir franchi le pas pour passer du statut du spécialiste de l’in-memory à celui de généraliste de la gestion de données.

Tous ces acteurs veulent proposer le support des workloads de machine learning, mobile et IoT. Pour autant, Hazelcast n’a pas les mêmes ambitions. Il préfère lancer des partenariats avec les fournisseurs de cloud ou d’autres éditeurs et mise davantage sur ses capacités de traitement en temps réel plutôt que se considérer comme un généraliste. Pour information, en juillet 2021, HazelCast est à la cinquantième place du classement réalisé par DB-Engines, Redis y est sixième et SingleStore figure à la soixante-septième position.