Relationale Datenbankmanagementsysteme (RDBMS) gehören nach wie vor zum Mittel der Wahl zur Datenspeicherung. Verschiedene andere Ansätze wie objektorientierte oder XML-Datenbanken fristen heute nur ein Nischendasein in bestimmten Anwendungsbereichen.
Dafür gibt es verschiedenste Gründe. Mitverantwortlich ist sicher die Tatsache, dass es traditionell im Bereich der RDBMS viele hochwertige Open-Source-Lösungen gibt. Die bekanntesten sind PostgreSQL und MySQL. Auch die Tatsache, dass das relationale Modell theoretisch sehr gut fundiert ist und eine saubere Trennung von Anwendung und Daten erlaubt, hat wohl einen Beitrag geleistet.
Aber während RDBMS etliche Vorteile bieten, bringen sie natürlich auch einige Nachteile mit. So vertragen sich die Welt der Objekte und die Welt der Tabellen zunächst nicht sehr gut. Zudem kann die Installation und Verwaltung von ausgewachsenen RDBMS sehr aufwendig sein und sich insbesondere für die sogenannten «kleinen» Applikationen oft nicht lohnen. Während sich das Objekt-Relationen-Problem mit objekt-relationalen Mapping Tools wie Hibernate, Castor oder Apaches iBates und Torque lösen lässt, können die Voraussetzungen zur Nutzung von RDBMS mit Embedded-Datenbanken gesenkt werden, die besonders im Java-Bereich verbreitet sind. Auch das Apache-Projekt hat mit Derby eine passende Software im Angebot, die vor rund 2 Jahren von IBM gestiftet wurde und mehr als eine klassische Embedded-Datenbank ist.
Derby bietet im Gegensatz zu anderen Open-Source-Java-Datenbanken eine sehr vielseitige Engine und eine umfangreiche Implementierung des SQL-Standards:
- Im Serverbetrieb ist Derby für Multi-User-Betrieb ausgelegt, und der Kernel arbeitet multithreaded.
- Transaktionen werden auf allen Isolation Levels unterstützt.
- Backup und Restore sind im laufenden Betrieb möglich.
- Unicode Support.
- Der SQL-Sprachumfang beinhaltet Tables, Views (non updateable), Indices, Constraints (Foreign Keys und Checks) sowie Trigger und Stored Procedures.
- Um die Performance zu verbessern, können Daten- und Logging-Files auf getrennten Laufwerken gehalten werden.
Sehr interessant ist zudem die Möglichkeit, mit nur geringem Overhead Tabellen auf der Platte zu verschlüsseln. Diese werden dann erst zur Laufzeit entschlüsselt. Dies ist insbesondere bei der Speicherung sicherheitskritischer Daten praktisch.
Im laufenden Betrieb sind wenige bis gar keine administrativen Eingriffe erforderlich, wenngleich die Datenbank-Engine über etliche Parameter auf den Anwendungsfall optimiert und somit beschleunigt werden kann.
Schwächen gibt es allerdings im Bereich der Access Controls durch das Fehlen der GRANT- respektive REVOKE-Statements. Dieses Feature ist aber bereits für eine der nächsten Versionen angekündigt.
Eine weitere, besonders auch vom Performance-Standpunkt her interessante Möglichkeit ist es, Trigger und Stored Procedures zu verwenden. Trigger werden von Datenbankaktivitäten wie Updates, Inserts oder Deletes ausgelöst und führen dann vor oder nach der entsprechenden Aktion Logik auf dem Server aus.
Derby bietet hier im Vergleich zu andern Systemen besonders viel: Trigger können SQL-Kommandos ausführen oder in Java geschriebene Funktionen aufrufen. Diese werden immer innerhalb der Datenbank abgearbeitet und haben entsprechende Performance-Vorteile. In verschiedenen Anwendungen häufig benötigte Logik kann also sehr einfach in Java implementiert und auf die Datenbank ausgelagert werden.
SQL-basierte Trigger sind auch transaktionssicher. Dies trifft im Prinzip auch für Java-Funktionen zu, allerdings sind diese entsprechend sauber zu implementieren, wie in der Dokumentation im Detail erklärt wird.
Derby kann wie die meisten anderen Java-Datenbanken in verschiedenen Modi betrieben werden: einerseits als klassischer Server (siehe Abbildung Seite 45) oder als eingebettete Software (siehe Abbildung unten).
Im Server-Modus werden die Verbindungen entweder über das Netzwerk oder einen Socket entgegengenommen. Dieser Betriebsmodus wird normalerweise in Multi-User-Umgebungen und beim Produktiv-Betrieb gewählt, da sich so auch Datenbank- und Applikationsserver physikalisch trennen lassen.
Beim Embedded-Modus wird dagegen der entsprechende JDBC-Treiber als Java Archive geladen und über die JDBC Connection Derby in derselben Virtual Machine gestartet. Dies ist einerseits eine äusserst einfache Möglichkeit, eine Datenbank zu verwenden, da keinerlei Installation erforderlich ist und sich nur die Java-Bibliothek im Klassenpfad befinden muss. Andererseits ist es auch eine sehr sichere Variante, da mangels Serverprozess nur die jeweilige Anwendung mit der Datenbank interagieren kann und so kein Zugriff von aussen möglich ist. Dies sind Vorzüge, die insbesondere bei Desktop-Applikationen (ob webbasiert oder nicht) eine grosse Rolle spielen, da der Anwender so von der Existenz der Datenbank nichts mitbekommt. Auch das Testen und Verteilen der Datenbank zwischen Entwicklern ist sehr einfach, da sowohl Derby selbst (das Derby Java Archive) als auch die Datenbank im Softwareprojekt mitverwaltet werden können. Das heisst, Derby wird in der entsprechenden Version beispielsweise über Maven geladen, und die Datenbank kann über ein Sourcecode-Management-System wie Subversion verwaltet werden.
Andere Datenbanken wie die ebenfalls freie HSQLDB erlauben noch weitere Betriebsvarianten neben dem Server- und dem Embedded-Modus. So zum Beispiel Datenbanken, von denen einige Tabellen vollständig im Hauptspeicher, andere wie üblich auf der Platte gehalten werden, was natürlich positive Effekte auf die Performance hat. Derartige In-Memory-Tabellen werden im Moment von Derby noch nicht unterstützt, sollen aber in einer der nächsten Versionen folgen.
Wie alle Java-basierten Datenbanksysteme unterstützt natürlich auch Derby das JDBC-Protokoll. Damit können auch alle Tools, die JDBC unterstützen, verwendet werden. Beispiele wären Datenbank-Frontends wie SquirrelSQL oder Reporting-Tools und Office-Anwendungen wie OpenOffice.org. Auch alle gängigen O/R-Mapping-Tools wie Hibernate, iBatis oder Castor arbeiten mit Derby zusammen. Damit kann der gesamte Persistenz-Stack in reinem Java gehalten werden und ist entsprechend performant, flexibel und portabel.
Der Zugriff über ODBC ist bei den meisten Java-Datenbanken nicht ohne weiteres möglich. Es gibt aber Dritthersteller wie Easysoft, die ODBC-Treiber für die meisten Systeme, darunter auch Derby, anbieten.
Bezüglich Geschwindigkeit erweist sich Derby als sehr angenehm. Generell lässt sich sagen, dass Derby im Embedded-Modus sehr schnell, aber doch deutlich langsamer als die andere freie Alternative HSQLDB ist. Dies liegt unter anderem daran, dass HSQLDB noch über keine Transaktions-Isolierung verfügt, sprich sogenannte Dirty Reads ermöglicht. Zudem lässt sich, wie bereits erwähnt, HSQLDB als In-Memory-Datenbank betrieben, was im Vergleich zu Derby einen weiteren Geschwindigkeitszuwachs bringt. Vergleicht man Derby dagegen mit RDBMS wie PostgreSQL, ist es deutlich flinker, was durch die geringe Grösse (rund 2 MB) und den Embedded-Modus bedingt ist. Wechselt man dagegen vom Embedded- zum Server-Modus, verliert man durch die Netzwerkzugriffe wieder an Leistung, wodurch Derby etwa auf dem Leistungsniveau anderer RDBMS zu liegen kommt. Derart generelle Aussagen sind selbstverständlich mit Vorsicht zu geniessen, sowohl wegen des unterschiedlichen Funktionsumfangs der verschiedenen Produkte als auch wegen den unterschiedlichen Anforderungen durch die auf der Datenbank aufsetzende Software. So können insbesondere in Kombination mit den häufig verwendeten O/R-Mapping-Tools, die eigene Caching-Mechanismen implementieren, grosse Unterschiede auftreten.
Der Toolsupport, vor allem an visuellen Tools, ist leider im Augenblick noch ein Schwachpunkt von Derby. Mitgeliefert werden im wesentlichen drei Kommandozeilen-Programme:
- ij dient der Verbindung zur Datenbank und zum Absetzen von SQL-Statements, ist aber nur als Notlösung zu bezeichnen.
- sysinfo gibt Informationen über die Datenbank aus.
- dblook erlaubt das Extrahieren bestehender Datenbanken-Definitionen.
Möchte man mit Derby effizient arbeiten, muss man letztlich auf externe Tools zurückgreifen. Zum Glück gibt es hier doch einiges, auch im Open-Source-Bereich. Zu nennen wären beispielsweise Squirrel SQL (Open Source), DB Visualiser (Freeware und kostenpflichtige Varianten) sowie verschiedene Eclipse-Plug-ins.
Leider helfen diese Tools aber nur beschränkt beim Modellieren beziehungsweise Administrieren von Datenbanken. Dieses Schicksal teilt Derby aber letztlich mit allen Open-Source-Java-Datenbanken, die ebenfalls nur wenige Tools mitbringen.
Die verschiedenen Open-Source-Datenbanken auf Java-Basis unterscheiden sich stark bei der Lizenzierung: One$DB, die Open-Source-Variante von Daffodil, steht unter LPGP, McKoi und db4o (eine objektorientierte Datenbank) unter GPL, HSQLDB unter einer eigenen Lizenz, h2 unter der Mozilla-Lizenz und Derby unter der Apache-Lizenz.
Als problematisch ist zumindest die GPL zu bezeichnen, weil sie eine invasive Lizenz ist. Das heisst, dass abgeleitete Produkte auch unter GPL gestellt werden müssen, was bei allen Produkten der Fall sein dürfte, die die entsprechende Datenbank im Embedded-Modus verwenden. Dies ist nun mit Sicherheit nicht für jedes Projekt akzeptabel und sollte gut überlegt sein. Denn der Wechsel von einer GPL-Lösung zu einer Software, welche die Apache- oder die Mozilla-Lizenz verwenden, kann sehr aufwendig und teuer werden!
Derby steht unter Apache-Lizenz und kann daher nahezu ohne Einschränkungen für alle Anwendungsfälle, auch in geschlossenen Produkten, eingesetzt werden.
Zudem bieten sowohl Sun als auch IBM eigene Produkte auf Basis von Derby an, zu denen weitere Dienstleistungen verkauft werden. Sowohl für JavaDB (Sun) als auch für Cloudscape (IBM) ist kostenpflichtiger Service erhältlich. Zudem existieren seitens Sun Überlegungen, Derby in die nächste Version des Java Development Kit zu integrieren. Dies würde eine Fortsetzung der bestehenden Strategie bedeuten, denn Sun verwendet (ähnlich wie IBM) Derby respektive JavaDB auch in verschiedenen Produktlinien wie Netbeans, Java Studio Enterprise sowie im Glassfish-Applikationsserver.
In diesem Zusammenhang ergibt sich ein weiterer interessanter Aspekt von Derby aus der Nähe zu IBMs DB2. Beispielsweise ist die SQL-Syntax weitgehend mit DB2 kompatibel. Dies gilt auch für die JDBC-Treiber. Das «Upgrade» von Derby zu DB2 ist daher recht problemlos möglich und wird bei Bedarf auch von IBM unterstützt, sodass sich Derby perfekt als Entwicklungsplattform eignet, während DB2 auf den Produktionsservern zum Einsatz kommt.
Generell lässt sich sagen, dass es sich bei Derby um ein sehr leistungsfähiges und funktional ziemlich vollständiges relationales Datenbankmanagementsystem auf Java-Basis unter Apache-Lizenz handelt. Support ist bei Bedarf von Sun oder IBM zu bekommen.
Auch die Dokumentation, die im Übergang von Cloudscape zu Derby recht chaotisch war, ist mittlerweile sehr umfangreich und deckt alle wesentlichen Bereiche ab.
Die Performance ist vor allem im Betrieb als Embedded Database gut, im Serverbetrieb gibt es aber schnellere Systeme wie HSQLDB, deren Performance man sich aber mit erheblichen funktionalen Defiziten erkauft (kein Multithreading im Kernel, keine saubere Isolation von Transaktionen).
Besonders für die Entwicklung beziehungsweise Auslieferung von fertig konfigurierten Applikationen ist Derby sehr geeignet und lässt sich sehr gut mit gängigen O/R-Mapping-Tools oder JDBC-Frontends kombinieren. Derby ist somit sicherlich für alle Java-Entwickler einen Blick wert.
Alexander Schatten ist Assistent am Institut für Softwaretechnik und interaktive Systeme der Technischen Universität Wien.
