Choisir sa base de données IoT en cinq étapes

Comment choisir la bonne base de données IoT

En suivant ces cinq étapes, les responsables SI peuvent réduire le nombre de bases de données nécessaires au fonctionnement d’un projet IoT intégré avec un système existant.

1. Identifier les types de données que la base de données va stocker et gérer

Par nature, les données IoT sont aussi variées que les cas d’usage eux-mêmes, mais elles peuvent être classées dans plusieurs catégories dont :

- Les métadonnées des objets connectés. Ce sont des informations généralement statiques comme l’identifiant de l’appareil, sa classe, sa date de fabrication, son numéro de série, sa configuration actuelle ou encore la version de son firmware.

- Les informations sur l’état des équipements. Ces données indiquent si l’appareil est allumé, éteint, passif ou actif, connecté ou non, en phase de récolte ou non, etc. Cette fois-ci ces informations dynamiques, envoyées à intervalle régulier ou en continu.

- Les données de télémétrie. Généralement, elles renseignent l’objectif d’un capteur IoT. Un capteur hygrométrique communiquera certaines valeurs sur une quantité d’eau ou sur un taux d’humidité. Là encore, elles sont collectées en continu, à intervalle régulier ou suivant un seuil défini par l'administrateur.

- Les ordres de commande. Ils servent à contrôler l’actuateur ou l’appareil pour déclencher des actions : ouverture/fermeture, démarrage d’un moteur, accélération de la cadence d’un tapis, etc.

- Les données opérationnelles. Elles indiquent les performances des composants de l’équipement lui-même : utilisation du CPU et de la mémoire, température, etc.

De nombreux néophytes se concentrent sur les données de commande et de télémétrie, puisqu’elles sont essentielles à l’exécution du cas d’usage. Or les données de gestion (métadonnées, état des appareils, informations opérationnelles) sont également primordiales. Sans elles, pas de jumeaux numériques ou de maintenance prédictive. Il est tout de même possible de collecter l’ensemble de ces informations via un seul format, JSON, par exemple.

2. Cartographier les flux de données

Les chefs de projet IoT doivent identifier où les différents types de données sont collectés, agrégés, analysés ou transformés, ainsi que la manière dont celles-ci s’intègrent avec d’autres systèmes. Peuvent-elles être enrichies et faut-il toutes les stocker avec les logs associés ? Veillez à identifier les zones de stockage et de réplication des données. Y aura-t-il un stockage canonique des données via un modèle commun ? Prévoyez où, quand et dans quelles circonstances elles seront archivées.

3. Lister les exigences fonctionnelles

Après avoir défini le type de données et les flux associés, l’étape suivante consiste à adapter la base de données aux exigences fonctionnelles.

- L’ingestion et l’agrégation. Les données IoT sont souvent analysées en parallèle de leur collecte et de leur agrégation, en temps réel ou à intervalle régulier. Les données de télémétrie nécessitent un système capable de gérer des opérations de lecture à haute vitesse, tandis que les informations de commande réclament des capacités d’écriture instantanées. Par exemple, InfluxDB qui est un SGBD time series associé à un moteur SQL a été conçu pour gérer des informations horodatées de ce genre, mais une base PostgreSQL ou MongoDB, après configuration, apporte des fonctionnalités similaires. Toutefois, l’ingestion demande généralement la mise en place d’un message broker pour redistribuer les informations à la base de manière quasi instantanée.

- Haute disponibilité. La base de données doit être fiable et profiter d’un haut niveau de disponibilité. Pour cela, se tourner vers un fournisseur de DbaaS comme AWS, Microsoft Azure, GCP mais aussi MongoDB, MariaDB ou autres peut s’avérer un bon choix.

- Analytique Edge. De nombreuses architectures de flux de données des capacités analytiques sont relativement proches des équipements eux-mêmes. Les exigences en matière de données comprennent le filtrage, l’enrichissement et toute agrégation supplémentaire. Les bases de données Edge analytics nécessitent des fonctionnalités de lecture et d’écriture à grande vitesse et une très faible latence, ainsi que la possibilité de prendre en charge des outils et des solutions analytiques.

- Plateforme analytique dans le cloud. Au fur et à mesure que les données sont agrégées – éventuellement dans un cluster hébergé dans le cloud – les équipes ont souvent besoin d’y appliquer des transformations, des enrichissements et des analyses supplémentaires. Une plateforme de base de données analytique nécessite une haute disponibilité. Elle peut également devoir être distribuée et prendre en charge le traitement continu.

- Observabilité. La console de gestion doit saisir et afficher les données des appareils, y compris les métadonnées, les données opérationnelles et d’état. Elle doit inclure des capacités de visualisation et de tableau de bord et nécessite une latence de l’ordre de la milliseconde.

-  Analyse métier. Les informations en provenance des parcs IoT, doivent souvent être injectées dans des entrepôts ou des lacs de données où les data scientists peuvent s’en servir pour entraîner des algorithmes de machine learning. La base de données IoT doit pouvoir communiquer avec la plateforme analytique utilisée par l’entreprise.

4. Déterminer les exigences de performances

En bref, les bases de données présentent généralement un compromis entre la performance (le temps de réponse en lecture et en écriture) et la longévité (la durée pendant laquelle les données doivent être stockées et maintenues à jour). Une autre façon de voir les choses est celle de la vitesse par rapport à l’échelle. Les outils d’ingestion et d’analytiques Edge ont besoin d’une latence très faible et d’une vitesse supérieure, mais ne doivent généralement pas conserver de gros volumes de données pendant une longue période. En revanche, les bases de données dédiées à l’analytique métier doivent conserver des historiques conséquents, mais n’ont pas besoin d’un temps de réponse inférieur à la milliseconde. Cette disparité fonctionnelle entraîne, généralement, la nécessité de gérer plusieurs bases de données. Cependant, certaines bases de données NoSQL ou SQL, associées avec les bons middlewares peuvent couvrir l’ensemble de la chaîne de valeur.

5. Appliquer des exigences métiers

La performance n’est pas la seule exigence. D’autres facteurs incluent la manière dont les fournisseurs fixent le prix de leurs services, les droits de licence, l’emplacement de la base de données, la position de l’organisation sur l’utilisation d’outils et de ressources open source, et l’environnement existant avec lequel le SGBD doit communiquer.