Embedded Databases – Weniger ist manchmal mehr

In einem Kundenprojekt haben wir uns nach einer Technologie zum lokalen Speichern von Daten umgesehen. Unter anderem haben wir dabei einige Embedded-Speicherlösungen analysiert. Die Ergebnisse unserer Recherche möchten wir in diesem Blogbeitrag aufzeigen.

Kontext

In einem Programm für Endanwender (Java-Fatclient) sollen Nutzerdaten gesammelt und anonymisiert übertragen werden, um eine bessere Fehleranalyse zu ermöglichen. Unter anderem sollen Name und Eigenschaft des Fehlers erfasst werden sowie die Version und das Betriebssystem bei denen der Fehler auftrat. Beendet der Benutzer das Programm, werden diese Daten über eine REST-Schnittstelle an einen entfernten Server übertragen. Schlägt dies fehl sollen die Daten vorübergehend lokal gespeichert werden, um beim nächsten Mal nachträglich gesendet zu werden.

Anforderungen

Aktuell gibt es keine Notwendigkeit, die Daten zu Durchsuchen oder gezielt einzelne Datensätze zu ermitteln. Hierfür haben wir uns nach einer geeigneten Technologie umgesehen, um die lokale Speicherung der Daten schnell und einfach umzusetzen. Folgende Kriterien waren dabei wichtig:

• Den Anforderungen angemessen: Da wir nur eine Tabelle mit einem Benutzer speichern und die Datenmenge sehr überschaubar ist, brauchen wir keine Big Data-Lösung.
• Einfache und schnelle Installation: Das initiale Einrichten und auch die spätere Benutzung sollte möglichst schnell und nicht zu zeitaufwendig sein.
• Keine Schema/Tabellen Erzeugung: Die Arbeit mit einem fixen, initial zu erstellenden Schema erhöht den initialen sowie den Aufwand bei Veränderung der Attribute.
• Embedded Mode: Die Technologie sollte in das bestehende Programm integriert werden können.
• Verhalten bei Veränderung von Datentypen und Attributen: Um die Erweiterbarkeit der Nutzerstatistiken zu gewährleisten, sollte das Hinzufügen von neuen sowie das Verändern und löschen von bestehenden Attributen ohne Probleme möglich sein.
• Lizenz: Wenn möglich frei und ohne Quellcode-Offenlegung.
• Speicherplatzbedarf: Dieser sollte nicht zu hoch ausfallen falls die Daten beim Benutzer zwischengespeichert werden.
• Testbarkeit: Die Technologie sollte einfach zu testen sein.
• Dependency Verwaltung über Maven: Idealerweise sollte sich das Plug-In über Maven verwalten lassen.

Nicht berücksichtigt wurde die Performance, da keine großen Datenmengen verarbeitet werden müssen.

Embedded Database Technologien

Da die zu speichernde Datenmenge gering ist und nur eine einzige Tabelle benötigt wird, sollte der Aufwand möglichst gering gehalten werden. In die nähere Auswahl kamen deshalb ein einfaches JSON-File, zwei objektorientierte DB Systeme ObjectDB und Db4o sowie die Key-Value Store Systeme BerkleyDB und LevelDB. Es gibt eine ganze Reihe von Storage Technologien die viele der oben aufgeführten Kriterien erfüllen. Unter anderem SQLite, Apache Derby oder H2 Database. Allerdings ist bei diesen der Aufwand deutlich höher als bei den hier getesteten Systemen. Es müssen erst Tabellen erzeugt werden, außerdem ist das ablegen von Objekten nicht ohne weiteres möglich (Objekt-relationale Transformation notwendig). Daneben gibt es noch viele weitere Systeme, die ähnliche Lösungsmöglichkeiten bieten (zum Beispiel UnQLite, SQLite Json Extension, CouchDB, RavenDB, u.v.m). Diese werden aber aus Zeit- und Komplexitätsgründen nicht betrachtet.

Insgesamt eignen sich alle oben aufgeführten Systeme um Objekte schnell und einfach zu speichern. Der Aufwand von der Integration bis zur Verwendung ist bei allen Systemen Vergleichsweise gering. Die meisten Kriterien können sowohl von JSON als auch von den Datenbanksystemen erfüllt werden.
Nur Db4o schneidet bei vier Kriterien sehr schlecht ab. Löscht man ein Attribut so bleibt dessen Spalte bestehen, aber alle darin enthaltenen Werte werden zu null. Ändert man den Datentyp eines Attributes wird eine neue Spalte mit diesem Datentyp angelegt, die alte Spalte bleibt allerdings bestehen jedoch werden hier alle Werte zu null. Probleme beim verändern des Datentyps gab es auch bei den Key-Value Stores. Wenn man dort den Datentyp eines Attributes veränderte, war es nicht mehr möglich das als Byte-Folge gespeicherte Objekt zu deserialisieren. Auch bei den Lizenzen unterscheiden sich die fünf Technologien. So ist JSON und LevelDB frei nutzbar während bei ObjectDB ab einem gewissen Objekt- und Klassenlimit eine kommerzielle Lizenz benötigt wird. Db4o hingegen kann entweder mit einer kommerziellen Lizenz in nicht-GPL-Projekten verwendet werden, oder mit einer GPL Lizenz als freie Software. BerkleyDB verfolgt hier ein ähnliches Lizenzsystem.

Fazit

Da die anonyme Nutzerstatistik in Zukunft sowohl veränderbar als auch erweiterbar bleiben muss, kann sich Db4o hier nicht behaupten, zumal die Entwicklung eingestellt wurde. Bei LevelDB und BerkleyDB besteht ebenfalls das Problem der mangelnden Veränderbarkeit. Zudem ist das LevelDB System sehr unzuverlässig. So kann es bei Stromausfällen und Systemabstürzen zu Inkonsistenzen in den Daten kommen (1). Außerdem ist die Korruptionsanfällig so hoch, dass eine Korruptionserkennung mit in die Anwendung integriert werden muss. Auch das duale Lizenzsystem ist eher ungeeignet, da der Quellcode der von uns entwickelten Anwendung nicht offengelegt und auch keine kommerzielle Lizenz erworben werden soll. Somit bleiben nur noch JSON und ObjectDB. Diese unterscheiden sich hinsichtlich der Kriterien kaum, nur die freie Lizenz ist bei ObjectDB beschränkt. Um hier auf der sicheren Seite zu sein, haben wir uns letztendlich für JSON entschieden. JSON erfüllt alle Kriterien und ist ohne Einschränkung verwendbar. Es ist außerdem flexibel und erlaubt das einfache Speichern von Objekten.

(geschrieben von Michael Lang und Marc Mai)