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.
Das IoT rasant, und was am Edge geschieht – in Bezug auf Anwendungen, Analysen, Verarbeitungsanforderungen und Durchsatz – wird die Welt derNutzer altmodisch erscheinen lassen. Wie wir in diesem und dem nächsten Beitrag dieses Blogs sehen werden, liegen die Datenanforderungen moderner Edge-Anwendungsfälle weit außerhalb des Kompetenzbereichs von SQLite.
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.
Aus all diesen Gründen und da SQLite im Zuge der zunehmenden Verbreitung mobiler Geräte im letzten Jahrzehnt allgegenwärtig war, haben IoT SQLite ganz selbstverständlich in viele frühe IoT integriert. Diese frühen Implementierungen waren fast spiegelgleiche Abbilder mobiler Anwendungen (abgesehen davon, dass auf der Präsentationsschicht kein großer Aufwand erforderlich war). Die Daten wurden auf dem Gerät erfasst und zwischengespeichert, in der Erwartung, dass sie Cloud Datenverarbeitung und -analyse in die Cloud übertragen würden.
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.
Das lässt sich nicht einfach in eine eingebettet hineinzwängen. Das passt einfach nicht zusammen. Und das erklärt, warum Entwickler und technisches Fachpersonal aus den Fachabteilungen dazu neigten, anzugeben, sie hätten anderswo dringende Aufgaben zu erledigen, sobald in Gesprächen über das IoT die Begriffe „Client-Server“ auftauchten. Die Anwendungsfälle, die in dem Bereich entstanden, den wir als IoT zu bezeichnen begannen, IoT nichtNutzer menschlicheNutzer . Sofern nicht gerade jemand ein Prototyp entwarf oder Tests und Wartungsarbeiten an einem Gerät, einem Gateway oder einer komplexen Messanlage durchführte, fanden kaum oder gar keine Ad-hoc-Abfragen statt. Client-Server war in diesem Fall ein regelrechter 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
Die Dynamik des modernen Datenmanagement , dass wir unsere Vorstellungen vom Client-Server-Modell neu überdenken, denn die Anforderungen des IoT von denen des verteilten Rechnens, wie es in den 80er Jahren konzipiert wurde. Das alte Client-Server-Paradigma beinhaltete zahlreiche Ad-hoc-Interaktionen mit Datenbanken – sowohl direkt für Ad-hoc-Abfragen als auch indirekt durch Anwendungen, an denen menschliche Endnutzer beteiligt waren. In IoT ist der Datenzugriff stärker vorgegeben, oft wiederholt und ereigniszentriert; man weiß genau, auf welche Daten zugegriffen werden muss und wann (oder zumindest unter welchen Umständen) ein Ereignis die Anfrage auslöst.
Ebenso gibt es in einem bestimmtenuse case keine Unbekannten hinsichtlich der Anzahl der auf einem Gerät ausgeführten Anwendungen oder der Anzahl externer Geräte, die Daten von einer Anwendung und der zugehörigen Datenbank anfordern (oder an diese senden) – wobei es in diesem Zusammenhang keine Rolle spielt, ob die Datenbank eingebettet separat als eigenständiges System betrieben wird. Auch wenn diese Zahlen je nach Anwendungsfall und Bereitstellung variieren, wird ein virtuelles Team aus Entwicklern, Systemintegratoren, Produktmanagern und anderen die Struktur, Wiederholbarkeit und Transparenz des Systems entwerfen – selbst wenn es zustandslos ist (und erst recht, wenn es zustandsbehaftet ist).
Im modernen IoT entsprechen die Anforderungen an Client-Server-Datenbanken eher klar definierten Publish-and-Subscribe-Beziehungen (Veröffentlichung durch den Publisher/Lesen durch den Subscriber sowie Zugriff durch den Publisher/Schreiben durch den Subscriber). Sie funktionieren als automatisierte Machine-to-Machine-Beziehungen, bei denen das Veröffentlichen/Senden und parallele Mehrkanal-Erfassungsvorgänge oft gleichzeitig stattfinden. Tatsächlich IoT das Client-Server-Modell im IoT dem Publish-Subscribe-Modell – mit dem Unterschied, dass jedes Element beide Vorgänge ausführen muss und die meisten komplexen Geräte (einschließlich Gateways und intelligenter Geräte) in der Lage sein müssen, beide Vorgänge nicht nur gleichzeitig, sondern auch über parallele Kanäle hinweg auszuführen.
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.
Betrachtet man den Unterschied zwischen Actian Zen Edge und Actian Zen Enterprise (dessen Speicherbedarf unter 200 MB liegt), so wird deutlich, dass der Großteil des Unterschieds mitNutzer zusammenhängt. So enthält Actian Zen Enterprise beispielsweise einen SQL-Editor, der Ad-hoc-Anfragen andere Datenmanagement über die Befehlszeile ermöglicht. Zwar sind die meisten dieser Funktionen auch in Zen Edge vorhanden, doch der Zugriff darauf und deren Ausführung erfolgen über API-Aufrufe aus einer Anwendung heraus und nicht über die Befehlszeile.
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?
In der Vergangenheit sind die allermeisten Datenarchitekten und Entwickler diese Frage von unten nach oben angegangen. Deshalb haben wir mit Flatfiles begonnen und sind dann zu SQLite übergegangen. Anstatt von unten nach oben zu blicken, plädiere ich dafür, dass wir einen Schritt zurücktreten, ein neues Verständnis davon entwickeln, was Client-Server sein kann, und die Frage dann von oben nach unten neu betrachten. Versuchen Sie nicht einfach, Serverless in eine Welt zu zwängen, für die es nie gedacht war – oder schlimmer noch, aus Serverless eine provisorische Implementierung einer Serverkonfiguration aus dem späten20. Jahrhundert zusammenzubasteln.
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.
Sind Sie bereit, SQLite noch einmal in Betracht zu ziehen? Erfahren Sie mehr über Actian Zen. Oder probieren Sie Zen Core einfach kostenlos aus – die Nutzung für Entwicklungs- und Vertriebszwecke ist lizenzgebührenfrei.
Bleiben Sie in Verbindung
Datenanalysen direkt bei Ihnen.
(z. B. sales@..., support@...)
