Mittendrin statt nur dabei

Wer neben den klassischen Datenbankservern nichts gelten lässt, muss womöglich umdenken, denn eingebettete Varianten ziehen in immer mehr Betriebssysteme und Anwendungen ein. Ohne Administrationsaufwand bieten sie vieles, was große RDBMS ebenfalls beherrschen.

In Pocket speichern vorlesen Druckansicht 6 Kommentare lesen
Lesezeit: 12 Min.
Von
  • Frank Müller
Inhaltsverzeichnis

Bei aller Pfiffigkeit in den Algorithmen: Der Wert eines Systems steckt in den von ihm verwalteten Informationen. So umfasst die Datenbasis beispielsweise den Kundenstamm eines Unternehmens, Informationen über die Waren, den Lagerbestand, Aufträge und Verträge sowie finanzielle Transaktionen. Diese Informationen benötigen Unternehmen für ihre tägliche Arbeit und strategische Planung.

Deshalb verwundert es nicht, dass die Administration der Datenbankserver zu den elementaren Anforderungen an den Systembetrieb in Unternehmen gehört. Ebenso ist die hier zum Einsatz kommende Datenbanksoftware vielfach von zentraler Bedeutung, die Anzahl verschiedener Systeme soll möglichst gering sein. So kommt es, dass die Auswahl eines Anwendungssystems oft auch vom verwendeten DBMS abhängt.

Diese Rolle von Datenbankservern ist für unternehmensweite Anwendungssysteme leicht zu erkennen. Doch außer diesen großen Anwendungen existieren kleinere Spezialisten, die komfortabel, zuverlässig und schnell ihre Daten verwalten und sowohl den Distributions- als auch den Administrationsaufwand gering halten wollen oder deren Laufzeitsystem begrenzte Ressourcen bestimmen. Dies ist das Spielfeld der eingebetteten Datenbanksysteme. Sie fügen sich nahtlos und transparent in Anwendungen ein. In der Regel bestehen sie aus nur einer Bibliothek und Schnittstellen zu Programmiersprachen.

Mehr Infos

Entsprechend leicht lassen sie sich einsetzen, aufwendige Installationsverfahren sind nicht notwendig. Alle Arbeiten erledigt die Anwendung per Programmierschnittstelle: das Erzeugen der Datenbank, das Konfigurieren, das Anlegen der Tabellen, nahezu alles – vielleicht bis auf die Festlegung des Speicherorts – ohne den Eingriff des Nutzers.

Wegen ihrer geringen Anforderungen an die Systemressourcen laufen eingebettete Datenbanksysteme auf vielen Plattformen. In der Theorie reicht die Spanne von eingebetteten Computern bis zu ihren großen Brüdern, den Serversystemen. Allerdings sind große Server-Anwendungen dafür sicherlich nicht die typische Spielwiese. Dennoch hat beispielsweise Solaris das Datenbanksystem SQLite nicht nur für Drittanwendungen integriert, sondern verwendet es auch für die eigene Arbeit. So kann das Betriebssystem eine komfortable Datenverwaltung nutzen, ohne dass zuvor ein vollwertiges RDBMS installiert und konfiguriert werden müsste.

Außer Betriebssystemen verwenden diverse Anwendungen eingebettete Datenbanken und kommen so ohne proprietäre Formate aus. Die mögen für das Speichern von Dokumenten zwar Sinn ergeben. Größere Datenmengen mit komplexen Zusammenhängen erfordern jedoch leistungsfähige Hilfsmittel zum Indizieren, für das Suchen und Aktualisieren der Informationen. Zudem sollen sie trotz Stromausfall oder anderen Katastrophen konsistent bleiben, was Transaktionen sicherstellen. Diese Leistungen eingebetteter Datenbanken nutzen Produkte wie Photoshop Lightroom, Apples Aperture und Firefox. Weitere Nutznießer sind für den Eigenbedarf entwickelte Anwendungen, die nicht in Client/Server-Umgebungen arbeiten. Als Beispiel sei die Finanzberatung der Postbank genannt. Für die Umstellung weg vom Schalter hin zu Mitarbeitern im Außendienst wurde eine neue Version der Software auf Basis von db4o als Datenbanksystem realisiert.

Ein dritter Einsatzbereich lässt sich direkt aus dem Namen ableiten. Eingebettete Datenbanksysteme finden in eingebetteten Systemen Verwendung: in Mobiltelefonen, MP3-Playern und anderer Unterhaltungselektronik, mobilen Datenerfassungssystemen, NAS für den Heimbereich oder eingebetteten Computern in der industriellen Fertigung oder der Medizin. In der Regel teilen diese Systeme ihre Datenbanken nicht online mit anderen, sondern synchronisieren sie bei Bedarf.

