SQLite: Nicht schneller, nicht besser, aber billiger?

Die Gesamtbetriebskosten von SQLite verstehen (TCO)

In den letzten drei Monaten wurde in dieser Blogserie untersucht, warum Entwickler sich für SQLite für das eingebettet Datenmanagement entschieden haben. Einige Entwickler haben sich für SQLite entschieden, weil Mitglieder des erweiterten Teams SQL kannten und dieses Wissen nutzen wollten, um das Datenmanagement oder die Extraktion von Daten für die Visualisierung und Berichterstattung zu unterstützen. Die meisten Entwickler haben sich jedoch für SQLite entschieden, um die Einschränkungen der bestehenden Flat-File-Management-Systeme zu überwinden.

Im Nachhinein betrachtet macht das alles Sinn. Die Annahme neuer Produkte und Technologien hängt sehr oft von der Antwort auf eine einfache Frage ab: Ist dieser Ersatz eine Verbesserung gegenüber dem, was ich jetzt habe? Noch kategorischer gefragt: Ist das neue Produkt schneller, besser oder billiger? Ein idealer Ersatz wäre schneller, besser und billiger, aber das ist ein Dreiklang, der uns normalerweise entgeht. Es kommt jedoch selten vor, dass eine vorgeschlagene Änderung durchgeführt wird, wenn nicht mindestens eine dieser Eigenschaften vorhanden ist. Was war also der Grund für die Einführung von SQLite? War es schneller, besser oder billiger als die verfügbaren Alternativen? Und wenn es eines dieser Merkmale war, ist es immer noch schneller, besser oder billiger als die heute verfügbaren Datenbankalternativen?

Schneller?

Früher war SQLite im Vergleich zu Operationen mit einer flachen Datei schneller. Und heute? Wohl kaum.

SQLite ist an mehreren Fronten geradezu lethargisch. In einem direkten Vergleich zwischen SQLite und Actian Zen Core mag der Datenzugriff über SQL vergleichbar sein, aber der Zugriff auf dieselben Daten über die NoSQL-API von Actian Zen liefert eine Leistungssteigerung, die um eine Größenordnung über SQLite liegt. Oder betrachten Sie die Geschwindigkeit im Hinblick auf die Art der optimierten Client-Server-Interaktionen, die von Anwendungen im Bereich des modernen Datenmanagement gefordert werden. Client-Server-Interaktionen in IoT und mobilen Szenarien sind auf eine High-Performance Datenerfassung und die Inline-Verarbeitung von Transaktionen aus mehreren externen Kanälen angewiesen. Da SQLite jedoch ausschließlich in einem serverlosen Modus arbeitet, müssen die Daten transformiert werden (das "T" in ETL), bevor sie zu oder von einem serverbasierten Pendant, wie Microsoft SQL Server, übertragen werden können. Dieser Schritt führt nicht nur zu einer messbaren Leistungseinbuße, sondern schafft auch einen potenziellen Engpass, der die scalability Anwendung einschränken kann. Wenn man dann noch die Anforderung der Ver- und Entschlüsselung von Daten als Teil dieser Client-Server-Transformation hinzufügt - und stellt sich wirklich die Frage, ob eine Verschlüsselung in jedem modernen Datenmanagement erforderlich sein wird -, kann man sehen, wie der Tacho auf dem dashboard weiter gegen Null tendiert.

SQLite war seinerzeit ein Geschwindigkeitsdämon - aber das war die Intel 80×86-Architektur auch. Muss ich noch mehr sagen?

Besser?

Nun, solange Sie nicht ausschließlich mit dem zugrunde liegenden Dateisystem interagieren, ist die Antwort auch hier ein einfaches "Nein". Wir haben die Grenzen der serverlosen SQLite-Architektur in den Teilen 5, 6 und 7 dieser Serie ausführlich untersucht. Die Architektur war damals zwar ein Durchbruch, aber auch ein Durchbruch für ihre Zeit. Sie erfüllte den damals aufkommenden Bedarf an einem einfachen Datencache für mobile und Webanwendungen. Aber das ist nicht der Bedarf von heute. Die heutigen mobilen und IoT erfordern eine Architektur, die für Hochgeschwindigkeits-, Multikanal-, Multiprozess- und Multithreading-Anwendungen ausgelegt ist. Während einige frühe IoT auf der Annahme basierten, dass die überwiegende Mehrheit der Daten zur Verarbeitung und Analyse in die Cloud gesendet würde - ein Szenario, in dem SQLite als lokaler Datencache praktikabel erschien -, hat sich gezeigt, dass die zugrunde liegende Annahme selbst fehlerhaft war. Mit dem Aufkommen einer modernen Datenmanagement , bei der die Analyse und Transaktionsverarbeitung am Edge und nicht tief in der Cloud stattfinden kann, definiert eine optimierte Client-Server-Architektur, die auf eine optimierte Leistung entlang des gesamten Kontinuums von Gerät Cloud Edge zu Cloud/Rechenzentrum ausgelegt ist, den Begriff "besser" neu.

Wie bei faster war SQLite einst besser als andere Datenbankalternativen, wenn es um Nutzer und lokales Daten-Caching ging. Aber serverlose Architekturen sind nicht dafür gedacht, die Aufgaben unserer Zeit zu bewältigen. Wir leben in einem Multi-Versum, in dem ständig Interaktionen und Transaktionen zwischen mehreren Maschinen und zwischen mehreren Menschen stattfinden. Diese Welt erfordert mehr, als SQLite leisten kann.

