Die serverlose Architektur von SQLite eignet sich nicht für IoT - Teil 2
Teil 2: Die Bedeutung von Client-Server für das Datenmanagement neu überdenken
In den letzten Wochen haben wir uns in unserer SQLite-Blogserie mit den Leistungsmängeln von SQLite bei der Verarbeitung lokaler persistenter Daten befasst und die Leistungskomplikationen untersucht, die durch die Notwendigkeit von ETL bei der gemeinsamen Nutzung von SQLite-Daten mit Backend-Datenbanken entstehen. In unserer letzten Folge - Mobilemay be IoT but IoT is not Mobile - haben wirbegonnen zu verstehen, warum die serverlose SQLite-Architektur für IoT nicht besonders gut geeignet ist. Die Tatsache, dass SQLite die beliebteste Datenbank der Welt ist, liegt darin begründet, dass sie kostengünstig (sprich: kostenlos) und scheinbar ausreichend für die auf mobilen Smartphones und Tablets entstehenden Nutzer eingebettet Anwendungen war.
Das war gestern. Morgen sieht die Sache ganz anders aus.
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 für das IoT: Mit dem falschen Fuß aufgestanden
Wie wir bereits erwähnt haben, basiert SQLite auf einer eleganten, aber einfachen B-Baum-Architektur. Es kann jede Art von Daten speichern, ist in C implementiert und hat einen sehr kleinen Footprint - einige hundert KB - was es in praktisch jede Umgebung mit minimalen Ressourcen portabel macht. Es ist zwar kein vollständiges ANSI-Standard-SQL, aber es ist nah genug für Hufeisen, Handgranaten und mobile Anwendungen.
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.
Aber diese Erwartung war einfach eine Extrapolation der uns bekannten mobilen Welt, und sie war kurzsichtig. Es wurde nicht bedacht, wie viel Rechenleistung in ein immer kleineres CPU gepackt werden kann und wo diese Pakete am Ende landen könnten. Sie sahen den Edge-Bereich nicht als Ort für Analysen vor (war das nicht die Domäne der Cloud und des Rechenzentrums?). Es hatte keine Vorstellung von der wahren Leistung von KI und ML und der Rolle, die diese bald im gesamten IoT spielen würden. Und man rechnete nicht mit der schieren Menge an Daten, die bald wie ein virtueller Tsunami durch die Netzwerke schwappen würden.
Waren Sie in letzter Zeit auf einer IoT ? Vor drei bis fünf Jahren wurden in vielen Sitzungen PoCs und kleine Pilotprojekte beschrieben, bei denen alle Daten in die Cloud gesendet wurden. Ingenieure und Entwickler, mit denen wir auf der Messe sprachen, äußerten sich skeptisch über die Notwendigkeit von etwas anderem als SQLite. Einige bezweifelten sogar, dass überhaupt eine Datenbank benötigt wird (geschweige denn Datenbanken, die über Clients und Server hinweg konsistent sind). In den letzten drei Jahren hat sich jedoch das gemeinsame Thema der Sitzungen geändert. Sie begannen, sich auf die Skalierung von Pilotprojekten auf die volle Produktion und die Integration von ML-Routinen in lokale Geräte und Gateways zu konzentrieren. Die Gespräche begannen, robustere lokale Datenmanagement zu berücksichtigen. Diskussionen über Client-Server-Konfigurationen (OMG!) begannen, zunächst in gedämpftem Ton, aufzutauchen. Die Erkenntnis, dass das IoT nicht dasselbe ist wie Mobile, begann sich durchzusetzen.
Quadratische Stifte und runde Löcher neu denken
Natürlich war die Begründung für den Verzicht auf eine Client-Server-Datenbank in einer IoT (oder überhaupt in einer eingebettet Umgebung) absolut sinnvoll - solange es sich bei dem Client-Server-Modell, das Sie vermeiden wollten, um das Client-Server-Modell für Unternehmen handelte, das seit den 80er Jahren verwendet wurde. In diesem Client-Server-Paradigma waren die Datenbanken für das Rechenzentrum konzipiert. Sie wurden entwickelt, um auf großen Rechnern zu laufen und Unternehmensanwendungen wie ERP zu unterstützen, mit Dutzenden, Hunderten, ja sogar Tausenden von gleichzeitigen Benutzern, die von kaum ansprechbaren Rechnern aus interagieren. Man nehme diese Datenbanken, füge ausgeklügelte Management-Overlays, ein Heer von DBAs, vielleicht einen externen Systemintegrator hinzu und stecke sie in Millionen von Dollar an Investitionsgeldern - und schon hat man ein nettes kleines Unternehmensdatenlager.
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.
Kurz gesagt, angesichts einer sehr begrenzten Anzahl von Anwendungsfällen, begrenzten Budgets und dem Wissen um die Kosten und die Komplexität herkömmlicher Client-Server-Datenbankumgebungen war es absolut sinnvoll, auf SQLite zu setzen.
Neukonzeption von Client-Server mit Blick auf das IoT
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.
Lassen Sie mich das zur Verdeutlichung wiederholen: Die meisten komplexen IoT (sprich: so ziemlich alles, was kein Sensor ist) müssen gleichzeitig lesen und schreiben können.
SQLite kann dies nicht tun.
Herkömmliche Client-Server-Datenbanken können das, aber sie wurden nicht mit Blick auf einen kleinen Speicherplatz entwickelt. Die meisten Client-Server-Datenbanken Cloud und in Rechenzentren benötigen Hunderte von Megabytes oder sogar Gigabytes an Speicherplatz. Die Kernfunktionen, die für die effiziente Verarbeitung gleichzeitiger Lese- und Schreibvorgänge erforderlich sind, benötigen jedoch weit weniger Platz. Die Actian Zen Edge-Datenbank zum Beispiel benötigt weniger als 50 MB Speicherplatz. Das ist zwar das 100-fache des installierten Platzbedarfs von SQLite, aber nur ein Bruchteil des Platzes, der auf den heutigen 64-Bit-Plattformen mit ARM- und eingebettet benötigt wird. Darüber hinaus bietet der Platzbedarf von Actian Zen Edge alle Ressourcen, die für die Verwaltung mehrerer Nutzer , die Integration mit externen Anwendungen über ODBC und andere Standards, das Sicherheitsmanagement und andere Funktionen erforderlich sind, die ein Muss sind, wenn man von Serverless zu Client-Server wechselt. Eine serverlose Datenbank wie SQLite bietet diese Dienste nicht, weil ihr Bedarf - wie der von Edge selbst - zu diesem Zeitpunkt einfach noch nicht absehbar war.
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.
Aber braucht jedes IoT einen Server?
Diejenigen von Ihnen, die das Thema aufmerksam verfolgt haben, werden jetzt aufhorchen und sagen: Hey, Moment mal: Hatten Sie nicht gesagt, dass nicht jedes Datenmanagement eine Client-Server-Architektur benötigt?
Ja, das habe ich. Ich gratuliere Ihnen, dass Sie gut aufgepasst haben. Das gilt nicht für alle Szenarien, aber das ist auch nicht die Frage, die Sie sich stellen sollten. Die entscheidende Frage ist, ob Sie wirklich eine Architektur, Implementierung und Anbieterlösung für diese serverlosen Anwendungsfälle und separate Architekturen, Implementierungen und Anbieterlösungen für Edge, Cloud und Rechenzentrum beherrschen wollen. Und aus welcher Richtung sollten Sie diese Frage angehen?
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.
Dieser Weg führt in den Wahnsinn, wie wir im letzten Teil dieser Serie sehen werden, in dem wir untersuchen werden, was passiert, wenn Entwickler sich entscheiden, SQLite trotzdem zu verwenden.
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.
Bleiben Sie in Verbindung
Datenanalysen direkt bei Ihnen.
(z. B. sales@..., support@...)