Dass eingebettete Datenbanksysteme wie SQLite mittlerweile mit regulären Betriebssystemen wie Solaris und OS X, mit mobilen Systemen wie Android, iPhone und Symbian, sowie mit Sprachen wie Python, PHP und REALbasic gebündelt werden, trägt zu einer weiteren Verbreitung bei. Die oftmals große Zahl an APIs für unterschiedliche Programmiersprachen tut ein Übriges.

Eingebettete Datenbanksysteme gibt in vielen Varianten. Dies betrifft sowohl den Zugriff und die interne Struktur als auch die Portabilität auf Betriebssysteme und die Auswahl an APIs. Einige verhalten sich der Anwendung gegenüber wie ein relationales DBMS, der Client merkt nichts davon, dass er ihr einziger Nutzer ist. Diese Arbeitsweise spart Entwicklern Umstellungsaufwand, sie können ihr SQL-Know-how weiterverwenden. Außerdem lässt sich die Anwendung später leichter auf ein externes RDBMS umstellen. Je nach verwendeter Bibliothek lassen sich Strukturen sowie der dynamische Umgang mit den Daten übernehmen.

Als Nachteil kann sich die mengenorientierte Arbeitsweise relationaler Datenbanksysteme herausstellen. Sie kommt dem Auswerten großer Datenbestände entgegen, also der Suche aller Datensätze, die einer gewünschten Eigenschaft entsprechen. Oft braucht man hingegen nur den Direktzugriff auf einen Datensatz über einen Schlüssel. Hinzu kommt, dass das Format der Datensätze einer Tabelle variieren kann. So ist es möglich, die Änderungshistorie einer Struktur als Bestandteil des Datensatzes mit aufzunehmen.

Relationale Datenbanksysteme kommen solchen Anforderungen in der Regel nicht entgegen. Nichtrelationale DBMS, die vielfach mit Schlüssel-Wert-Paaren arbeiten, eignen sich dafür besser. Je nach System können die Werte und manchmal sogar die Schlüssel komplexe und geschachtelte Datenstrukturen umfassen. Typen und Strukturen sind dabei in der Regel nicht starr durch ein Schema festgelegt. Sie dürfen auch innerhalb einer Tabelle variieren und erlauben so flexible Lösungen ohne großen Aufwand.

Neben der Arbeitsweise ist die Portabilität einer der wichtigen Aspekte in der Evaluierungsphase. Ohne dedizierten Datenbankserver muss die Bibliothek auf allen Betriebssystemen verfügbar sein, auf denen die sie nutzende Anwendung laufen soll. Noch wichtiger ist jedoch die Verfügbarkeit in einer oder mehreren Programmiersprachen. Sie kann einerseits eine Anforderung sein, beispielsweise um Daten innerhalb einer Applikation zu verwalten, Reports hingegen über Skripts zu erstellen. Andererseits schränkt sie unter Umständen die internen Datenformate ein und zwingt so den Entwickler zu Anpassungen.

Einige eingebettete Datenbanksysteme sind nicht systemübergreifend geschrieben, sondern für eine Laufzeitumgebung, beispielsweise die JVM, .Net, Erlang oder Smalltalk, in die sie sich nahtlos integrieren. So können sie deren Möglichkeiten optimal ausnutzen.

Ein populärer und alteingesessener Vertreter eingebetteter Datenbanksysteme ist das freie SQLite: eine kleine Bibliothek, die den SQL92-Standard nahezu vollständig implementiert. Zum Speichern der Daten nutzt sie eine plattformunabhängige Datei. Dies erleichtert den Abgleich mit zentralen Systemen, beispielsweise durch Hochladen dieser Datei und Zugriff mit einer Synchronisationsanwendung. Für Schreiboperationen stehen Transaktionen nach dem ACID-Prinzip zur Verfügung. Dies trägt ebenso zu einem breiten Einsatzspektrum bei wie die Fähigkeit, je nach Konfiguration Datenbanken im Terabytebereich sowie Strings und BLOBs im Gigabytebereich zu verwalten.

