EclipseStore will für Java Datenbanken ersetzen

Inhaltsverzeichnis

EclipseStore ist ein neues Persistenz-Framework für Java, das als Einsatz heutiger Datenbanksysteme insbesondere in der Cloud dienen. Das als Nachfolger der Projekts MicroStream geltende Framework kann beliebige Java-Objekte – in der Regel komplexe Objektgraphen beliebiger Größe und Komplexität – in jedem beliebigen Data Storage persistent speichern und umgekehrt zu jeder Zeit im Speicher vollständig oder in Teilen wiederherstellen. Anstatt Java-Objekte auf ein relationales oder anderes datenbankspezifisches Datenmodell zu mappen oder in ein Dokumentenformat wie JSON zu konvertieren, wandelt der ebenfalls neue Eclipse Serializer sie in ein effizientes Binärformat, das als BLOB persistent gespeichert wird. In der Cloud eignen sich hierfür besonders Objektspeicher wie AWS S3. Die Methode erfordert kein Datenbanksystem mehr und bietet Anwendern drei Hauptvorteile:

Performance: Sämtliche Anwendungsdaten werden im Hauptspeicher der Anwendung gehalten und verarbeitet. Der Java Objektgraph im Hauptspeicher wird als In-Memory-Datenbank benutzt. Mit der Java Streams API bietet Java eine leistungsfähige Abfragesprache für Objektgraphen. Selbst auf sehr komplexen Objektgraphen dauert das Suchen und Filtern damit meist nur Mikrosekunden und kann je nach Query mehrere hundertmal schneller sein als vergleichbare SQL-Queries.

1. Kosten: DBaaS-Dienste wie AWS RDS gelten als vergleichsweise teuer und erfordern DevOps-Ressourcen unter anderem für Replikation und Backups. Cloud BLOB Storages wie AWS S3 sind dagegen deutlich günstiger und werden sogar vom Provider vollständig gemanagt.
2. Produktivität: EclipseStore ist ein Pure-Java Ansatz. Entwickler müssen weder speziellen Datenbankkonzepte noch eine neue Abfragesprache lernen oder spezielle Designregeln befolgen, es gibt nur noch Java Klassen (POJOs). Ein zu pflegendes datenbankseitiges Datenmodell entfällt ebenso wie aufwendige Mappings oder Datenkonvertierungen für Datenbankzugriffe. Für Klassen gibt es keine speziellen Anforderungen oder Vorgaben. Entwickler müssen weder spezielle Annotationen verwenden, noch spezielle Interfaces implementieren oder von einer Superklasse ableiten. Auch die Schemamigration ist einfacher als bei Datenbanken und funktioniert zur Laufzeit.

Umdenken von Datenbank- auf Java-Konzepte

Der Ansatz wirft jedoch auch zahlreiche kritische Fragen auf. So wird etwa immer der gesamte Objektgraph gespeichert. Will man Transaktionen bieten, muss man immer die gesamte Datenbank in den RAM laden. Hier bleiben oft Fragen offen, etwa: Wie findet EclipseStore die richtigen Objekte im Object-Store? Wie funktioniert das Concurrency Handling? Wie findet man einzelne Objekte in großen Collections? Welches Vorgehen bietet sich bei einer Schemamigration an? Auf welchem Weg erfolgte von außen der Zugriff auf die Daten? Wie lassen sich verteilte, horizontal skalierbare Anwendungen entwickeln? Welchen Aufwand bringt eine Migration und wer außer Java-Entwicklern kann solche Datenbanken verwalten?

Auf fast all diese Fragen hat das Projekt valide Lösungen. Entwickler müssen jedoch bereit sein, sich von traditionellen Server-Datenbank-Konzepten zu lösen und sich darauf konzentrieren, was Java kann. Bei Änderungen am Objektgraphen wird mit einer Store-Methode oft nur vom Delta ein Snapshot erzeugt. Der Entwickler entscheidet also explizit, wann Objekte persistiert werden. Jeder Store ist eine atomare All-or-Nothing-Operation, transaktionssicher und Full-Consistent. Jedes neue BLOB wird anhängend in die Storage geschrieben, auch Updates.

Beim Start der Anwendung wird die Struktur des gesamten Objektgraphen in den RAM geladen. Der Zugriff auf die eigentlichen Daten in klassischer Java-Manier objektorientiert via Getter. Befindet sich ein Objekt bereits im RAM, wird es von der JVM zurückgegeben, wenn nicht, werden die entsprechenden Objektreferenzen mit Lazy-Loading von der Engine geladen, direkt in den Heap geschrieben und von der JVM zurückgegeben. Klassische Selects sind überflüssig. Gemäß den Entwicklern funktioniert EclipseStore durch Lazy-Loading auch ausgezeichnet bei großen Datenmengen bei gleichzeitig geringer RAM-Kapazität, da man wie beim Caching nur heiße Daten im Memory halten soll. Dennoch gilt auch für EclipseStore: Je mehr Memory zur Verfügung steht, desto besser.

