© Excellent backgrounds/Shutterstock.com
Überblick und Zugriff mit Objectify

Cloud-Datenspeicher objektiv betrachtet


Wer nicht mit den drei Normalformen unter dem Kopfkissen schläft und in der Cloud nur ein großes Datenschutzproblem sieht, kann sich im Folgenden einen kleinen Überblick über den Google Cloud Datastore verschaffen, eine moderne NoSQL-Datenbank in der Cloud. Vor allem werden wir uns anschauen, wie man diesen ohne größere Schmerzen von Java aus anspricht. Dazu gibt es ein Low-Level-API von Google und ein modernes Mapping-Framework mit dem schönen Namen Objectify.

Neben diversen Möglichkeiten, Docker-Container in der Cloud zu hosten, bietet Google mit seiner Google App Engine bereits seit Anfang 2008 eine echte Platform-as-a-Service-(PasS-)Lösung an. App Engine macht es leicht, hoch skalierbare Anwendungen auf Basis der standardisierten Dienste der App-Engine-Plattform zu schreiben. Und da die meisten nicht trivialen Anwendungen irgendeine Form von persistenter Datenhaltung benötigen, bieten App Engine und die Google Cloud allgemein hier einige Möglichkeiten. Interessant sind zum einen Cloud SQL, das relationale MySQL- oder PostgreSQL-Datenbankinstanzen in der Cloud zur Verfügung stellt, und vor allem die dokumentenbasierte NoSQL-Datenbank Google Cloud Datastore [1].

Während Cloud SQL, wie der Name schon sagt, die altbekannten Tugenden relationaler Datenbanken bietet, also vor allem transaktionsbasiert arbeitet und so die Datenkonsistenz stets sicherstellt, müssen wir auch beim Cloud Datastore nicht völlig auf diese Eigenschaften verzichten, auch er bietet ACID-Transaktionen. Darüber hinaus wartet der Datastore mit den Vorteilen einer modernen NoSQL-Datenbank auf: Die Speicherung erfolgt schemalos und hoch skalierbar. Der Datastore repliziert die Daten innerhalb der Google-Infrastruktur automatisch und für den Benutzer völlig transparent. Die Daten werden in Dokumenten gespeichert, die als Entity bezeichnet werden. Dort werden die Daten typisiert in Schlüssel/Wert-Paaren, den Properties, abgelegt. Das Typensystem bietet dabei die üblichen Datentypen wie Integer und Text String, aber auch einige hoch spezialisierte Typen wie Rating für das Abspeichern von Kundenbewertungen oder Link für URLs.

Weiterhin wird eine Entity durch ihren Key identifiziert, der wiederum aus mehreren Komponenten besteht. Zunächst ist da das Kind der Entity: eine Art Typbezeichnung, z. B. Person. Dann besitzt der Key natürlich einen Identifier, der eine Entity innerhalb eines Kinds eindeutig identifiziert. Der Identifier kann entweder eine meist automatisch generierte numerische ID sein oder ein sprechender Identifier in Form eines Name-Strings. Im Fall einer Entity Person wären also sowohl eine vom Datastore generierte ID 8459 als auch beispielsweise ein eindeutiger Log-in peterm2 als Name denkbar. Außerdem kann man noch einen Namespace vergeben, um beispielsweise Mandantenfähigkeit zu realisieren. Und schließlich kann der Key noch einen Pfad aller seiner übergeordneten Entitys in Form des Ancestor Path enthalten, aber dazu später mehr.

Abbildung 1 zeigt das Beispiel einer einfachen Entity des Kinds Person mit zwei String-Properties.

freitag_cloud_1.tif_fmt1.jpgAbb. 1: Beispielhafte Darstellung einer Entity

Transaktionen mit dem Datastore

Der Schlüssel für den Spagat zwischen Skalierbarkeit und Transaktionen liegt im wahrsten Sinne des Worts im Ancestor Path, den man als Teil des Keys für eine Entity angeben kann. Über diesen Pfad setzen wir eine Entity in eine hierarchische Beziehung mit ihren Vorgänger-(Ancestor-)Entitys (Abb. 2). Die so zusammengefassten Entitys bilden dann eine sogenannte Entity Group. Das hilft Transaktionen insofern, als die als zusammengehörig markierten Daten nun in der verzweigten, redundant ausgelegten Infrastruktur auch gezielt zusammen auf einem Server gespeichert werden können. Und dadurch wird das gemeinsame Ändern der Daten innerhalb einer Transaktion in einer vernünftigen Laufzeit möglich. Das ist der Fall, da nun nicht mehr auf andere Server innerhalb des Netzwerks gewartet werden muss, um festzustellen, ob die Transaktion durchführbar ist oder zurückgerollt werden muss. Ein Replizieren der gesamten Entity Group auf alle anderen Server muss aber selbstverständlich dennoch erfolgen und findet synchron statt. Deshalb ist der Schreibdurchsatz mit etwa einem Commit pro Sekunde und Entity Group auch als gelinde gesagt eher langsam zu bezeichnen. Lesen über eine Ancestor Path Query ist dafür dann aber auch „strongly consistent“, also vollständig konsistent.

freitag_cloud_2.tif_fmt1.jpgAbb. 2: Entitys, die in einer Ancestor-Beziehung stehen

Der Datastore geht sogar noch weiter und erlaubt das Zusammenfassen mehrerer Entity Groups in einer einzigen Transaktion. Um genau zu sein, können maximal 25 Entity Groups gleichzeitig an einer Transaktion teilnehmen. Hierbei kommen aber natürlic...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang