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 entwickelt sich explosionsartig, und was sich am Rande der Welt abspielt - in Bezug auf Anwendungen, Analysen, Verarbeitungsanforderungen und Durchsatz - lässt die Welt der Nutzer altmodisch erscheinen. Wie wir in diesem und dem nächsten Teil dieses Blogs sehen werden, liegen die Datenanforderungen für moderne Edge-Anwendungsfälle weit außerhalb des Leistungsspektrums 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 weil SQLite mit der zunehmenden Verbreitung mobiler Geräte in den letzten zehn Jahren allgegenwärtig war, haben IoT SQLite natürlich in viele frühe IoT übernommen. Diese ersten Entwürfe waren fast spiegelbildlich zu den mobilen Anwendungen (abzüglich der Notwendigkeit eines großen Aufwands für die Präsentationsschicht). Die Daten wurden auf dem Gerät erfasst und zwischengespeichert, in der Erwartung, dass sie zur Datenverarbeitung und -analyse in die Cloud verlagert werden 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 ist nichts, was man in eine eingebettet Anwendung quetschen kann. Eckiger Pflock, rundes Loch. Und das erklärt auch, warum Entwickler und technisches Personal aus der Geschäftsleitung dazu neigten, zu verkünden, dass sie dringende Geschäfte an anderer Stelle zu erledigen hätten, sobald die Worte "Client-Server" in Gesprächen über das IoT auftauchten. Die Anwendungsfälle, die in dem, was wir als IoT zu verstehen begannen, auftauchten, waren nicht auf den menschlichen Nutzer ausgerichtet. Wenn nicht gerade ein Prototyp entwickelt oder ein Gerät, ein Gateway oder eine komplexe Instrumentierung getestet und gewartet wird, finden kaum Ad-hoc-Abfragen statt. Client/Server war ein echter 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 erfordert, dass wir unsere Vorstellungen von Client/Server überdenken, denn die Anforderungen des IoT unterscheiden sich von denen des verteilten Computings, wie es in den 80er Jahren angedacht war. Das alte Client-Server-Paradigma beinhaltete eine Vielzahl von Ad-hoc-Datenbankinteraktionen - sowohl direkt für Anfrage als auch indirekt durch Anwendungen, die menschliche Endbenutzer involvierten. In IoT ist der Datenzugriff eher vorgeschrieben, oft wiederholt und ereigniszentriert; man weiß genau, auf welche Daten zugegriffen werden muss, und auch, wann (oder zumindest unter welchen Umständen) ein Ereignis die Anfrage auslösen wird.

Ebenso gibt es in einem bestimmtenuse case keine Unbekannten darüber, wie viele Anwendungen auf einem Gerät ausgeführt werden oder wie viele externe Geräte Daten von einer Anwendung und deren Datenbankpaarung anfordern (oder an diese senden) (und hier spielt es keine Rolle, ob die Datenbank eingebettet oder eigenständig ist). Während diese Zahlen je nach Anwendungsfall und Einsatz variieren, sorgt ein virtuelles Team aus Entwicklern, Systemintegratoren, Produktmanagern und anderen für Struktur, Wiederholbarkeit und Transparenz des Systems - auch wenn es zustandslos ist (und erst recht , wenn es zustandsabhängig ist).

Im modernen IoT entsprechen die Anforderungen an Client-Server-Datenbanken eher genau definierten Veröffentlichungs- und Abonnementbeziehungen (Veröffentlichung durch den Herausgeber/Lesen durch den Abonnenten und Zugriff vom Herausgeber/Schreiben an den Abonnenten). Sie funktionieren als automatisierte Maschine-zu-Maschine-Beziehungen, bei denen die Veröffentlichung/Übertragung und die parallele Aufnahme über mehrere Kanäle oft gleichzeitig stattfinden. In der Tat ist Client-Server im IoT wie Publish-Subscribe - nur dass alles beide Vorgänge ausführen muss, und die meisten komplexen Geräte (einschließlich Gateways und intelligenter Geräte) müssen in der Lage sein, beide Vorgänge nicht nur gleichzeitig, sondern auch über parallele Kanäle 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.

Wenn wir uns den Unterschied zwischen Actian Zen edge und Actian Zen enterprise (mit einem Footprint von unter 200MB) ansehen, können wir feststellen, dass der größte Teil des Unterschieds mit der Befähigung der menschlichen Nutzer zu tun hat. So enthält Actian Zen enterprise zum Beispiel einen SQL-Editor, der Ad-hoc-Anfragen und andere Datenmanagement über die Kommandozeile ermöglicht. Während die meisten dieser Funktionen in Zen edge vorhanden sind, erfolgt der Zugriff und die Ausführung über API-Aufrufe aus einer Anwendung und nicht über eine 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?

In der Vergangenheit sind die meisten Datenarchitekten und -entwickler diese Frage von unten nach oben angegangen. Deshalb haben wir mit Flat Files angefangen und sind dann zu SQLite übergegangen. Anstatt von unten nach oben zu schauen, plädiere ich dafür, einen Schritt zurückzutreten, ein neues Verständnis davon zu entwickeln, was Client-Server sein kann, und dann die Frage von oben nach unten zu überdenken. Versuchen Sie nicht einfach, Serverless in eine Welt zu pressen, für die es nie gedacht war - oder schlimmer noch, von Serverless zu einer notdürftigen Implementierung einer Serverkonfiguration aus dem späten^20.

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.

Wenn Sie bereit sind, SQLite zu überdenken, erfahren Sie mehr über Actian Zen. Oder Sie können Zen Core kostenlos testen, das für Entwicklung und Vertrieb lizenzfrei ist.

Über Actian Corporation

Actian macht Daten einfach. Unsere Datenplattform vereinfacht die Verbindung, Verwaltung und Analyse von Daten in Cloud-, Hybrid- und lokalen Umgebungen. Mit jahrzehntelanger Erfahrung in den Bereichen Datenmanagement und -analyse liefert Actian leistungsstarke Lösungen, die es Unternehmen ermöglichen, datengesteuerte Entscheidungen zu treffen. Actian wird von führenden Analysten anerkannt und wurde für seine Leistung und Innovation mit Branchenpreisen ausgezeichnet. Unsere Teams präsentieren bewährte Anwendungsfälle auf Konferenzen (z. B. Strata Data) und tragen zu Open-Source-Projekten bei. Im ActianBlog behandeln wir Themen wie Echtzeit-Dateneingabe, Datenanalyse, Data Governance, Datenmanagement, Datenqualität, Datenintelligenz und KI-gesteuerte Analysen.