Der Übergang von Flat Files zu SQLite

Im Dezember, Januar und Februar habe ich eine kurze Serie von Blogs über Flat-File-Systeme veröffentlicht. In der Blogserie geht es um die weitere Verwendung von Flat Files und warum sie in Zukunft nicht mehr sinnvoll sind.

In der ersten Folge ging es um flache Dateien und warum Entwickler von eingebettet Softwareanwendungen diese gerne verwenden. In der zweiten Folge ging es dann darum, warum eingebettet Entwickler Datenbanken nur ungern verwenden. Der dritte Teil befasste sich mit der Frage , warum Entwickler an flachen Dateisystemen festhalten. Der letzte Teil enthält eine Checkliste für eingebettet Entwickler, die von Flat Files wegmigrieren.

In dieser nächsten Serie möchte ich mich dem nächsten Sprungbrett auf dem Weg vieler eingebettet Entwickler weg von Flat Files zuwenden: SQLite. Es ist zwar ein Fortschritt, aber ich möchte Sie davon überzeugen, dass Sie über diesen Stein steigen oder abspringen sollten, wenn Sie noch auf ihm wippen.

Vielleicht sollten wir mit der Frage beginnen, warum und inwiefern dies ein positiver Schritt im Vergleich zu flachen Dateien ist. Das müsste natürlich im Hinblick darauf geschehen, wo und wie es auf reale Anforderungen angewandt wird. Laut den SQLite-Leuten selbst, wie auf der SQLite-Website angegeben, Geeignete Anwendungen für SQLite: "SQLite konkurriert nicht mit Client/Server-Datenbanken. SQLite konkurriert mit fopen()". Diese Aussage ist mit der grundsätzlichen Aussage verbunden, dass SQLite nicht mit SQL-Datenbank-Engines verglichen werden soll, da SQL-Datenbank-Engines als gemeinsames Lager für Unternehmensdaten gedacht sind. Um ein gemeinsames Lager zu sein, braucht eine SQL-Datenbank-Engine laut der SQLite-Website und damit der Gemeinschaft: Scalability, Zustimmung, Zentralisierung und Kontrolle. SQLite hingegen konzentriert sich auf die lokale Datenspeicherung für einzelne Anwendungen und Geräte, bei denen keine Datenbankverwaltung erforderlich ist (sie liefern die Standard-Wäscheliste typischer IoT ).

Die SQLite-Leute sagen auch, dass es in eingebettet Umgebungen großartig wäre, wenn man ein einziges kompaktes Dateiformat hätte, um plattformübergreifenden Datentransfer und auch ad-hoc, selbst erstellte Datensätze mit multiple data entypen zu unterstützen. Tatsächlich hat SQLite Benchmarking durchgeführt, um zu zeigen, dass es 35% schneller ist als Dateisysteme und das Lesen und Schreiben dieser Art von Daten durch fread() oder fwrite()¹.

Wir stimmen mit den meisten Aussagen der SQLite-Leute überein: Ja, SQL-Datenbank-Engines sollten die oben genannten Anforderungen kennenlernen . Ja, es besteht ein Bedarf an lokalem Datenmanagement , das plattformübergreifend portabel ist und multiple data unterstützen kann; und schließlich führt definitiv kein Weg an einer Null-Verwaltungsumgebung am Rande für Mobile und IoT vorbei.

Damit wissen wir, was als Nächstes kommt: das Wort mit den drei Buchstaben, das mit einem "B" beginnt und mit einem "T" endet: ABER. Aber was wäre, wenn Sie Ihren Kuchen haben und ihn auch essen könnten? Was wäre, wenn Sie alle Funktionen und Vorteile eines gemeinsam genutzten Enterprise-Datenspeichers von einer SQL-Datenbank-Engine erhalten könnten und gleichzeitig die Möglichkeit hätten, sie zu verkleinern und direkt in eine lokale mobile oder IoT einbetten , die multiple data unterstützt, plattformübergreifend portabel ist und keine Datenbankverwaltung erfordert?

