L'architecture sans serveur de SQLite n'est pas adaptée aux environnements IoT - Partie 1

Première partie : le mobile est peut-être l'IdO, mais en matière de données, l'IdO n'est pas mobile

Il y a trois semaines, nous avons examiné les performances brutes - ou leur absence - de SQLite. Ensuite, nous avons examiné SQLite dans le contexte plus large de la gestion des données moderne gestion des données et nous avons découvert que ses défauts de performance étaient en fait aggravés par les exigences de l'environnement. En tant que base de données sans serveur, SQLite nécessite une intégration avec une base de données basée sur un serveur, ce qui entraîne inévitablement une baisse des performances car les données SQLite sont transformées par un processus ETL pour être compatibles avec l'architecture de la base de données basée sur un serveur.

Les partisans de SQLite pourraient alors adopter un ton narquois et dire : "Oui ? Si SQLite est si lent et si l'intégration est si lourde, pouvez-vous me rappeler pourquoi c'est la base de données la plus omniprésente ?"

Eh bien, oui, nous le pouvons. Et dans le même souffle, nous pouvons fournir, même aux partisans, de nombreuses raisons de douter que la popularité de SQLite se maintiendra à l'avenir. Alerte au spoiler : à quoi ressemblent les courbes de croissance globales de l'IdO en dehors du domaine des téléphones mobiles et des tablettes ?

Comment la limace de la banane a gagné la course

Dans le premier blog de cette série, nous avons examiné les raisons pour lesquelles les développeurs d'Embarqué ont adopté SQLite plutôt que de simples systèmes de gestion de fichiers à une extrémité du spectre de la gestion des données et de grands systèmes SGBDR complexes à l'autre extrémité. Les principales raisons techniques, pour récapituler, sont son faible encombrement, sa capacité à être Embarqué dans une application, sa portabilité vers presque tous les systèmes d'exploitation et langages de programmation avec une architecture simple (magasin clé-valeur), et sa capacité à fournir une fonctionnalité standard de gestion des données par le biais d'une API SQL. La principale raison non technique - d'accord, la raison - estque, eh bien, c'est gratuit ! dans les cas d'utilisation dominés par les applications personnelles qui avaient besoin d'une gestion des données intégrée (y compris les outils de développement), les applications web qui avaient besoin d'un cache de données, et les applications mobiles qui avaient besoin de quelque chose avec une très petite empreinte. Si l'on combine la gratuité avec ces caractéristiques techniques et que l'on considère où et comment SQLite a été déployé, il n'est pas surprenant qu'en termes de chiffres bruts, SQLite ait été plus largement déployé que n'importe quelle autre base de données.

Ce que les trois cas d'utilisation mentionnés ci-dessus ont en commun, c'est qu'il s'agit de scénarios à utilisateur utilisateur dans lesquels les données associées à un utilisateur peuvent être stockées dans un seul fichier et une seule table de données (qui, dans SQLite, sont une seule et même chose). La demande de données dans ces cas d'utilisation implique généralement des lectures et des écritures en série ; il est peu probable qu'il y ait des lectures simultanées, et encore moins des écritures simultanées. En fait, ce n'est que dans les versions ultérieures de SQLite que les développeurs du produit ont ressenti le besoin de permettre des lectures simultanées avec une seule écriture.

Mais voilà : à l'avenir, ces trois cas d'utilisation ne seront pas ceux qui détermineront les décisions architecturales clés. Ironiquement, les caractéristiques de SQLite qui l'ont rendu si populaire auprès des développeurs ont donné naissance à un monde dans lequel des milliards d'appareils agissent, réagissent et interagissent en en temps réelpériphérie, dans le nuage et dans le centre de données - etc'est un monde pour lequel les caractéristiques clés de SQLite sont singulièrement mal adaptées.

SQLite s'est essentiellement affranchi d'un rôle dans le domaine de la gestion des données moderne gestion des données.

Comme nous l'avons mentionné précédemment, SQLite est basé sur une architecture élégante mais simple, le stockage clé-valeur, qui vous permet de stocker n'importe quel type de données. L'implémentation se fait en C avec un très faible encombrement, 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.