Billiger?

Okay, SQLite hat den Zuschlag bekommen. Es ist quelloffen und kostenlos. Billiger geht's nicht. Für Heimwerker, die die Kosten für extern hergestellte und gekaufte Software mit einem wachsamen Auge betrachten, mag SQLite immer noch eine Anziehungskraft ausüben. Dasselbe gilt für die Entscheidungsträger in den Unternehmen, wenn sie hören, dass SQLite kostenlos ist. Das könnte bedeuten, dass im Budget mehr für andere Posten in der Stückliste oder für zusätzliche Servicestunden übrig bleibt.

Aber "kostenlos" ist hier genauso irreführend wie "kostenlose Welpen". Wenn Sie nur die Anschaffungskosten von SQLite betrachten, ist es unschlagbar. Aber Sie entkoppeln diese Einschätzung von der Berücksichtigung der internen Kosten dieser Entscheidung. Wenn Sie die Kosten für Softwaredesign, Entwicklung, Tests, Updates, laufenden Support usw. berücksichtigen - die, wie wir bereits erörtert haben, angesichts der inhärenten Beschränkungen der Architektur einen erheblichen Aufwand erfordern -, ändert sich die Kostenkalkulation drastisch.

Wir könnten einen ganzen Blog nur den DIY-Kostenschätzungen widmen, also werden wir hier nicht in die Tiefe gehen. Jeder, der noch Cobol-Assets oder andere Legacy-Tools und -Systeme besitzt, weiß genau, wie schwierig es sein kann, Code zu pflegen und zu unterstützen, der ursprünglich dafür entwickelt wurde, die Herausforderungen einer früheren Ära kennenlernen . Wenn billiger für Sie an erster Stelle steht und Sie entschlossen sind, sich die Arbeit zu machen, die Funktionen von SQLite zu erweitern, um kennenlernen heutigen Bedürfnisse kennenlernen , gibt es verschiedene Tools, mit denen Sie die Kostenbelastung pro Anzahl von Codezeilen modellieren können, die dieser Aufwand mit sich bringen wird. Die Modelle variieren je nach Größe des Codekörpers, gesetzlichen Vorgaben, geplantem Lebenszyklus und vielen anderen Faktoren, aber sie können Ihnen helfen, die wahren Kosten dieser Dummheit - pardon, dieses Aufwands - im Voraus abzuschätzen.

Natürlich werden Sie vielleicht selbstgefällig lächeln und denken, dass Sie das nicht wirklich selbst machen werden. Es gibt eine ganze Branche von Boutique-Entwicklern, die sich auf SQLite-Tools und Zusatzkomponenten spezialisiert haben, darunter Anfrage , Dienstprogramme zur Verschlüsselung von Data-at-Rest und in Transit, Transformations-Tools zur Synchronisierung von Daten mit Microsoft SQL Server und vieles mehr. Dieser Ansatz führt jedoch nur eine andere Dimension von Kosten in Ihr Unternehmen ein. Diese Add-Ons machen nicht nur den "kostenlosen" Aspekt von SQLite zunichte (da sie nicht kostenlos sind ), sondern die Abhängigkeit von diesen kleinen Anbietern birgt auch ein Risiko, über das Sie keine Kontrolle haben. Alle Fehler oder Unzulänglichkeiten in deren Code werden zu einem festen Bestandteil Ihrer Anwendung. Wenn der Boutique-Entwickler verschwindet - und die meisten von ihnen sind in der Vergangenheit ziemlich schnell wieder verschwunden -, dann sind Sie plötzlich wieder bei dem Heimwerkermodell, das Sie eigentlich vermeiden wollten. Diesmal müssen Sie jedoch selbst Hand anlegen, ohne den von Ihnen eingebrachten Code vollständig zu verstehen, was häufig suboptimale Patches und Erweiterungen des Codes bedeutet, den Sie wahrscheinlich von Grund auf anders gestaltet hätten, wenn es Ihr eigener wäre.

Oh, und zwischen den Zeilen - kein Wortspiel beabsichtigt - können Sie klar erkennen, dass Sie die Integration dieser Boutique-Add-ons in die von Ihnen entwickelte Lösung immer noch selbst vornehmen müssen. Müssen wir Ihre Seifenblase noch weiter durchlöchern, indem wir anmerken, dass die Last der Fehlerbehebung bei Problemen oder Konflikten, die sich aus der Einbindung dieser Add-Ons ergeben, ebenfalls bei Ihnen liegt? Sie werden nicht unbedingt über die erforderlichen Erkenntnis verfügen, um diese Probleme leicht zu lösen, aber Sie sind letztendlich für die von Ihnen gelieferte Lösung verantwortlich, und Sie werden derjenige sein, den man an die Gurgel nimmt, wenn die Benutzer unzufrieden sind.

Zeit, diese Nummer in Rente zu schicken

Letztendlich ist SQLite nicht schneller, nicht besser und nicht billiger. Nicht mehr. Zugegeben: SQLite war in seiner Jugend eine brillante Ergänzung des technischen Teams, aber es ist an der Zeit, das Trikot in die Höhe zu recken und die Nummer in Rente zu schicken. Wenn es nicht schneller, besser oder billiger ist, warum sollte man es dann noch einsetzen? In Anbetracht der Anforderungen an ein modernes Datenmanagement sprechen die Begriffe schneller, besser und billiger alle für Actian Zen.

Ü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.