Die Antwort, die Sie geben sollten, ist ja. Sie können jedoch mit den folgenden vernünftigen Argumenten widersprechen:

Erstens sind SQLite und Dateisysteme kostenlos und weit verbreitet. Open-Source-SQL-Datenbank-Engines (MySQL, Postgres, MariaDB, etc.) sind nicht in der Lage, auf einen IoT oder Mobile-Footprint herunter skaliert zu werden. Ich kann sie auch nicht in meine Anwendungen eingebettet .

Zweitens, warum verwenden die Leute so eine dumme Analogie, als ob man den Kuchen haben und ihn auch essen könnte? Es ist eher so, dass ich ein Auto brauche, keinen LKW, das ist zu viel, also warum sich die Mühe machen?

Nun, meine Antwort an Sie wäre, dass das so 2015 ist (das war übrigens das letzte Mal, dass SQLite seine Seite zur "angemessenen Verwendung" aktualisiert hat). Tatsache ist, dass Sie im Jahr 2020 und ganz sicher im Jahr 2025 mit jeder Anwendung, die Sie entwickeln, die Funktionalität eines Autos und eines Lastwagens benötigen werden. Ja, Sie müssen viel mehr Daten lokal speichern und analysieren, selbst mit WiFi-6 und 5G-Bandbreite. Doch die schiere Zunahme des Datenvolumens und die Notwendigkeit, Peer-to-Peer- und Cloud , die gemeinsame Nutzung kontextbezogener Daten für die Unternehmensführung, gemeinsame Betriebsbilder und Ähnliches zu handhaben, werden so viel wie möglich diktieren und müssen immer noch lokal stattfinden, um Latenz zu vermeiden.

Darüber hinaus erfordern viele Peer-to-Peer- und Cloud - ganz zu schweigen von Gateway-Vorgängen, bei denen Sie Daten aus mehreren nachgelagerten Quellen übernehmen - die Zustimmung zu und die Kontrolle über diese nachgelagerten Datenquellen. Gateways und Edge-Datenspeicher müssen außerdem so scalability , dass Sie plattformübergreifend die gleiche Architektur und Datenportabilität nutzen können. Und schließlich müssen mit der Verlagerung von mehr Funktionen auf das Gateway, die bisher im Rechenzentrum oder in der Cloud untergebracht waren, auch die zentralisierten Funktionen dorthin verlagert werden.

Stellen Sie sich das so vor, dass Ihr Auto in den meisten Fällen einen Zweiradantrieb benötigt, in den übrigen Fällen aber die Möglichkeit eines Allradantriebs. Ihr Auto braucht vielleicht auch eine Anhängelast. Denken Sie aber auch an den umgekehrten Fall: Ihr Lkw zieht nicht immer ein Boot oder wird für Off-Road-Einsätze verwendet, und vielleicht befördert er zusätzliche Passagiere, und Sie wollen viele der Annehmlichkeiten eines Luxusautos.

Zusammenfassend lässt sich sagen, dass im Hinblick auf das Datenmanagement und diese Analogie der Edge im Jahr 2020 und in den nächsten fünf Jahren alles benötigt wird, was im Rechenzentrum für einen SQL-Datenspeicher erforderlich war (Ihre Anforderungen an einen LKW). Aber auch alles, was für das Datenmanagement lokaler Geräte benötigt wurde, als diese noch eigenständig waren (Ihre Anforderungen an das Auto).

Im Grunde genommen brauchen Sie einen Geländewagen, der von einem sehr kleinen CRV bis zu einem Monster skalierbar ist. Dazu ist SQLite leider nicht in der Lage, und wenn Sie SQLite verwenden, sind Sie immer gezwungen, es mit einer anderen Datenbank auf der anderen Seite zu verbinden. Die Nachteile dieser Zwangsehe werden wir im nächsten Blog besprechen.

Wenn Sie bereit sind, SQLite zu überdenken, erfahren Sie mehr über Actian Zen. Oder Sie können Zen Core kostenlos testen, da es 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.