SQLite a été adopté dans de nombreuses applications IoT initiales, car ces premières conceptions étaient presque des images miroir des applications mobiles (sans le besoin de beaucoup d'efforts au niveau de la couche de présentation), axées sur la mise en cache locale des données dans l'attente qu'elles soient déplacées vers le nuage pour le traitement et l'analyse des données. Les projets pilotes peu coûteux ont poussé les concepteurs et les développeurs à se tourner vers ce qu'ils connaissent et ce qui est gratuit - ta-dah SQLite !

Indépendamment de SQLite, le marché de l'IdO et ses cas d'utilisation ont rapidement quitté cette trajectoire initiale. La preuve en est évidente si vous avez eu l'occasion d'assister à des salons professionnels sur l'IdO au cours des dernières années. Il y a trois ou cinq ans, rappelez-vous le nombre de sessions qui décrivaient des preuves de concept et de petits projets pilotes dans lesquels toutes les données étaient envoyées dans le nuage. Lorsque nous avons parlé aux ingénieurs et aux développeurs sur le salon, ils étaient sceptiques quant à la nécessité d'une base de données autre que SQLite, voire d'une base de données tout court - sans parler des versions client-serveur. Toutefois, au cours des trois dernières années, un plus grand nombre de sessions ont été consacrées à la mise à l'échelle des projets pilotes en vue d'une production complète et à l'infusion de routines de ML dans les dispositifs locaux et les passerelles. De plus en plus de conversations ont porté sur des considérations relatives à l'utilisation d'une gestion des données locale gestion des données plus robuste, y compris des options client-serveur.

L'IdO intelligent redéfinit l'Edge gestion des données

Malgré tous ses atouts dans l'espace des applications à utilisateur utilisateur , SQLite et son architecture sans serveur ne sont pas à la hauteur des exigences des véhicules autonomes, de l'agriculture intelligente, de l'instrumentation médicale et d'autres espaces de l'IdO industriel. Il en va de même pour les espaces horizontaux occupés par les composants clés de l'IdO industriel, tels que les passerelles IdO, les équipements de réseau 5G, etc. Contrairement aux applications à utilisateur utilisateur conçues pour support besoinsentre humains et machines, d'innombrables applications IoT sont construites pour les relations machine-machine qui se produisent dans des environnements hautement automatisés. Les scénarios modernes de machine à machine impliquent beaucoup moins de relations de personne à personne et un nombre beaucoup plus important de relations d'égal à égal et de relations hiérarchiques (y compris des scénarios d'abonnement et de publication de personne à personne et de plusieurs à plusieurs), qui ont tous des exigences de gestion des données beaucoup plus complexes que celles pour lesquelles SQLite a été conçu. En outre, la puissance des processeur ayant migré du centre de données vers le nuage et maintenant vers la périphérie, un éventail beaucoup plus large de systèmes effectue des opérations complexes définies par logiciel, le traitement des données et l'analyse que jamais auparavant. Les demandes de traitement deviennent à la fois beaucoup plus sophistiquées et beaucoup plus locales.

Pensez-y : Les réseaux de capteurs IoT de demain iront des flux de données structurés à faible vitesse et à faible résolution (capturant des dizaines de milliers de relevés de pression, de volume et de température, par exemple) aux flux vidéo à haute vitesse et à haute résolution provenant de centaines de caméras UHD streaming . Dans une usine de traitement chimique, les deux réseaux de capteurs pourraient être acheminés vers une ou plusieurs passerelles IoT qui, à leur tour, pourraient être acheminées vers un réseau de systèmes périphériques (chacun doté de la puissance que l'on ne trouvait que dans un centre de données il y a quelques années) pour le traitement et l'analyse locaux, après quoi une partie ou la totalité des données et des informations analytiques serait transmise à un réseau de serveurs dans le nuage.

Approfondir : Les flux de données brutes provenant de ces grilles devront être lus et traités en parallèle. Ces activités pourraient impliquer l'élimination immédiate des points de données parasites, l'exécution de filtres signal-bruit, la normalisation des données ou la fusion de données provenant de plusieurs capteurs, pour ne citer que quelques-unes des fonctions évidentes de traitement des données. Une partie des données serait stockée au fur et à mesure de leur arrivée - de manière temporaire ou permanente, selon le cas d'usage - tandis que d'autres données pourraient être éliminées.

Un monde de plus en plus complexe

Dans ces scénarios, nous voyons des opérations beaucoup plus complexes se dérouler à tous les niveaux, y compris des routines d'inférence ML exécutées localement sur les appareils, au niveau de la passerelle, ou les deux. D'autres opérations peuvent être exécutées en parallèle sur ces mêmes ensembles de données, notamment des opérations de surveillance et de gestion des appareils en aval, qui créent effectivement de nouveaux flux de données allant dans la direction opposée (par exemple, lecture à partir de la passerelle IoT et écriture vers le bas de l'échelle hiérarchique). Les données peuvent également être extraites simultanément pour être rapportées et analysées par des analystes commerciaux et des scientifiques de données dans le nuage ou le centre de données. Dans un environnement tel que l'usine chimique que nous avons imaginée, il peut également y avoir plus d'activités d'analytique avancée et de visualisation réalisées, par exemple, dans un centre d'opérations local.

Ces scénarios sont à la fois de plus en plus courants et totalement différents de ceux qui ont propulsé SQLite sur le devant de la scène. Ils sont combinatoires et additifs ; ils présentent un monde de demandes de traitement et de gestion des données qui est aussi éloigné que possible du monde de l'utilisateur unique et de l'application unique, le terrain d'élection de SQLite :

• Les écritures simultanées sont une nécessité, et pas seulement dans un seul fichier ou une seule table de données, avec des temps de réponse entre les demandes d'écriture de quelques millisecondes seulement.
• De multiples applications liront et écriront des données dans les mêmes tables de données (ou les rejoindront) dans les passerelles IoT et autres dispositifs périphériques, ce qui nécessitera le même type d'orchestration sophistiquée que pour plusieurs utilisateurs simultanés.
• Les systèmes périphériques sur site peuvent faire l'objet d'une surveillance humaine locale, et leurs activités ajouteront une complexité supplémentaire à l'orchestration des multiples activités de lecture et d'écriture dans les bases de données et les tables de données.

Si tout cela ressemble à un environnement pour lequel SQLite est mal préparé, vous avez raison. Dans les deuxième et troisième parties de ce blog, nous approfondirons ces questions.

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 couvrons des sujets allant de l'ingestion de données en temps réel à l'analyse pilotée par l'IA. Faites connaissance avec l'équipe dirigeante https://www.actian.com/company/leadership-team/