🤰🏽 👩‍🔬 👛 Bases de données dans la plate-forme IIoT: comment Mail.ru Cloud Solutions fonctionne avec des pétaoctets de données provenant de plusieurs appareils 🚅 🧑🏿‍🤝‍🧑🏾 ⏲️

Bonjour, je suis Andrey Sergeev, chef du groupe de développement de solutions IoT chez Mail.ru Cloud Solutions . Il est connu qu'il n'existe pas de base de données universelle. Surtout lorsque vous avez besoin de construire une plate-forme Internet des objets capable de traiter des millions d'événements à partir de capteurs par seconde en mode quasi-temps réel.

Notre produit Mail.ru IoT Platform a commencé avec un prototype basé sur Tarantool. Je vais vous dire dans quelle direction nous sommes allés, quels problèmes nous avons rencontrés et comment nous les avons résolus. Et aussi montrer l'architecture actuelle de la plate-forme moderne de l'Internet des objets industriel. Dans l'article, nous parlerons:

sur nos exigences de base de données, solution universelle et théorème CAP;
si la base de données + le serveur d'applications dans une approche est une solution miracle;
sur l'évolution de la plateforme et des bases de données qui y sont utilisées;
, Tarantool’ .

, @Databases Meetup by Mail.ru Cloud Solutions. , :

Mail.ru IoT Platform