Eine Schemamigration wird zur Laufzeit gelöst. Beim Laden eines Objekts wird es mit seiner Klasse verglichen. Einfache Änderungen an einer Klasse etwa neue oder entfernte Felder sowie Änderungen primitiver Typen lassen sich nur von einer Heuristik auflösen. Für komplexere Fälle können Entwickler ein Type-Mapping definieren. Durch erneute Persistierung sammeln sich unterschiedliche Objektversionen im Storage an. Ein spezieller Garbage Collector entfernt im Hintergrund permanent veraltete Objekte und reorganisiert den Storage. Per REST oder über eine Web-UI kann man auf die persistenten Daten darin zugreifen. Eine CSV-Im-/-Exportfunktion hilft bei einer Migration.

EclipseStore erfordert Java Know-how

Bei den folgenden Konzepten wird es jedoch kontrovers. Um externen Anwendungen den Zugriff auf die Daten zu ermöglichen, müssen spezielle Schnittstellen dafür in Java implementiert sein. Der Zugriff selbst kann dann via REST oder GraphQL erfolgen, aber immer innerhalb einer Anwendung. Es gibt keinen Datenbank-Server mehr. Des Weiteren gibt es noch keine SQL-Unterstützung, was sich aber in Kürze ändern soll. Die aber wohl größte Herausforderung bei EclipseStore ist das Concurrency Handling. Alle Datenbankoperationen finden auf ein und demselben Objektgraphen statt. Um konkurrierende Zugriffe kümmert sich Java, Entwickler müssen sich aber für eine von mehreren Methoden entscheiden und vor allem die Funktionsweise kennen, etwa. Synchronized und ReentrantLock. Für die einen erscheint das zu komplex, für die anderen gehört es zum Java-Grundwissen. Dennoch arbeitet man an weiteren Vereinfachungen für das Concurrency-Handling.

EclipseStore ist für den Einsatz in einer einzigen JVM konzipiert. Für die Entwicklung verteilter EclipseStore Anwendungen gibt es von MicroStream einen Cluster, mit dem sich beliebig große und komplexe Objektgraphen über beliebig viele JVMs replizieren und hohe Lasten damit horizontal verteilen lassen. Der Cluster lässt sich dann auch wieder wie ein Datenbank-Server nutzen und ermöglicht Abfragen durch beliebige externe Services (Stateless Services, Python, .NET, NodeJS ec.) via REST und GraphQL. Der Cluster ist als SaaS Service für AWS sowie für On-premises verfügbar, jedoch nicht Open-Source.

Abstrakt betrachtet entstand EclipseStore für das persistente Speichern von Objektgraphen und als Alternative für Hibernate. Das Konzept eignet sich vorrangig für Anwendungen, die eine deutlich schnellere Datenverarbeitung als konventionelle Datenbanken benötigen. Prädestinierte sind hier unter anderem Persistenz für Microservices und Serverless Functions, Caching, Searching sowie Anwendungen, die eine schnelle Response-Time, Low-Latency und Echtzeitdaten benötigen. Aber auch für leichtgewichtigen, schnell implementierbaren Data Storage ist das Projekt eine interessante Option.

Fazit

EclipseStore ist ein völlig neuer Ansatz für Persistenz in Java, der eine hohe Performance, hohe Kostenersparnisse in der Cloud und eine einfachere Implementierung verspricht, aber zu einem Paradigmenwechsel bei der gesamten Anwendungsentwicklung führt. Entwickler müssen sich von traditionellen Datenbankkonzepten lösen und sich auf Java-Kernkonzepte konzentrieren. Bei den Microservice Frameworks Helidon und Micronaut ist EclipseStore bereits fest integriert und auch für Spring Boot und Quarkus gibt es eine Extension.

Als Java-Library lässt sich EclipseStore als Maven Dependency in praktisch jedes Java Projekt einbinden. Die einzige Voraussetzung ist Java 11. Die Engine lässt sich auch mit anderen JVM Sprachen wie Kotlin nutzen und läuft zudem auf sämtlichen Android Geräten, wo es vor allem als Alternative zu Room und SQLite gedacht ist. Als Nächstes soll auf Basis von EclipseStore ein neuer Standard analog zum JPA-Standard entwickelt und EclipseStore die Referenzimplementierung werden. Auch die Portierung des Projekts auf andere Programmiersprachen und Plattformen wie .NET ist geplant. Ausführliche Infos zu EclipseStore finden sich auf der Webseite des Projekts oder auf GitHub.

()