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.
The IoT is expanding at an explosive rate, and what’s happening at the edge—in terms of applications, analytics, processing demands, and throughput—will make the world of single-user SQLite deployments seem quaint. As we’ll see in this and the next installment of this blog, the data requirements for modern edge use cases lie far outside SQLite’s wheelhouse.
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.
For all these reasons, and because it has been used ubiquitously as mobile devices have proliferated over the past decade, IoT developers naturally adopted SQLite into many early IoT applications. These early design-ins were almost mirror images of mobile applications (minus the need for much effort at the presentation layer). Data was captured and cached on the device, with the expectation that it would be moved to the cloud for data processing and analytics.
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.
That’s not something you’re going to squeeze into an embedded application. Square peg, round hole. And that explains why developers and line-of-business technical staff tended to announce that they had pressing business elsewhere whenever the words “client-server” began to pop up in conversations about the IoT. The use cases emerging in what we began to think of as the IoT were not human end-user centric. Unless someone was prototyping or doing some sort of test and maintenance on a device or gateway or some complex instrumentation, little or no ad hoc querying was taking place. Client-server was serious overkill.
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
The dynamics of modern edge data management demand that we reframe our notions of client-server, for the demands of the IoT differ from those of distributed computing as envisioned in the 80s. The old client-server paradigm involved a lot of ad hoc database interaction—both directly for ad hoc queries and indirectly by applications that involved human end-users. In IoT use cases, data access is more prescribed, often repeated and event-driven; you know exactly which data needs to be accessed, as well as when (or at least under which circumstances) an event will generate the request.
Similarly, in a given IoT use case, there are no unknowns about how many applications are running on a device or about how many external devices will be requesting data from (or sending data to) an application and its database pairing (and here, whether the database is embedded or separate standalone doesn’t really matter). While these numbers vary among use cases and deployments, a virtual team of developers, systems integrators, product managers, and others will design structure, repeatability, and visibility into the system—even if it’s stateless (and more so if it’s stateful).
In the modern IoT space, client-server database requirements are more like well-defined publish-and-subscribe relationships (post by publisher/read by subscriber and access from publisher/write to subscriber). They operate as automated machine-to-machine relationships, in which publishing/broadcasting and parallel multichannel intake activities often take place concurrently. Indeed, client-server in the IoT is like publish-subscribe—except that everything needs to perform both operations, and most complex devices (including gateways and intelligent equipment) will need to be able to perform both operations not just simultaneously but also across parallel channels.
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.
If we look at the difference between Actian Zen edge and Actian Zen enterprise (with its footprint under 200MB), we can see that most of the difference has to do with human end-user enablement. For example, Actian Zen enterprise includes an SQL editor that enables ad-hoc queries and other data management operations from a command line. While most of that same functionality resides in Zen Edge, it is accessed and executed through API calls from an application rather than a 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 ?
Historically, the vast majority of data architects and developers have approached this question from the bottom up. That’s why we started with flat files and then moved to SQLite. Rather than looking from the bottom up, I’m arguing that we need to step back, embrace a new understanding of what client-server can be, and then revisit the question from the top down. Don’t just try to force-fit serverless into a world for which it was never intended—or worse, kludge up from serverless to a jury-rigged implementation of a late 20th century-server configuration.
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.
Ready to reconsider SQLite? Learn more about Actian Zen. Or, you can just kick the tires for free with Zen Core, which is royalty-free for development and distribution.
Restez connecté
Des informations tirées des données, à votre service.
(par exemple : sales@..., support)
