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'IoT se développe à une vitesse fulgurante, et ce qui se passe à la périphérie - en termes d'applications, d'analyses, de demandes de traitement et de débit - fera paraître désuet le monde des déploiements SQLite à utilisateur utilisateur . Comme nous le verrons dans ce blog et dans le prochain, les exigences en matière de données pour les cas d'utilisation modernes à la périphérie se situent bien au-delà de la timonerie 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 lors de la prolifération des appareils mobiles au cours de la dernière décennie, les développeurs IoT ont naturellement adopté SQLite dans de nombreuses applications IoT initiales. Ces premières conceptions étaient presque le reflet des applications mobiles (sans qu'il soit nécessaire de déployer 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'attente d'être transférées dans le nuage pour le traitement et l'analyse des donné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 quelque chose que l'on peut intégrer dans une demande d'Embarqué . Un trou rond pour une cheville carrée. Cela explique pourquoi les développeurs et le personnel technique de l'entreprise avaient tendance à annoncer qu'ils avaient des affaires urgentes à régler ailleurs dès que les mots "client-serveur" commençaient à apparaître dans les conversations sur l'IdO. Les cas d'utilisation émergeant dans ce que nous avons commencé à considérer comme l'IdO n'étaient pas centrés sur l'utilisateur utilisateur humain. À moins qu'il ne s'agisse d'un prototypage ou d'une sorte de test et de maintenance d'un appareil, d'une passerelle ou d'un instrument complexe, il n'y avait que peu ou pas d'interrogation ad hoc. Le client-serveur était vraiment exagéré.

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 la gestion des données moderne gestion des données nous oblige à revoir nos notions de client-serveur, car les exigences de l'IdO 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 beaucoup d'interactions ad hoc avec les bases de données, à la fois directement pour les requête ad hoc et indirectement par les applications qui impliquaient des utilisateurs finaux humains. Dans les cas d'utilisation de l'IdO, l'accès aux données est plus prescrit, souvent répété et axé sur des événements; vous savez exactement quelles données doivent être consultées, ainsi que quand (ou au moins dans quelles circonstances) un événement générera la demande.

De même, dans un cas d'usage IoT donné, il n'y a pas d'inconnues sur le nombre d'applications exécutées sur un appareil ou sur le nombre d'appareils externes qui demanderont des données à (ou enverront des données à) une application et son couplage avec la base de données (et ici, que la base de données soit Embarqué ou autonome n'a pas vraiment d'importance). Bien que ces chiffres varient selon les cas d'utilisation et les déploiements, une équipe virtuelle de développeurs, d'intégrateurs de systèmes, de gestionnaires de produits et d'autres personnes concevra la structure, la répétabilité et la visibilité du système, même s'il est sans état (et plus encore s'il est avec état).

Dans l'espace IdO moderne, les exigences des bases de données client-serveur s'apparentent davantage à des relations de publication et d'abonnement bien définies (publication par l'éditeur/lecture par l'abonné et accès de l'éditeur/écriture à l'abonné). Elles fonctionnent comme des relations automatisées de machine à machine, dans lesquelles la publication/diffusion et les activités parallèles de réception multicanal ont souvent lieu simultanément. En effet, le client-serveur dans l'IdO ressemble à la publication-souscription, sauf que tout doit effectuer les deux opérations et que la plupart des dispositifs complexes (y compris les passerelles et les équipements intelligents) devront être en mesure d'effectuer les deux opérations non seulement simultanément, mais aussi 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 nous examinons la différence entre Actian Zen edge et Actian Zen enterprise (dont l'empreinte est inférieure à 200 Mo), nous constatons que la majeure partie de la différence est liée à l'habilitation de l'utilisateur utilisateur . Par exemple, Actian Zen enterprise comprend un éditeur SQL qui permet d'effectuer requêtes ad hoc et d'autres opérations de gestion des données à partir d'une ligne de commande. Bien que la plupart de ces fonctionnalités se trouvent dans Zen edge, elles sont accessibles et exécutées par le biais d'appels API à partir d'une application plutôt que d'une 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 et des développeurs de données ont abordé cette question de bas en haut. C'est pourquoi nous avons commencé avec des fichiers plats, puis nous sommes passés à SQLite. Plutôt que de regarder de bas en haut, je soutiens que nous devons prendre du recul, adopter une nouvelle compréhension de ce que peut être le client-serveur, puis réexaminer la question de haut en bas. N'essayez pas de faire entrer de force le serverless dans un monde pour lequel il n'a jamais été conçu - ou pire, de passer du serverless à une implémentation bricolée d'une configuration de serveur datant de la fin du^20e 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.

Si vous êtes prêt à reconsidérer SQLite, renseignez-vous sur Actian Zen. Vous pouvez également vous familiariser gratuitement avec Zen Core, qui est libre de droits pour le développement et la distribution.

À propos d'Actian Corporation

Actian facilite l'accès aux données. Notre plateforme de données simplifie la façon dont les gens connectent, gèrent et analysent les données dans les environnements cloud, hybrides et sur site . Avec des décennies d'expérience dans la gestion des données et l'analyse, Actian fournit des solutions de de haute performance qui permettent aux entreprises de prendre des décisions basées sur les données. Actian est reconnu par les principaux analystes et a reçu des prix de l'industrie pour sa performance et son innovation. Nos équipes partagent des cas d'utilisation éprouvés lors de conférences (par exemple, Strata Data) et contribuent à des projets à code source ouvert. Sur le blog d'Actian, nous abordons des sujets tels que l'ingestion de données en temps réel, l'analyse de données, la gouvernance données, la gestion des données, la qualité des données, l'intelligence des données et l'analyse pilotée par l'IA.