Die serverlose Architektur von SQLite eignet sich nicht für IoT - Teil 1

Teil eins: Mobile mag IoTsein IoTwenn es um Daten geht, ist IoT nicht mobil

Vor drei Wochen haben wir uns die Leistung von SQLite angesehen - oder das Fehlen einer solchen. Danach haben wir SQLite im breiteren Kontext des modernen Datenmanagement betrachtet und festgestellt, dass seine Leistungsmängel durch die Anforderungen der Umgebung noch verstärkt werden. Als serverlose Datenbank erfordert SQLite die Integration mit einer serverbasierten Datenbank, was unweigerlich zu Leistungseinbußen führt, da die SQLite-Daten durch einen ETL-Prozess transformiert werden, um mit der Architektur der serverbasierten Datenbank kompatibel zu sein.

SQLite-Partisanen könnten dann einen abfälligen Ton anschlagen und sagen: "Ja? Wenn SQLite so langsam und die Integration so mühsam ist, warum ist es dann die am weitesten verbreitete Datenbank überhaupt?"

Nun, ja, das können wir. Und im gleichen Atemzug können wir selbst Parteigängern reichlich Grund liefern, daran zu zweifeln, dass die Popularität von SQLite auch in Zukunft anhalten wird. Spoiler-Alarm: Wie sehen die allgemeinen Wachstumskurven des IoT außerhalb des Bereichs der mobilen Endgeräte und Tablets aus?

Wie die Bananenschnecke das Rennen gewann

Im ersten Blog dieser Reihe haben wir uns angesehen, warum eingebettet Entwickler SQLite sowohl gegenüber einfachen Dateiverwaltungssystemen am einen Ende des Datenmanagement als auch gegenüber großen komplexen RDBMS am anderen Ende bevorzugt haben. Zu den wichtigsten technischen Gründen gehören, um es kurz zu machen, der geringe Platzbedarf, die Fähigkeit, in eine Anwendung eingebettet zu werden, die Portabilität auf fast jedes Betriebssystem und jede Programmiersprache mit einer einfachen Architektur (Key-Value-Store) und die Fähigkeit, Datenmanagement über eine SQL-API bereitzustellen. Der wichtigste nicht-technische Grund ist,dass es kostenlos ist! In Anwendungsfällen, die von persönlichen Anwendungen dominiert werden, die ein integriertes Datenmanagement benötigen (einschließlich Entwickler-Tools), von Webanwendungen, die einen Daten-Cache benötigen, und von mobilen Anwendungen, die etwas mit einem sehr kleinen Fußabdruck benötigen. Wenn man die Kostenfreiheit mit diesen technischen Merkmalen kombiniert und bedenkt, wo und wie SQLite eingesetzt wurde, ist es keine Überraschung, dass SQLite, gemessen an den reinen Zahlen, weiter verbreitet war als jede andere Datenbank.

Allen drei genannten Anwendungsfällen ist jedoch gemeinsam, dass es sich um Nutzer handelt, bei denen die mit einem Nutzer verbundenen Daten in einer einzigen Datei und einer einzigen Datentabelle (die in SQLite ein und dasselbe sind) gespeichert werden können. Die Nachfrage nach Daten in diesen Anwendungsfällen umfasst in der Regel serielle Lese- und Schreibvorgänge; die Wahrscheinlichkeit gleichzeitiger Lesevorgänge ist gering, von gleichzeitigen Schreibvorgängen ganz zu schweigen. Erst in späteren Iterationen von SQLite sahen die Entwickler die Notwendigkeit, gleichzeitige Lesevorgänge mit einem einzigen Schreibvorgang zu ermöglichen.

Aber die Sache ist die: In Zukunft werden diese drei Anwendungsfälle nicht mehr die Hauptentscheidungen für die Architektur sein. Ironischerweise sind die Eigenschaften von SQLite, die es bei Entwicklern so beliebt gemacht haben und die wiederum zu einer Welt geführt haben, in der Milliarden von Geräten in Echtzeitagieren, reagieren und interagieren EchtzeitNetzwerkrand, in der Cloud und im Rechenzentrum -eine Welt, für die die Hauptmerkmale von SQLite denkbar ungeeignet sind.