Mit 300 KByte hält sich die Bibliothek dezent im Hintergrund, ohne optionale Features reichen sogar 180 KByte. Abhängigkeiten von weiteren Bibliotheken existieren nicht. SQLite ist für diverse Unix-Betriebssysteme, OS X und Windows verfügbar, gleichzeitig findet es sich auf Smartphones wie dem iPhone, Android und Symbian. Schnittstellen gibt es zu C, C++, Java, JavaScript, .Net-Sprachen, Lisp, Smalltalk, Perl, PHP, Python, Ruby, Scheme und vielen mehr. SQLite kommt unter anderem in Apples Safari und im Firefox zum Einsatz. Die Browser nutzen es einerseits zum Speichern von Anwenderdaten wie Lesezeichen. Andererseits stellen sie es Webanwendungen via JavaScript zur Verfügung [1].

HSQLDB ist wie SQLite ein relationales Datenbanksystem, jedoch in Java und nur für die JVM geschrieben. Es funktioniert mit den JDKs 1.1 bis 1.6. Java-Anwendungen nutzen die Datenbank mit einer internen JDBC-Schnittstelle. Außer in einer eigenständigen Java-Anwendung läuft HSQLDB als Server in einer JVM. Zwischen ihm und den Clients kommt dann ein proprietäres Protokoll zum Einsatz, was der Nutzer jedoch nicht bemerkt, da er weiterhin JDBC benutzt. Als Datenbanksprache dient SQL:2003 samt eigenen Erweiterungen, Stored Procedures und Trigger schreibt man hingegen in der Wirtssprache Java. Wie es sich für ein Datenbanksystem gehört, bietet HSQLDB Transaktionen inklusive Savepoints. Für die Speicherung kommen unterschiedliche Arten von Tabellen zum Einsatz: Für die höchste Geschwindigkeit bieten sich ausschließlich im Hauptspeicher gehaltene an, dazu kommen bis zu 8 GByte große Tabellen im Dateisystem und spezielle Texttabellen für CSV oder ähnliche Daten, die bis zu 2 GByte groß sein dürfen. HSQLDB ist unter anderem in das freie OpenOffice.org integriert.

Mit Berkeley DB stellt Oracle ein in C entwickeltes, nichtrelationales, eingebettetes Datenbanksystem mit Schnittstellen zu vielen Sprachen zur Verfügung. Es erlaubt die einfache Speicherung beliebiger Daten mit einem ebenso beliebigen Schlüssel. Der Befehl hierzu lautet je nach Sprache

Database put(Transaction, Key, Value, Flags)

Das Lesen funktioniert mit

Database get(Transaction, Key, Buffer, Flags)

Als gespeicherte Daten kommen einfache Strings oder Zahlen ebenso wie C-Strukturen und Objekte in C++, Java oder weiteren unterstützten Sprachen infrage.

Weitere Freiheiten hat der Nutzer bei der Zugriffsmethode auf die Schlüssel einer Tabelle. Er wählt zwischen B-Trees und Hashwerte, Queue und Datensatznummern. Die Verfahren unterscheiden sich hinsichtlich der Zugriffsgeschwindigkeit und des Sortierverhaltens. Tabellen dürfen im Speicher, im Dateisystem und sogar an beiden Orten liegen. Transaktionen folgen wiederum den ACID-Regeln. Berkeley DB gestattet konkurrierende Zugriffe durch parallele Threads.

Den professionellen Anspruch unterstreichen weitere Features: Backups im laufenden Betrieb sowie der Master-Slave-Einsatz mit einem Master und mehreren Kopien im Lesezugriff. Beim Ausfall des Masters übernimmt eine von ihnen seine Aufgaben. Diese für Verfügbarkeit und Skalierung wichtigen Aspekte sind eigentlich Domänen großer DBMS wie Oracle 11g. Auch die Obergrenzen von 4 GByte für Datensätze und 256 TByte für Tabellen sprechen für die Eignung für große Projekte.

Berkeley DB steht unter diversen Unix- und POSIX-kompatiblen Betriebssystemen zur Verfügung, unter anderem Linux, BSD, OS X, VxWorks und Windows. APIs existieren für C, C++, Java, Perl, Python, PHP, Tcl, Ruby und weitere Sprachen. Oracle bietet neben der C- eine reine Java-Version an, jedoch ohne Replikation. Als dritte Variante steht eine XML-Version bereit, die auf dem regulären Berkeley DB aufsetzt.