Notre produit, Mail.ru IoT Platform, est une plateforme évolutive et indépendante du matériel pour créer des solutions pour l'Internet des objets industriel. Il vous permet de collecter des données de centaines de milliers d'appareils simultanément et de traiter ce flux en mode presque en temps réel (c'est-à-dire en quasi-temps réel), y compris en utilisant des règles personnalisées - des scripts en Python ou Lua.

La plateforme peut stocker une quantité illimitée de données brutes provenant de sources, il existe un ensemble de composants prêts à l'emploi pour visualiser et analyser les données, des outils intégrés pour l'analyse prédictive et la création d'applications basées sur la plateforme.

Voici à quoi ressemble

la plate-forme Mail.ru IoT Platform. Pour le moment, la plate-forme est disponible pour l'installation selon le modèle sur site dans les installations du client, cette année, il est prévu de publier la plate-forme en tant que service dans le cloud public.

Prototype Tarantool: comment tout a commencé

Notre plate-forme a commencé comme un projet pilote - un prototype avec une seule instance de Tarantool, dont la fonction principale était de recevoir le flux de données d'un serveur OPC, de traiter les événements reçus à l'aide de scripts Lua en temps réel, de surveiller les indicateurs clés en fonction d'eux et de générer des événements et des alertes dans systèmes supérieurs.

Schéma prototype de Tarantool

Ce prototype a même fonctionné en conditions de combat pendant plusieurs mois sur un site de cluster, c'est une plateforme de production de pétrole en haute mer, en Irak, dans le golfe Persique. Il a surveillé les indicateurs clés et fourni des données pour le système de visualisation et le journal des événements. Le pilote a été reconnu comme un succès, mais comme c'est souvent le cas avec les prototypes - il n'a pas dépassé le pilote et le prototype a été mis en attente pendant longtemps jusqu'à ce qu'il tombe entre nos mains.

Nos objectifs dans le développement d'une plateforme IoT

Avec le prototype, nous avons eu la tâche de créer une plate-forme IoT à part entière, évolutive et tolérante aux pannes, qui pourrait plus tard être lancée en tant que service dans un cloud public.

Nous avions besoin de construire une plate-forme avec l'introduction suivante:

Connectez des centaines de milliers d'appareils simultanément.
Recevez des millions d'événements par seconde.
Traitement de flux en mode quasi-temps réel.
Stockage des données brutes pendant plusieurs années.
Outils pour l'analyse en continu et l'analyse historique.
Prise en charge du déploiement dans plusieurs centres de données pour une reprise après sinistre maximale.

Avantages et inconvénients du prototype de plateforme

Au moment du début du développement actif, le prototype se présentait comme suit:

Tarantool, qui est utilisé comme base de données + serveur d'applications (Application Server);
toutes les données sont stockées dans la mémoire Tarantool;
une application sur Lua dans le même Tarantool, qui remplit les fonctions de réception des données, de traitement et d'appel de scripts utilisateur sur les données entrantes.

Cette approche de la construction d'applications a ses avantages :

Le code et les données sont au même endroit, ce qui vous permet d’opérer sur les données directement dans la mémoire de l’application et supprime les frais généraux des visites réseau typiques des applications traditionnelles.
Tarantool utilise JIT (Just in Time Compiler) pour Lua, qui lors de la compilation compile le code Lua en code machine, ce qui permet aux scripts Lua simples de s'exécuter à une vitesse comparable au code C (40000 RPS à partir d'un cœur - et ce n'est pas la limite !).
Tarantool est basé sur le multitâche coopératif, c'est-à-dire que chaque appel à la procédure stockée est lancé dans sa propre fibre, un analogue de coroutine, ce qui améliore encore plus les performances dans les tâches avec des opérations d'E / S, par exemple, les visites de réseau.
Utilisation efficace des ressources - peu d'outils peuvent gérer 40 000 requêtes par seconde à partir d'un seul cœur de processeur.

Mais il y a des inconvénients importants :

Nous devons stocker les données brutes des appareils pendant plusieurs années, mais nous n'avons pas des centaines de pétaoctets de mémoire pour Tarantool.
Conséquence directe du premier plus: tout le code de notre plateforme est des procédures stockées dans la base de données, ce qui signifie que toute mise à jour de la base de code de la plateforme est une mise à jour de la base de données, ce qui est très douloureux.
, . , Tarantool 24-32 (Tarantool ) . — Tarantool, .
. - , Tarantool Lua , - , LuaJIT .

Conclusion: Tarantool est un bon choix pour créer MVP, mais pour une plate-forme IoT à part entière, évolutive, facilement prise en charge et tolérante aux pannes qui peut recevoir, traiter et stocker des données à partir de centaines de milliers d'appareils, elle ne convient pas.

Les principales douleurs du prototype dont nous voulions nous débarrasser

Tout d'abord, nous voulions guérir deux douleurs de notre prototype:

Éloignez-vous du concept de base de données + service d'application. Nous voulions mettre à jour le code d'application indépendamment du magasin de données.
Simplifiez la mise à l'échelle dynamique sous charge. Je voulais obtenir une mise à l'échelle horizontale indépendante facile du plus grand nombre de fonctions possible.

Pour résoudre ces problèmes, nous avons choisi une approche innovante et non encore testée: architecture de microservices et séparation des services en base de données Stateless - applications et Stateful -.

Pour faciliter davantage le fonctionnement et la mise à l'échelle horizontale des services sans état, nous les avons conteneurisés et adopté Kubernetes.

Nous avons compris les services sans état, il reste à décider quoi faire avec les données.

Exigences de base de base de données pour la plate-forme IoT

Au départ, nous ne voulions pas clôturer le jardin et voulions stocker toutes les données de la plateforme dans une seule base de données universelle. Après avoir analysé les objectifs, nous sommes arrivés à la liste suivante des exigences pour une base de données universelle:

ACID- — , .
— .
— , near real-time.
— - .
— , .
— ( !), .
— , ( !).
SQL — .

CAP-

Avant de commencer à trier toutes les bases de données qui sont sur le marché pour la conformité à nos exigences, nous avons décidé de valider nos exigences en matière de santé mentale à l'aide d'un outil assez bien connu - les théorèmes CAP.

Le théorème CAP dit qu'un système distribué peut avoir au maximum deux des trois propriétés suivantes:

Cohérence (cohérence des données) - dans tous les nœuds de calcul à un moment donné, les données ne se contredisent pas.
Disponibilité - toute demande adressée à un système distribué se termine par une réponse correcte, mais sans garantie que les réponses de tous les nœuds du système correspondent.
Tolérance de partition - même s'il n'y a pas de connexion entre les nœuds, ils continuent de fonctionner indépendamment les uns des autres.

Par exemple, le système CA classique est un cluster maître-esclave PostgreSQL avec réplication synchrone, et le système AP classique est Cassandra.

Revenons à nos exigences et classons-les à l'aide du théorème CAP:

Les transactions ACID et la cohérence stricte (ou du moins pas la cohérence éventuelle) sont C.
La mise à l'échelle horizontale pour l'écriture et la lecture ainsi que la haute disponibilité est A (multi-maître).
La tolérance aux pannes est P, lorsqu'un centre de données tombe en panne, la plate-forme ne doit pas mourir.

Conclusion : la base de données universelle dont nous avons besoin doit avoir les trois propriétés du théorème CAP, ce qui signifie qu'il n'y a pas de base de données universelle pour toutes nos exigences.

Choisir une base de données pour les données avec lesquelles la plateforme IoT fonctionne

Si vous ne pouvez pas choisir une base de données universelle, nous avons décidé de sélectionner les types de données avec lesquels la plateforme fonctionnera et de sélectionner une base de données pour chaque type.

En première approximation, nous avons divisé les données en deux types:

Les méta - informations sont un modèle du monde, des appareils, des paramètres, des règles, de presque toutes les données, à l'exception de celles qui transmettent les appareils finaux.
Données brutes des appareils - lectures des capteurs, télémétrie et informations de service des appareils. En fait, ce sont des séries chronologiques, où chaque message individuel contient une valeur et un horodatage.

Choix d'une base de données pour les métadonnées

Exigences de base de données pour les métadonnées . Les métadonnées sont intrinsèquement relationnelles. Ils sont caractérisés par une petite quantité, ils sont rarement modifiés, mais ce sont des données importantes, ils ne peuvent pas être perdus, donc la cohérence est importante même dans le cadre de la réplication asynchrone, ainsi que des transactions ACID et de l'échelle de lecture horizontale.

Il existe relativement peu de telles données et elles seront relativement rarement modifiées, vous pouvez donc sacrifier la mise à l'échelle horizontale à l'enregistrement, ainsi que l'inaccessibilité possible de la base de données d'enregistrement en cas d'accident. Autrement dit, en termes de théorème CAP, nous avons besoin d'un système CA.

Ce qui convient dans le cas habituel . Avec une telle déclaration du problème, toute base de données relationnelle classique prenant en charge les clusters avec réplication asynchrone comme PostgreSQL ou MySQL nous conviendrait parfaitement.

Caractéristiques de notre plateforme . Nous avions également besoin d'un support pour les arbres ayant des exigences spécifiques. Dans le cadre du prototype, il y avait une fonctionnalité des systèmes de la classe BDVV (bases de données en temps réel) - la modélisation du monde à l'aide d'un arbre de balises. Ils vous permettent de combiner tous les appareils clients dans une arborescence, ce qui facilite la gestion d'un grand nombre d'appareils et leur affichage.

Voici à quoi ressemble l'affichage des appareils sous forme d'arborescence.

Une telle arborescence vous permet de relier les appareils finaux à l'environnement, par exemple, vous pouvez placer des appareils qui sont physiquement situés dans une pièce dans un sous-arbre, ce qui facilite grandement le travail avec eux à l'avenir. Il s'agit d'une fonction pratique, en outre, nous voulions en outre travailler dans le créneau du système de détonateur aéroporté, et la présence d'une telle fonctionnalité est en fait la norme de l'industrie.

Pour l'implémentation complète des arbres de balises, une base de données potentielle doit répondre aux exigences suivantes:

Prise en charge d'arbres de largeur et de profondeur arbitraires.
Modification des éléments d'arbre dans les transactions ACID.
Haute performance lors de la traversée d'un arbre.

Les bases de données relationnelles classiques peuvent très bien gérer les petits arbres, mais elles ne fonctionnent pas aussi bien avec les arbres arbitraires.

Solution possible. Utilisez deux bases de données - une base de données graphique pour stocker un arbre et une base de données relationnelle pour stocker le reste des méta-informations.

Cette approche présente plusieurs gros inconvénients à la fois:

Pour garantir la cohérence entre deux bases de données, vous devez ajouter un coordinateur de transactions externe.
Cette conception est difficile à entretenir et peu fiable.
En sortie, nous obtenons deux bases de données au lieu d'une, tandis que la base de données graphique n'est nécessaire que pour prendre en charge des fonctionnalités limitées.

Une solution possible mais pas très bonne avec deux bases de données

Notre solution pour stocker des métadonnées . Nous avons également pensé et retenu qu'initialement cette fonctionnalité a été implémentée dans un prototype basé sur Tarantool et elle s'est très bien déroulée.

Avant de continuer, je voudrais donner une définition non standard de Tarantool: Tarantool n'est pas une base de données, mais un ensemble de primitives pour construire une base de données pour votre cas spécifique.

Primitives disponibles prêtes à l'emploi:

Espace - un analogue des tables de la base de données pour le stockage des données.
Transactions ACID à part entière.
La réplication est asynchrone à l'aide des journaux WAL.
Un outil de sharding qui prend en charge le resharding automatique.
LuaJIT ultra-rapide pour les procédures stockées.
Grande bibliothèque standard.
Gestionnaire de paquets LuaRocks avec encore plus de paquets.

Notre solution CA était une base de données relationnelle + graphique basée sur Tarantool. Nous avons collecté le référentiel de méta-informations de rêve basé sur les primitives Tarantool:

Espace pour le stockage des données.
Transactions ACID - étaient disponibles.
Réplication asynchrone - était disponible.
Relations - effectuées sur des procédures stockées.
Arbres - également créés sur les procédures stockées.

L'installation en cluster que nous avons est classique pour de tels systèmes - un maître pour l'écriture et plusieurs Slive avec réplication asynchrone pour la mise à l'échelle pour la lecture.

Le résultat: un hybride rapide et évolutif d'une base de données relationnelle et graphique. Une seule instance de Tarantool est capable de gérer des milliers de demandes de lecture, y compris celles avec une traversée d'arbre active.

Choisir une base de données pour les données des appareils

Exigences de base de données pour les données des appareils . Ces données se caractérisent par un enregistrement fréquent et une grande quantité de données: des millions d'appareils, plusieurs années de stockage, des pétaoctets d'informations à la fois des messages entrants et des données stockées. Leur haute disponibilité est importante, car ce sont les lectures des capteurs qui fonctionnent principalement à la fois sur les règles d'utilisation et sur nos services internes.

Pour une base de données, la mise à l'échelle horizontale pour la lecture et l'écriture, la disponibilité et la tolérance aux pannes, ainsi que la disponibilité d'outils d'analyse prêts à l'emploi pour travailler avec ce tableau de données, de préférence basés sur SQL, sont importants. Dans le même temps, nous pouvons sacrifier la cohérence et les transactions ACID.

Autrement dit, dans le cadre du théorème de la PAC, nous avons besoin d'un système AP.

Exigences supplémentaires. Nous avions quelques exigences supplémentaires pour décider où les quantités gigantesques de données seraient stockées:

Séries chronologiques - les données des capteurs sont des séries chronologiques, je voulais obtenir une base spécialisée.
Open source - les avantages du code open source n'ont pas besoin de commentaires.
Un cluster gratuit est un fléau courant parmi les bases de données nouvelles.
Bonne compression - étant donné la quantité de données et en général leur uniformité, je voulais compresser efficacement les données stockées.
Opération réussie - nous voulions commencer sur une base de données que quelqu'un exploite déjà activement à proximité de nos charges afin de minimiser les risques.

Notre décision . ClickHouse répondait exclusivement à nos besoins - une base de données sur colonne de séries chronologiques avec réplication, multimaître, partitionnement, prise en charge SQL et un cluster gratuit. De plus, Mail.ru possède de nombreuses années d'expérience réussie dans l'exploitation d'un des plus grands clusters ClickHouse en volume de stockage.

Mais peu importe la qualité de ClickHouse, nous avons des problèmes avec.

Problèmes de base de données pour ces appareils et leur solution

Le problème avec les performances d'écriture. Immédiatement, il y a eu un problème avec les performances d'écriture d'un flux de données volumineux. Ils doivent être introduits dans la base de données analytiques le plus rapidement possible afin que les règles qui analysent le flux des événements en temps réel puissent consulter l'historique d'un appareil particulier et décider de déclencher ou non une alerte.

Solution au problème . ClickHouse ne tolère pas plusieurs insertions uniques (insertions), mais fonctionne bien avec de gros paquets (lots) de données - il peut facilement gérer l'écriture de lots sur des millions de lignes. Nous avons décidé de mettre en mémoire tampon le flux de données entrant, puis de coller ces données par lots.

Nous avons donc dû faire face à des performances d'enregistrement médiocres. Le

problème d' enregistrement a été résolu, mais cela nous a coûté un délai important de plusieurs secondes entre les données entrant dans le système et leur apparition dans notre base de données.

Et cela est essentiel pour divers algorithmes qui répondent aux données des capteurs en temps réel.

Lire le problème de performances. L'analyse de flux pour le traitement des données en temps réel a constamment besoin d'informations de la base de données - ce sont des dizaines de milliers de petites requêtes. En moyenne, un nœud ClickHouse contient une centaine de requêtes analytiques en même temps; il a été créé pour des requêtes analytiques lourdes peu fréquentes pour le traitement de grandes quantités de données. Bien sûr, cela ne convient pas pour calculer les tendances dans le flux de données provenant de centaines de milliers de capteurs.

ClickHouse ne fonctionne pas bien avec un grand nombre de demandes .

Solution . Nous avons décidé de mettre un cache devant ClickHouse, qui contiendra les données chaudes les plus demandées pour les dernières 24 heures.

Les données des 24 dernières heures ne sont pas des données d'un an, mais également une quantité assez importante de données, par conséquent, nous avons également besoin d'un système AP avec une mise à l'échelle horizontale pour la lecture et l'écriture, mais en mettant l'accent sur les performances à la fois pour l'enregistrement d'événements uniques et pour plusieurs événements. en train de lire. Il nécessite également une haute disponibilité, des analyses de séries chronologiques, de la persistance et un TTL intégré.

En fin de compte, nous avions besoin d'un ClickHouse rapide, qui peut même tout stocker en mémoire pour plus de vitesse. Nous n'avons trouvé aucune solution adaptée sur le marché, nous avons donc décidé de la construire sur la base des primitives Tarantool:

Persistance - est (journaux WAL + instantanés).
Performance - il y a toutes les données en mémoire.
Mise à l'échelle - il y a réplication + partitionnement.
Haute disponibilité - il y en a.
Outils d'analyse de séries temporelles (regroupement, agrégation, etc.) - réalisés sur des procédures stockées.
TTL - réalisé sur des procédures stockées avec une fibre de fond (coroutine).

Il s'est avéré être une solution pratique et productive - une instance contient 10 000 RPC pour la lecture, y compris des requêtes analytiques pouvant aller jusqu'à des dizaines de milliers de requêtes.

Voici l'architecture résultante:

Architecture finale: ClickHouse en tant que base de données analytique et cache Tarantool qui stocke les données en 24 heures

Nouveau type de données - état et son stockage

Nous avons sélectionné des bases de données spécialisées pour toutes les données, mais la plateforme s'est développée et un nouveau type de données est apparu - l'état. L'état contient l'état actuel des appareils et des capteurs, ainsi que diverses variables globales pour les règles d'analyse de flux.

Par exemple, il y a une ampoule dans la pièce. Il peut être à la fois désactivé et activé, et vous devez toujours avoir accès à son état actuel, y compris dans les règles. Un autre exemple est une variable dans les règles de flux, par exemple, une sorte de compteur. Ce type de données se caractérise par la nécessité d'un enregistrement fréquent et d'un accès rapide, mais en même temps, les données elles-mêmes occupent une quantité relativement faible.

Le référentiel de méta-informations est mal adapté à ces types de données, car l'état peut changer souvent, et dans notre cas le plafond d'enregistrement est limité à un maître. Les stockages à long terme et opérationnels sont également mal adaptés, puisque notre état a changé pour la dernière fois il y a trois ans, et il est important pour nous d'avoir un accès en lecture rapide.

Autrement dit, pour la base de données dans laquelle l'état est stocké, la mise à l'échelle horizontale pour la lecture et l'écriture, la haute disponibilité et la tolérance aux pannes sont importantes, tandis qu'une cohérence est nécessaire au niveau des valeurs / documents. Vous pouvez tirer parti de la cohérence globale et des transactions ACID.

Une solution appropriée pourrait être n'importe quelle valeur clé ou une base de données de documents: un cluster Redis ombré, MongoDB ou encore Tarantool.

Tarantool Pros:

C'est la façon la plus populaire d'utiliser Tarantool.
Mise à l'échelle horizontale - il y a réplication asynchrone + partitionnement.
La cohérence au niveau du document - est.

En conséquence, nous avons maintenant trois Tarantools, que nous utilisons pour des cas complètement différents: le stockage des méta-informations, un cache pour lire rapidement les données des appareils et le stockage des données d'état.

Comment choisir une base de données pour la plateforme IoT

Il n'existe pas de base de données universelle.
Chaque type de données possède sa propre base de données qui lui convient le mieux.
Parfois, la base de données dont vous avez besoin peut ne pas être disponible sur le marché.
Tarantool convient comme base pour une base de données spécialisée.

Cette conférence a été faite pour la première fois au @Databases Meetup par Mail.ru Cloud Solutions. Regardez une vidéo d' autres performances et inscrivez-vous aux annonces d'événements Telegram Autour de Kubernetes chez Mail.ru Group .

Quoi d'autre à lire :

Bases de données dans la plate-forme IIoT: comment Mail.ru Cloud Solutions fonctionne avec des pétaoctets de données provenant de plusieurs appareils