SQLite hat sich im Wesentlichen aus einer Rolle im Bereich des modernen Datenmanagement herausgearbeitet.

Wie bereits erwähnt, basiert SQLite auf einer eleganten, aber einfachen Architektur, dem Key-Value-Store, mit dem Sie jede Art von Daten speichern können. Die Implementierung erfolgt in C mit einem sehr geringen Platzbedarf von einigen hundert KB, wodurch es mit minimalen Ressourcen in praktisch jede Umgebung portiert werden kann. Und obwohl es nicht ganz dem ANSI-Standard-SQL entspricht, ist es doch nahe genug für Hufeisen, Handgranaten und mobile Anwendungen.

SQLite wurde in vielen frühen IoT eingesetzt, da diese frühen Entwürfe fast spiegelbildlich zu den mobilen Anwendungen waren (ohne die Notwendigkeit eines großen Aufwands für die Präsentationsschicht) und sich auf die lokale Zwischenspeicherung von Daten konzentrierten, in der Erwartung, dass diese zur Datenverarbeitung und -analyse in die Cloud verlagert würden. Billige Pilotprojekte bedeuteten, dass Designer und Entwickler sich auf das stürzten, was sie kannten und was kostenlos war - ta-dah SQLite!

Unabhängig von SQLite haben sich der IoT und seine Anwendungsfälle schnell von dieser anfänglichen Entwicklung wegbewegt. Ein klarer Beweis dafür ist leicht zu erkennen, wenn Sie in den letzten Jahren die Gelegenheit hatten, IoT zu besuchen. Erinnern Sie sich daran, wie viele der Vorträge vor drei bis fünf Jahren Proof of Concepts (PoCs) und kleine Pilotprojekte beschrieben, bei denen alle Daten in die Cloud gesendet wurden. Als wir auf der Messe mit Ingenieuren und Entwicklern sprachen, waren sie skeptisch, ob man mehr als SQLite oder überhaupt eine Datenbank benötigte - ganz zu schweigen von Client-Server-Versionen. In den letzten drei Jahren drehten sich jedoch mehr Sitzungen um die Skalierung von Pilotprojekten auf die volle Produktion und die Einbindung von ML-Routinen in lokale Geräte und Gateways. Viele der Gespräche betrafen Überlegungen zur Verwendung eines robusteren lokalen Datenmanagement, einschließlich Client-Server-Optionen.

Intelligentes IoT definiert das Datenmanagement neu

Trotz all seiner Stärken im Bereich der Nutzer sind SQLite und seine serverlose Architektur den Anforderungen von autonomen Fahrzeugen, intelligenter Landwirtschaft, medizinischer Instrumentierung und anderen Bereichen des industriellen IoT nicht gewachsen. Das Gleiche gilt für die horizontalen Bereiche, die von wichtigen industriellen IoT wie IoT , 5G-Netzwerken usw. eingenommen werden. Im Gegensatz zu Nutzer , die auf die Unterstützung von Mensch-zu-Maschine-Anforderungen ausgelegt sind, werden unzählige IoT für Maschine-zu-Maschine-Beziehungen in hochautomatisierten Umgebungen entwickelt. Moderne Maschine-zu-Maschine-Szenarien beinhalten weit weniger Eins-zu-Eins-Beziehungen und eine weitaus größere Anzahl von Peer-to-Peer- und hierarchischen Beziehungen (einschließlich Eins-zu-Viel- und Viele-zu-Eins-Abonnement- und Publikationsszenarien), die alle weitaus komplexere Anforderungen an Datenmanagement stellen als diejenigen, für die SQLite entwickelt wurde. Darüber hinaus ist die CPU aus dem Rechenzentrum in die Cloud und nun auch in den Edge-Bereich gewandert, so dass eine weitaus größere Anzahl von Systemen komplexe softwaredefinierte Operationen, Datenverarbeitung und Analysen durchführt als je zuvor. Die Anforderungen an die Verarbeitung werden immer anspruchsvoller und lokaler.

