Actualites

AWS fait une place aux données chronologiques sur son cloud et muscle Aurora et DynamoDB

Le groupe a présenté une base de données time-series nommé TimeStream, entièrement bâtie sur une architecture serverless. Le groupe a enrichi également ses bases maison DynamoDB et Aurora.

Cyrille Chausson
par
Publié le: 29 nov. 2018

Parce qu’il convient d’apporter « la bonne base pour le bon cas d’usage », AWS a décidé de répondre à celui des données propres à l’IoT et à l’IT de proximité (Edge Computing) en proposant désormais sur son cloud un service managé de base de données dites Time-Series, TimeStream.  

Ces bases de données ont la particularité d’être adaptées aux données chronologiques. Ces données correspondent en fait à des mesures prises à intervalle régulier (par des capteurs par exemple) afin de dégager des indicateurs de changement et de variations dans le temps.

Cette particularité rend ainsi peu praticables les bases de données relationnelles, a expliqué Andy Jassy , le CEO d’AWS, rappelant la difficulté à mettre en place une telle base avec les technologies traditionnelles. Autre constat, appuie-t-il : les bases time-series du marché requièrent des travaux d’intégration avancés et ont du mal à passer à l’échelle. Parmi les pure-players du marché, on retrouve notamment InfluxData et sa base InfluxDB (celle-ci s’adosse à des technologies open source). Mais ce segment de marché est également peuplé d’éditeurs de base NoSQL comme MongoDB ou encore DataStax qui se positionnent sur ce cas d’usage de plus en plus tendance.

Avec TimeStream, AWS veut apporter sa vision de cette technologie. Cette base a donc été développée « from scratch » par les équipes du groupe et embrasse une architecture serverless, comme Aurora par exemple.

Afin de proposer une scalabilité forte, AWS a développé une couche stockage adaptée aux données chronologiques, mais a également apporté des fonctions de gestion du cycle de vie des données, reprend Herain Oberoi, Product Marketing for AWS Databases and Analytics. Cela  permet d’appliquer des politiques spécifiques aux données, comme de déclencher leur archivage lorsqu’elles sont considérées comme désuètes. Une aubaine lorsqu’il s’agit de manipuler des données en flux continu, propres à l’IoT.

Des travaux ont été menés dans l’ingestion de flux de données. Pour faciliter cette procédure, souligne le responsable, AWS permet de s’appuyer sur son service Kinesis ou sur des connecteurs intégrés à la base.

Le service intègre nativement des fonctions analytiques à appliquer directement sur les données stockées dans la base, ce qui selon lui tranche avec l’approche du marché.

AWS dispose d’un catalogue de services de bases de données de plus en plus étendu dont la vocation n’est pas d’avoir une approche multi-modèles, mais de confronter chaque service à des cas d’usage spécifiques et adaptés. AWS propose plusieurs déclinaisons de base relationnelles avec RDS et Aurora, DynamoDB pour le modèle Document / clé-valeur, Amazon ElastiCache pour le In-Memory et Neptune pour les graphes (et Timestream pour les données chronologiques).

Suivant ce principe, AWS a décidé d’habiller DynamoDB et Aurora de nouvelles fonctions pour affirmer leurs cas d’usage.

ACID pour DynamoDB, géo-réplication pour Aurora

Ainsi, DynamoDB supporte pour la première fois les transactions ACID via une fonction nommée Transactions. « Les clients souhaitaient réaliser des transactions entre plusieurs tables, et coder la logique des transactions au niveau de l’application. Transactions répond à ce besoin en fournissant une seule API pour intégrer ce modèle, directement à partir de DynamoDB. « Il est désormais plus facile de créer des applications transactionnelles avec DynamoDB », commente Herain Oberoi. Il n’est plus nécessaire d’ajouter du code à façon, l’API apporte la fonction. Selon le responsable, cela ne va transformer la base NoSQSL en une base purement transactionnelle, mais répond à certains cas d’usage, comme « réaliser plusieurs PUT end GET entre plusieurs tables et souhaiter de la cohérence dans ces transactions ».

De son côté, Aurora se retrouve doté d’une capacité nommée Global Database. Cette fonction permet de créer des réplicas de la base entre deux régions AWS distantes dans le monde, avec la promesse d’une latence très faible, en dessous de la seconde. « Si votre application est distribuée à l’échelle mondiale et nécessite d’accéder à des données locales très rapidement, Global Database est faite pour cela », résume Herain Oberoi.

Un des gains est bien de rapprocher l’application au plus près des données - stockées dans une région particulière - et au plus près des clients. Mais cette fonction a aussi son cas d’usage dans des scenarii de reprise après sinistre, affirme-t-il.

Pour approfondir sur Applications et services