L'architecture sans serveur de SQLite n'est pas adaptée aux environnements IoT - Partie 2
Deuxième partie : Repenser la signification de l'approche client-serveur pour la gestion des données en périphérie
Au cours des dernières semaines, notre série de blogs sur SQLite a examiné les déficiences de performance de SQLite lors de la manipulation de données locales persistantes et les complications de performance créées par le besoin d'ETL lors du partage de données SQLite avec des bases de données dorsales. Dans notre dernier article - Mobilemay be IoT but IoT is not Mobile - nousavons commencé à comprendre pourquoi l'architecture sans serveur de SQLite n'est pas très adaptée aux environnements IoT. Le fait que SQLite soit la base de données la plus populaire de la planète tient au fait qu'elle était peu coûteuse (lire : gratuite) et apparemment suffisante pour les applicationsEmbarqué à utilisateur utilisateur qui émergent sur les smartphones et les tablettes.
C'était hier. Demain, c'est une toute autre histoire.
L'Internet des objets (IoT) connaît une croissance fulgurante, et ce qui se passe à la périphérie — en termes d'applications, d'analyses, de besoins de traitement et de débit — fera passer les déploiementsutilisateur pour des solutions d'un autre temps. Comme nous le verrons dans cet article et dans le prochain de cette série, les exigences en matière de données pour les cas d'utilisation modernes à la périphérie dépassent largement les capacités de SQLite.
SQLite Design-Ins pour l'IoT : Mettre le mauvais pied en avant
Comme nous l'avons noté, SQLite est basé sur une architecture B-tree simple et élégante. Il peut stocker n'importe quel type de données, est implémenté en C et a une très faible empreinte - quelques centaines de Ko - ce qui le rend portable dans pratiquement n'importe quel environnement avec un minimum de ressources. Et bien qu'il ne soit pas entièrement conforme à la norme ANSI SQL, il en est suffisamment proche pour les fers à cheval, les grenades à main et les applications mobiles.
Pour toutes ces raisons, et parce qu’il a été utilisé de manière omniprésente avec la prolifération des appareils mobiles au cours de la dernière décennie, les développeurs de l’IoT ont naturellement adopté SQLite dans de nombreuses applications IoT précoces. Ces premières intégrations étaient presque le reflet fidèle des applications mobiles (à l’exception du fait qu’elles ne nécessitaient pas beaucoup d’efforts au niveau de la couche de présentation). Les données étaient capturées et mises en cache sur l’appareil, dans l’optique d’être ensuite transférées vers le cloud pour y être traitées et analysées.
Mais cette attente n'était qu'une extrapolation du monde mobile que nous connaissions, et elle était à courte vue. Elle ne tenait pas compte de la puissance de traitement pouvant être intégrée dans un processeur plus en plus petit, ni de l'endroit où ces processeurs pourraient se retrouver. Elle n'envisageait pas la périphérie comme un lieu d'analyse (n'était-ce pas le domaine de l'informatique en nuage et du centre de données ?) Elle n'a pas envisagé la véritable puissance de l'IA et de la ML, ni le rôle qu'elles commenceraient bientôt à jouer dans l'IdO. Elle n'a pas non plus tenu compte du volume de données qui allait bientôt déferler sur les réseaux comme un véritable tsunami.
Vous êtes-vous rendu récemment à un salon de l'IdO ? Il y a trois à cinq ans, de nombreuses sessions décrivaient des PoC et de petits projets pilotes dans lesquels toutes les données étaient envoyées dans le nuage. Les ingénieurs et les développeurs avec lesquels nous nous sommes entretenus sur le salon ont exprimé leur scepticisme quant à la nécessité d'une base de données autre que SQLite. Certains se sont même interrogés sur la nécessité d'une base de données (sans parler des bases de données cohérentes entre les clients et les serveurs). Au cours des trois dernières années, cependant, le thème commun des sessions a changé. Elles ont commencé à se concentrer sur la mise à l'échelle des pilotes vers une production complète et sur l'infusion de routines de ML dans les dispositifs locaux et les passerelles. Les conversations ont commencé à prendre en compte des besoins plus robustes en matière de gestion des données locale gestion des données . Des discussions, d'abord à voix basse, sur les configurations client-serveur (OMG !) ont commencé à apparaître. La prise de conscience que l'IdO n'est pas la même chose que la téléphonie mobile commençait à se faire sentir.
Repenser les cases et les trous ronds
Bien sûr, la raison de ne pas utiliser une base de données client-serveur dans un environnement IoT (ou, d'ailleurs, dans n'importe quel environnement Embarqué ) était parfaitement logique - tant que le modèle client-serveur que vous rejetiez était le modèle client-serveur d'entreprise utilisé depuis les années 80. Dans ce paradigme client-serveur, les bases de données étaient conçues pour le centre de données. Elles ont été conçues pour fonctionner sur du gros matériel et pour support applications d'entreprise telles que l'ERP, avec des dizaines, des centaines, voire des milliers d'utilisateurs simultanés interagissant à partir de machines à peine sensibles. Rassemblez ces bases de données, ajoutez-y des couches de gestion sophistiquées, une armée d'administrateurs de bases de données, peut-être un intégrateur de systèmes externe, et engloutissez-les dans des millions de dollars d'investissement - et vous obtiendrez bientôt un joli petit entrepôt de données d'entreprise.
Ce n’est pas le genre de chose qu’on peut caser dans une Embarqué . C’est comme vouloir enfoncer une cheville carrée dans un trou rond. Et cela explique pourquoi les développeurs et le personnel technique des services métier avaient tendance à prétexter qu’ils avaient des affaires urgentes à régler ailleurs dès que les mots « client-serveur » commençaient à surgir dans les conversations sur l’IoT. Les cas d’utilisation qui émergeaient dans ce que nous commencions à considérer comme l’IoT n’étaient pasutilisateur humain. À moins que quelqu’un ne réalise un prototype ou n’effectue des tests et de la maintenance sur un appareil, une passerelle ou un équipement complexe, il n’y avait pratiquement pas de requêtes ad hoc. L’architecture client-serveur était clairement surdimensionnée.
En bref, compte tenu d'un ensemble très limité de cas d'utilisation, de budgets limités et d'une prise de conscience du coût et de la complexité des environnements de base de données client-serveur traditionnels, il était tout à fait logique de s'appuyer sur SQLite.
Réimaginer le client-serveur en pensant à l'IdO
La dynamique de gestion des données moderne gestion des données en périphérie gestion des données à repenser nos notions de « client-serveur », car les exigences de l’IoT diffèrent de celles de l’informatique distribuée telle qu’elle était envisagée dans les années 80. L’ancien paradigme client-serveur impliquait de nombreuses interactions ad hoc avec les bases de données — à la fois directement, pour des requêtes ponctuelles, et indirectement, par le biais d’applications impliquant des utilisateurs finaux humains. Dans les cas d’utilisation de l’IoT, l’accès aux données est plus codifié, souvent répétitif et axé sur des événements; on sait exactement quelles données doivent être consultées, ainsi que le moment (ou du moins les circonstances) où un événement va générer la requête.
De même, dans un cas d'usage donné de l’IoT, il n’y a aucune incertitude quant au nombre d’applications en cours d’exécution sur un appareil, ni quant au nombre d’appareils externes qui demanderont des données à (ou enverront des données vers) une application et la base de données qui lui est associée (et ici, le fait que la base de données soit Embarqué autonome n’a pas vraiment d’importance). Bien que ces chiffres varient selon les cas d'utilisation et les déploiements, une équipe virtuelle composée de développeurs, d'intégrateurs système, de chefs de produit et d'autres intervenants concevra la structure, la répétabilité et la visibilité du système — même s'il est sans état (et a fortiori s'il est avec état).
Dans le domaine moderne de l’IoT, les exigences en matière de bases de données client-serveur s’apparentent davantage à des relations de publication-abonnement bien définies (publication par l’éditeur / lecture par l’abonné et accès depuis l’éditeur / écriture vers l’abonné). Elles fonctionnent comme des relations automatisées de machine à machine, dans lesquelles les activités de publication/diffusion et de collecte multicanal parallèle se déroulent souvent simultanément. En effet, le modèle client-serveur dans l’IoT s’apparente à un système de publication-abonnement, à cette différence près que chaque élément doit effectuer ces deux opérations, et que la plupart des appareils complexes (notamment les passerelles et les équipements intelligents) devront être capables d’effectuer ces deux opérations non seulement simultanément, mais également sur des canaux parallèles.
Permettez-moi de le répéter pour insister : la plupart des dispositifs IoT complexes (c'est-à-dire à peu près tout ce qui n'est pas un capteur) devront être capables de lire et d'écrire simultanément.
SQLite ne peut pas faire cela.
Les bases de données client-serveur traditionnelles le peuvent, mais elles n'ont pas été conçues dans l'optique d'un faible encombrement. La plupart des bases de données client-serveur en nuage et dans les centres de données nécessitent des centaines de mégaoctets, voire des gigaoctets, d'espace de stockage. Cependant, les fonctions de base nécessaires pour gérer efficacement les lectures et écritures simultanées occupent beaucoup moins d'espace. La base de données Edge Actian Zen base de données Edge, par exemple, occupe moins de 50 Mo. Et bien que cela représente 100 fois l'empreinte installée de SQLite, ce n'est qu'une infime partie de l'espace attaché aux plateformes basées sur les processeurs 64 bits ARM et Intel Embarqué nous voyons aujourd'hui. En outre, l'empreinte d'Actian Zen edge fournit toutes les ressources nécessaires à la gestion utilisateur , à l'intégration avec des applications externes via ODBC et d'autres normes, à la gestion de la sécurité et à d'autres fonctionnalités indispensables lorsque l'on passe d'une base de données sans serveur à une base de données client-serveur. Une base de données sans serveur comme SQLite ne fournit pas ces services parce que leur besoin - comme celui de Zen Edge lui-même - n'a tout simplement pas été envisagé à l'époque.
Si l'on examine les différences entre Actian Zen Edge et Actian Zen Enterprise (dont l'empreinte est inférieure à 200 Mo), on constate que la majeure partie de ces différences concerneutilisateur destinéesutilisateur . Par exemple, Actian Zen Enterprise intègre un éditeur SQL permettant d'effectuer requêtes ad hoc gestion des données autres gestion des données à partir d'une ligne de commande. Bien que la plupart de ces fonctionnalités soient également présentes dans Zen Edge, elles sont accessibles et exécutées via des appels d'API depuis une application plutôt que depuis une interface en ligne de commande (CLI).
Mais chaque scénario de périphérie IoT nécessite-t-il un serveur ?
Ceux d'entre vous qui ont suivi l'actualité de près vont maintenant se redresser et se dire : " Hé, attendez ! N'avez-vous pas dit que tous les scénarios de gestion des données à la périphérie de l'IdO n'ont pas besoin d'une architecture client-serveur?
Oui, je l'ai fait. Je vous félicite d'y avoir prêté attention. Ce n'est pas le cas de tous les scénarios, mais ce n'est pas vraiment la question que vous devriez poser. La question essentielle est la suivante : souhaitez-vous vraiment maîtriser une architecture, une mise en œuvre et une solution fournisseur pour ces cas d'utilisation sans serveur et des architectures, des mises en œuvre et des solutions fournisseur distinctes pour l'Edge, le cloud et le centre de données ? Et dans quelle direction aborder cette question ?
Historiquement, la grande majorité des architectes de données et des développeurs ont abordé cette question selon une approche ascendante. C’est pourquoi nous avons commencé par des fichiers plats avant de passer à SQLite. Plutôt que d’adopter une approche ascendante, je soutiens que nous devons prendre du recul, adopter une nouvelle conception de ce que peut être l’architecture client-serveur, puis réexaminer la question selon une approche descendante. Il ne faut pas simplement essayer d’adapter de force le « serverless » à un monde pour lequel il n’a jamais été conçu — ou pire encore, bricoler à partir du « serverless » pour aboutir à une implémentation de fortune d’une configuration de serveur de la findu XXe siècle.
Cette voie est celle de la folie, comme nous le verrons dans le dernier épisode de cette série, où nous examinerons ce qui se passe si les développeurs décident de toute façon d'utiliser SQLite.
Prêt à reconsidérer SQLite ? Découvrez Actian Zen. Vous pouvez également tester gratuitement Zen Core, qui est exempt de redevances pour le développement et la distribution.
Restez connecté
Des informations tirées des données, à votre service.
(par exemple : sales@..., support)
