Foto: Avesun | shutterstock.com
Die allermeisten modernen Business-Anwendungen können strukturierte Daten auf irgendeine Art und Weise speichern und verarbeiten. Eine Datenbank ist dabei ebenfalls obligatorisch, unabhängig davon, ob es sich um eine Client-seitige Applikation, eine Anwendung mit Web-Frontend oder für Edge Devices handelt. Allerdings ist eine Embeddable Database in vielen Fällen ausreichend. Diese zeichnen sich in erster Linie dadurch aus, dass sie leichtgewichtig, kompakt und portabel sind.
So wie SQLite - eine einbettbare Open-Source-Datenbank, die in C geschrieben ist und mit herkömmlichem SQL abgefragt werden kann. In diesem Artikel werfen wir einen Blick darauf, wofür SQLite (hauptsächlich) verwendet wird, welche Vorteile die Lösung realisieren kann und wo sie an ihre Grenzen stößt. Weil SQLite nicht die einzige Option in Sachen Embeddable Database darstellt, erfahren Sie nicht nur, inwiefern sie sich von MySQL und MariaDB unterscheidet, sondern auch, welche weiteren Alternativangebote Ihnen in diesem Bereich offenstehen.
SQLite in der Praxis
Der häufigste Use Case für SQLite ist die Verwendung als herkömmliche, tabellenorientierte relationale Datenbank. Das begründet sich vor allem durch folgende Funktionen:
SQLite unterstützt Transactions und Atomic Behaviors. Ein Programmabsturz oder gar ein Stromausfall kann nicht dazu führen, dass die Datenbank beschädigt wird.
SQLite verfügt über einige High-End-Funktionen, beispielsweise Volltextindizierung und Support für große Datenbanken (bis zu 281 Terabyte mit Zeilengrößen von bis zu 1 GB).
SQLite bietet die Möglichkeit, Konfigurationsdaten für Programme zu speichern. Statt Dateiformate wie JSON oder YAML zu parsen, können Entwickler SQLite als Schnittstelle zu diesen Dateien verwenden - was oft wesentlich schneller geht, als diese manuell zu bearbeiten.
SQLite kann mit In-Memory-Daten oder solchen aus externen Quellen (zum Beispiel CSV-Dateien) umgehen, als wären es native Datenbanktabellen. Das eröffnet eine praktische Möglichkeit, solche Daten abzufragen.
Darüber hinaus bringt SQLite auch nativen Support für JSON-Dateien mit.
6 SQLite-Vorteile
Die wichtigsten Vorteile von SQLite auf einen Blick:
Plattformübergreifend: SQLite läuft fast überall - es wurde auf eine Vielzahl von Plattformen portiert, unter anderem Windows, macOS, Linux, iOS und Android. Insbesondere Windows-Benutzer können vorkompilierte Binärdateien für normales Win32, UWP, WinRT und .Net verwenden. Unabhängig vom Deployment-Ziel Ihrer Anwendung stehen die Chancen gut, dass es eine SQLite-Edition dafür gibt - oder eine Möglichkeit, den C-Quellcode auf dieses Ziel zu portieren.
Umfassend kompatibel: Um SQLite zu verwenden, müssen die zugrundeliegenden Anwendungen nicht in einer bestimmten Sprache geschrieben sein. Einzige Voraussetzung ist, dass es eine Möglichkeit gibt, externe Bibliotheken einzubinden, die in C geschrieben sind. SQLite Binaries sind in sich geschlossen - können also einfach in dasselbe Verzeichnis wie die Anwendung gezogen werden, um sie bereitzustellen.
Python-fähig: Viele Sprachen verfügen über High-Level-Bindings, um SQLite als Bibliothek zu nutzen - und können das in Kombination mit weiteren Database Access Layers verwenden. In Python beispielsweise wird die SQLite-Bibliothek standardmäßig mit der Default-Version des Python-Interpreters ausgeliefert. Darüber hinaus haben Drittanbieter eine Vielzahl von ORMs und Datenschichten geschrieben, die SQLite nutzen. Sie müssen also nicht über SQL-Strings im raw-Format auf SQLite zugreifen (was nicht nur umständlich, sondern auch potenziell gefährlich ist).
Self-contained: Weil es sich bei SQLite um eine Standalone-Binärdatei handelt, lässt es sich leicht zusammen mit einer Anwendung bereitstellen und bei Bedarf mit ihr verschieben. Jede mit SQLite erstellte Datenbank besteht zudem aus einer einzelnen Datei, die mit SQL-Befehlen komprimiert oder optimiert werden kann.
Drittanbieter-Ökosystem: Binary Extensions von Drittanbietern sorgen für noch mehr Funktionalität bei SQLite. So wird es etwa möglich, AES-Verschlüsselung, UUIDs oder die Suche nach regulären Expressions hinzuzufügen. Viele weitere Drittanbieter-Projekte stellen zudem zusätzliche SQLite-Tools zur Verfügung.
Open Source: Der Quellcode von SQLite ist Public Domain (gemeinfrei), kann also praktisch ohne Einschränkung in anderen Programmen wiederverwendet werden.
Wo SQLite an seine Grenzen kommt
SQLite ist aufgrund seiner Konzeption für einige Szenarien gut, für andere dagegen weniger geeignet. Zum Beispiel funktioniert SQLite nicht gut mit:
Apps, deren Funktionen nicht unterstützt werden. SQLite bringt keinen Support für verschiedene Funktionen relationaler Datenbanken mit. Dabei handelt es sich eher um selten genutzte Features, wenn Sie aber gerade die brauchen, ist das ein Ausschlusskriterium.
Anwendungen, die Scale-Out-Designs erfordern. SQLite-Instanzen sind eigenständig und unabhängig, es besteht keine native Synchronisierung zwischen ihnen. Sie können auch nicht (in einem Cluster) zusammengeführt werden. Alle Softwareanwendungen mit Scale-Out-Design funktionieren deshalb nicht mit SQLite. Es gibt Extensions, um diese Funktionalitäten hinzuzufügen, aber keine native Möglichkeit.
Applikationen mit simultanen Write-Prozessen über mehrere Verbindungen. SQLite sperrt die Datenbank für Schreibvorgänge. Entsprechend führen mehrere parallele Write-Prozesse zu Performance-Problemen. Anwendungen mit mehreren simultanen Read-Vorgängen sind jedoch im Allgemeinen schnell. SQLite Version 3.7.0 (und höher) unterstützen den sogenannten "Write-Ahead Logging Mode", um mehrere Schreibvorgänge zu beschleunigen. Dieser Modus ist jedoch mit Einschränkungen verbunden.
Anwendungen mit starker Datentypisierung. SQLite verfügt über relativ wenige Datentypen und kann etwa nicht mit einem nativen Datetime Type aufwarten. Das hat zur Folge, dass die Anwendung die meisten Typen erzwingen muss. Wenn Sie möchten, dass die Datenbank und nicht die Anwendung die Inputs für Datetime-Werte normalisiert und einschränkt, ist SQLite möglicherweise nicht geeignet.
SQLite vs. MySQL vs. MariaDB
SQLite wird regelmäßig mit MySQL verglichen - ebenfalls ein populäres Open-Source-Datenbankprodukt, das heute fester Bestandteil vieler Applikations-Stacks ist. Und auch wenn sich SQLite und MySQL in vielerlei Hinsicht stark ähneln: Es gibt manchmal gute Gründe, MySQL oder auch MariaDB - die dritte populäre Lösung in diesem Bunde - vorzuziehen.
Datentypen
SQLite bringt eine überschaubare Anzahl nativer Datentypen mit, nämlich:
BLOB,NULL,INTEGER,REALundTEXT.
Sowohl MySQL als auch MariaDB verfügen hingegen über spezifische Datentypen für Datums- und Zeitangaben, verschiedene Präzisionsstufen für Ganzzahlen und Fließkommazahlen und vieles mehr.
Wenn Sie relativ wenige Datentypen speichern oder Ihren Data Layer zur Datenvalidierung nutzen wollen, ist SQLite die richtige Wahl. Wenn Sie jedoch Wert darauf legen, dass Ihre Datenschicht ihre eigene Validierung und Normalisierung vornimmt, sollten Sie MySQL oder MariaDB bevorzugen.
Konfiguration und Feintuning
Die Konfigurations- und Einstellungsmöglichkeiten von SQLite beschränken sich auf ein Minimum. Die meisten internen oder Befehlszeilen-Flags befassen sich mit Randfällen oder Abwärtskompatibilität. Das passt zur allgemein simplen Philosophie von SQLite: Die Standardoptionen sind für die meisten Anwendungsfälle gut geeignet.
MySQL und MariaDB bieten hingegen reichhaltige Konfigurationsoptionen. Zum Beispiel in Form von:
Collations,
Indexing,
Performance Tuning oder
Storage Engines.
Single-User- vs. Multi-User-Datenbank
SQLite eignet sich ideal für Anwendungen mit einem Benutzer. MySQL und MariaDB sind hingegen darauf ausgelegt, von mehreren Usern gleichzeitig genutzt zu werden. Deshalb eignen sie sich auch für Cluster- und Scale-Out-Lösungen. Einige Extensions erweitern SQLite um Skalierungsfunktionen. Das ist allerdings kein vollwertiger Ersatz für MySQL oder MariaDB.
5 SQLite-Alternativen
In Sachen Embeddable Database ist SQLite wie bereits erwähnt nicht die einzige Option. Diverse andere Lösungen bieten ähnliche Funktionen, fokussieren sich jedoch auf andere Anwendungsfälle oder Einsatzmodelle. Zum Beispiel:
Apache Derby, eine einbettbare SQL-Engine, die auch von Oracle (als Java DB) neu verpackt wurde. Da Apache Derby in Java geschrieben ist und die JVM benötigt, ist es hauptsächlich dafür konzipiert, in Java-Anwendungen eingebettet zu werden.
Firebird Embedded, eine plattformübergreifende Datenbank, die ebenfalls viele High-End-Funktionen bietet. Die Lösung ist als Bibliothek verfügbar, die in eine Client-Anwendung eingebettet werden kann. Ihr Funktionsumfang ist mit dem von SQLite vergleichbar, allerdings ist die Community- und Support-Basis von SQLite deutlich größer.
Realm, eine relationale Datenbank, die für mobile Umgebungen (hauptsächlich Android) entwickelt wurde, aber auch Desktop-Umgebungen unterstützt. Allerdings handelt es sich um eine objektbasierte Lösung, die entsprechend keine SQL Queries verwendet. Realm ist inzwischen ein MongoDB-Projekt.
VistaDB, eine Embeddable Database für die .Net-Laufzeitumgebung. VistaDB ist in verschiedenen Versionen erhältlich, die auf die jeweiligen .Net-Varianten ausgerichtet sind und viele Enterprise-Funktionen wie Full Database Encryption enthalten. Bei VistaDB handelt sich allerdings nicht um Open Source, sondern ein kommerzielles Produkt.
Berkeley DB, ein Oracle-Projekt, das nominell ein Key/Value Store ist, in aktuelleren Versionen jedoch SQLite verwendet, um SQL Queries zu verarbeiten. Die zugrundeliegende Datenbank-Engine verfügt über einige Performance-Optimierungen, die SQLite nicht bieten kann. Beispielsweise die Fähigkeit, mehrere parallele Schreibvorgänge zu verarbeiten. Die Lizenzierung von Berkeley DB richtet sich nach dem Anwendungsfall.
(fm)
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.