Ein alter Hase auf dem Markt nichtrelationaler DBMS ist Versant, seit vielen Jahren Anbieter des ODBMS ObjectDatabase und seit der Übernahme von Poet des ODBMS FastObjects .Net. Das eingebettete Datenbanksystem stammt ebenfalls von einem anderen Unternehmen: Carl Rosenbergers db4objects. Sein für Java und .Net verfügbares db4o bietet eine leicht zu nutzende API ohne Mapping, ohne Annotations und ohne db4o-spezifischen Code für die persistenten Klassen. Die Speicherung erfolgt mit einfachen Methoden, Abfragen über Query by Example, nativ in Java, C# oder VB.Net sowie mittels LINQ. Wie die bisherigen Datenbanksysteme unterstützt db4o ACID-Transaktionen, außerdem parallele Threads und Transaktionen, schnelle Tabellen im Hauptspeicher sowie Replikation. Jede Datenbankdatei darf bis zu 254 GByte groß sein. Die Java-Version versteht sich mit nahezu allen Java-Plattformen ab JDK 1.1, die .Net-Version im Wesentlichen mit allen Versionen ab 1.0 sowie Mono. Die db4o-Engine ist für GPL-lizenzierte Projekte frei, nichtkommerzielle Projekte dürfen es unter der dOCL kostenlos einsetzen. Für kommerzielle Software oder Support durch Versant existiert eine kommerzielle Lizenz.

Einige Umgebungen bringen ihr Datenbanksystem gleich mit, so Erlang/OTP mit Mnesia. Ericsson entwickelte dieses System zur nativen Speicherung beliebig komplexer Erlang-Datenstrukturen in einer verteilten Landschaft. Der Zugriff erfolgt über Schlüssel oder Query List Comprehension in Erlang selbst. Weitere Möglichkeiten sind die Iteration über Inhalte und die Suche mit Mustern. Neben der nahtlosen Integration bezüglich Datenstrukturen und Sprache legt Ericsson Wert auf eine hohe Fehlertoleranz und Verfügbarkeit. Mnesia ist in Erlang selbst geschrieben, bietet Transaktionen, benutzerdefinierte Reaktionen auf definierbare Ereignisse auf Datenbank- und Tabellenebene, Replikation, dynamische Rekonfiguration, Speichertabellen und die Fragmentierung von Tabellen über mehrere Knoten hinweg. Zurzeit dürften Tabellen im Dateisystem pro Knoten nicht größer als 4 GByte sein.

Es gibt viele unterschiedliche Ansätze für eingebettete Datenbanksysteme, sodass sowohl Freunde der traditionellen SQL-Nutzung als auch Interessenten an Key/Value-Datenbanken auf ihre Kosten kommen. Letztere entbinden den Entwickler in der Regel vom aufwendigen Mapping zwischen Datenstrukturen beziehungsweise Klassen und Tabellen sowie dem Datenzugriff in einer anderen Sprache als der gerade genutzten. Dies kann sich positiv auf die Zeiten für Realisierung und Anpassungen auswirken.

Frank Müller
ist Senior Consultant bei der BTC AG in Oldenburg.

Literatur
[1] Patrick Lobacher; Webprogrammierung; Datenlokal; Offline-Speicher mit JavaScript; iX 8/09, S. 128

iX-Link

Übersicht eingebettete Datenbanken
Produkt SQLite HSQLDB Berkeley DB db4objects Mnesia
Website sqlite.org hsqldb.org oracle.com/database/berkeley-db/ db4o.com erlang.org/doc/apps/mnesia
Lizenz Public Domain Hypersonic License Open Source & Commercial License for Oracle Berkeley DB GPL & Commercial Erlang Public License
Plattformen Unix, Linux, Mac OS X, Windows, Android, iPhone OS, Symbian JVM Unix (POSIX), Linux, Mac OS X, VxWorks, Windows JVM JVM & .Net, Erlang/OTP
APIs C, C++, TCL, Java, JavaScript, .Net-Sprachen, Lisp, Smalltalk, Perl, PHP, Python, Ruby Java C, C++, Java, Perl, Python, PHP, TCL, Ruby Java, .Net-Sprachen Erlang
Größe 180 – 300 KByte unbek. 400 KByte 600 KByte – 1 MByte unbek.1
max. Datenbankgröße 32 GByte abh. von Anz. Tabellen abh. von Anz. Tabellen abh. von Anz. Dateien abh. von Anz. Tabellen
max. Tabellengröße unbek. 8 GByte (Disk Table), 2 GByte (Text Table) 256 TByte 254 GByte (Datei) 4 TByte pro Fragment
max. Datensatzgröße 1 GByte, 2 GByte (BLOB) begr. durch Tabellengröße 4 GByte begr. durch Dateigröße begr. durch Tabellengröße
1 Mnesia ist Bestandteil der Erlang/OTP.

(ck)