Bedenken Sie: Die IoT von morgen reichen von strukturierten Dateneinspeisungen mit geringer Geschwindigkeit und Auflösung (z. B. Zehntausende von Druck-, Volumen- und Temperaturmesswerten) bis hin zu hochauflösenden Hochgeschwindigkeits-Videoeinspeisungen von Hunderten von Streaming . In einer chemischen Verarbeitungsanlage könnten beide Sensorgitter in ein oder mehrere IoT einfließen, die wiederum in ein Netzwerk von Edge-Systemen (jedes mit der Leistung, die man vor ein paar Jahren nur in einem Rechenzentrum gefunden hätte) zur lokalen Verarbeitung und Analyse einfließen könnten, woraufhin einige oder alle Daten und analytischen Informationen an ein Netzwerk von Servern in der Cloud weitergeleitet würden.

Tiefer eintauchen: Die Rohdatenströme, die von diesen Netzen einfließen, müssen parallel gelesen und verarbeitet werden. Diese Aktivitäten könnten das sofortige Aussortieren unerwünschter Datenpunkte, das Durchführen von Signal-Rausch-Filtern, das Normalisieren von Daten oder das Zusammenführen von Daten von mehreren Sensoren umfassen, um nur einige der naheliegenden Datenverarbeitungsfunktionen zu nennen. Ein Teil der Daten würde so gespeichert, wie sie ankommen - je nach use case vorübergehend oder dauerhaft -, während andere Daten verworfen werden könnten.

Eine Welt mit zunehmender Komplexität

In diesen Szenarien finden auf jeder Ebene weitaus komplexere Vorgänge statt, einschließlich ML-Inferenzroutinen, die lokal auf Geräten, auf der Gateway-Ebene oder auf beiden Ebenen ausgeführt werden. Möglicherweise laufen parallel zusätzliche Operationen auf denselben Datensätzen, einschließlich nachgelagerter Geräteüberwachungs- und -verwaltungsoperationen, die effektiv neue Datenströme erzeugen, die sich in die entgegengesetzte Richtung bewegen (z. B. Lesevorgänge vom IoT und Schreibvorgänge auf der hierarchischen Leiter). Oder die Daten könnten gleichzeitig für die Berichterstattung und Analyse durch Unternehmensanalysten und Datenwissenschaftler in der Cloud oder im Rechenzentrum extrahiert werden. In einer Umgebung wie dem Chemiewerk, das wir uns vorgestellt haben, können auch advanced analytics und Visualisierungsaktivitäten durchgeführt werden, beispielsweise in einer lokalen Betriebszentrale.

Diese Szenarien werden immer alltäglicher und unterscheiden sich völlig von den Szenarien, die SQLite zu seiner Bekanntheit verholfen haben. Sie sind kombinatorisch und additiv; sie stellen eine Welt der Verarbeitungs- und Datenmanagement dar, die so weit von der Welt des einzelnen Nutzer und der einzelnen Anwendung entfernt ist - dem bevorzugten Einsatzgebiet von SQLite - wie es nur möglich ist:

• Gleichzeitige Schreibvorgänge sind eine Voraussetzung, und zwar nicht nur für eine einzelne Datei oder Datentabelle, wobei die Antwortzeiten zwischen den Schreibanforderungen nur wenige Millisekunden betragen.
• Mehrere Anwendungen werden Daten in denselben Datentabellen in IoT und anderen Edge-Geräten lesen und schreiben (oder sie zusammenführen), was dieselbe Art von ausgeklügelter Orchestrierung erfordert, die auch bei mehreren gleichzeitigen Nutzern erforderlich wäre.
• Bei Edge-Systemen On-Premises kann es vorkommen, dass der Betrieb von Menschen überwacht wird, deren Aktivitäten die Orchestrierung mehrerer Lese- und Schreibvorgänge in den Datenbanken und Datentabellen noch komplexer machen.

Wenn das alles nach einer Umgebung klingt, für die SQLite nur unzureichend vorbereitet ist, haben Sie recht. In den Teilen zwei und drei dieses Blogs werden wir uns mit diesen Themen näher befassen.

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.