Clouddatenbanken lassen sich prinzipiell klassisch wie im eigenen Rechenzentrum betreiben. Dazu installiert der IT-Verantwortliche die entsprechende Datenbank einfach als virtuelle Maschine. Die Administration ist in diesem Fall äquivalent zu einer lokalen Verwaltung. Aspekte wie Hochverfügbarkeit, Patching, Backup und Restore, Wiederherstellung im Desaster-Fall oder Skalierung bleiben im Verantwortungsbereich des Administrators.

Um den Unternehmen den Betrieb von Datenbanken möglichst zu vereinfachen, stellen die Cloudanbieter Datenbanken auch als Managed Service zur Verfügung. Dabei ist der Kunde im Großen und Ganzen nur noch für die Applikation und die Datenbanklogik verantwortlich, braucht sich aber keine Gedanken um operative Belange zu machen.

Google gehört mit seiner Google Cloud Platform (GCP) zu den Pionieren der Cloud und ist mit seiner Plattform neben Amazon Web Services (AWS) und Microsoft Azure einer der drei größten Cloudprovider. Als solcher bietet er ein umfangreiches Portfolio an Datenbanktechnologien an. Doch die Wahl der richtigen Datenbank ist nicht immer einfach und sollte genau überlegt sein. Helfen kann dabei ein Kriterienkatalog:

- Zuerst ist das Zugriffsschema wichtig: Klassische Anwendungen wie beispielsweise Fakturierungssoftware greift mithilfe von SQL auf die Datenbank zu. Die DB muss ein entsprechendes relationales Schema haben, hochverfügbaren Betrieb erlauben und natürlich zu jedem Zeitpunkt im Datenbestand konsistent sein.

- Auch die Zugriffe können unterschiedlich sein: Relationale Datenbanken arbeiten mit den SQL-Befehlen SELECT, INSERT, UPDATE oder DELETE und unterstützen in der Regel meist Transaktionen. No-SQL-Datenbanken dagegen nutzen oft eine REST-Schnittstelle. Objektspeicher wiederum bringt Dateien in Form von Objekten zum Einsatz. Alternativ kann eine DB auch das Streamen von Daten und Batch-Vorgänge unterstützen.

- Von Relevanz ist auch die Speichermenge: Relationale Datenbanken bewegen sich in der Regel im Bereich von einigen TByte, Data-Warehouse-Systeme und No-SQL-Datenbanken dringen in den PByte-Bereich vor und beim Objektspeicher sind konzeptionell keine Größenbeschränkungen gegeben.

Daneben beschreibt im reinen Sinn Cloud-Storage keine Datenbanken, da es aber als Storage-Backend in vielen No-SQL- und Big-Data-Systemen Anwendung findet, ist eine Betrachtung dennoch sinnvoll. Cloud-Storage legt seine Daten in Buckets ab. Im Vergleich zu einem Dateisystem existieren keine Ordner, vielmehr sind alle Objekte in einem flachen Namensraum gelagert. Objekte werden repliziert und sind somit immer hochverfügbar abgespeichert. Durch die Replikation ist die Durability (Haltbarkeit) sehr groß, sie beträgt bis zu 99,999999999 Prozent. Der Zugriff auf den Objektspeicher erfolgt über REST- oder API-Schnittstellen. Dadurch und architekturbedingt sind die Latenzen beim Abruf von Objekten eher groß und bewegen sich fast durchgängig im zweistelligen Millisekundenbereich. Zum Einsatz kommen Objektspeicher daher in der Regel für unstrukturierte Daten.

Bei Cloud SQL handelt es sich um ein Service, der sowohl MySQL, PostgreSQL als auch Microsoft SQL Server als Ma-naged Service anbietet. Als solcher ist der Betrieb der Datenbank durch Google gegeben, das heißt, Patches und Updates befinden sich im Verantwortungsbereich von Google. Backup und Restore kann der Administrator beim Anlegen der Datenbank einfach konfigurieren – den Nutzerzugriff muss er allerdings immer noch selbst einrichten.

Das Anlegen einer Datenbank gelingt in der grafischen Benutzeroberfläche relativ einfach (Bild 1). Dazu klicken Sie im Menü oben links auf "Databases / SQL". Falls noch keine DB existiert, fahren Sie direkt mit dem Wizard fort und klicken auf "Create Instance". Zur Auswahl stehen anschließend MySQL in den Versionen 8.0, 5.7 und 5.8 und PostgreSQL in den Versionen 9.6, 10, 11, 12, 13 und 14. Alternativ steht eine gemanagte Datenbank-Instanz mit Microsoft SQL Server in den Versionen 2019 und 2017 bereit.

Für das Erzeugen der Datenbank ist eine eindeutige Bezeichnung notwendig. Diese sollten Sie möglichst mit zufälligen Zeichen versehen, denn beim Löschen einer Instanz können Sie den Namen für sieben Tage nicht mehr wiederverwenden. Von Relevanz ist zudem die Region: Wollen Sie die Datenbank in Frankfurt bereitstellen, wählen Sie als Region "europe-west3". Soll die Datenbank hochverfügbar sein, nutzen Sie bei "Zonal Availability" die Option "Multiple zones (Highly available)". Dabei ist es möglich, die "Primary Zone" und die "Secondary Zone" genau zu spezifizieren. Allerdings fallen bei Hochverfügbarkeit auch höhere Kosten an, denn damit ein Failover zu jedem Zeitpunkt möglich ist, ist ein Standby-Server notwendig.

Beim Hardware-Sizing haben Sie große Auswahl, eine kleine Testdatenbank mit PostgreSQL oder MySQL können Sie schon mit einem Shared-Core mit einer vCPU und 614 MByte RAM betreiben. Die Höchstgrenze liegt dagegen zum jetzigen Zeitpunkt bei 96 vCPUs und 624 GByte Arbeitsspeicher. Als Storage steht Festplattenspeicher in Form von magnetischen als auch von SSD-Platten bereit.

Die Größe bestimmt auch die Leistung der Festplatte, pro GByte Speicherplatz gibt es 30 IOPS für das Lesen und Schreiben der SSD-Festplatten – bei magnetischen Platten sind diese Werte für das Schreiben allerdings geringer. Beim Datendurchsatz verhält es sich ähnlich – auch dieser ist an die Größe gekoppelt.

Standardmäßig werden Datenbanken mit öffentlichen IP-Adressen bereitgestellt. Falls Sie dies aus Sicherheitsgründen nicht wünschen, stellen Sie die Datenbank nur mit privaten IP-Adressen in einem VPC bereit. Dabei sind normale als auch geteilte – sogenannte Shared-VPC – unterstützt.

Bei den Backupoptionen können Sie ein Zeitfenster einstellen, in dem eine automatische Sicherung erfolgt. Zusätzlich ist es möglich, Point-in-time-Recovery zu aktivieren, um damit im Fehlerfall feingranular jeglichen Datenbankstand wieder einspielen zu können. Standardmäßig speichert Cloud SQL die letzten sieben Backups. Auch die Backupregion konfigurieren Sie an dieser Stelle. Neben der Auswahl einer dedizierten Region steht auch ein Multi-Region-Backup zur Verfügung. Dabei sind Sie zum Beispiel in der Lage anzugeben, dass die Sicherung in verschiedene Regionen innerhalb der EU erfolgen soll.

Da Cloud SQL einen gemanagten Datenbankservice darstellt, ist es notwendig, Zeitfenster für das Patchen und Updaten festzulegen. Dies erledigen Sie, wie für die anderen Optionen auch, über die grafische Benutzeroberfläche. Weiterhin ist es möglich, datenbankspezifische Optionen zu setzen. Bei PostgreSQL ist dies beispielsweise das Auditieren von Abfragen oder die Anzahl der möglichen gleichzeitigen Verbindungen. Für Entwickler ist die Option "Insights" interessant, mit der sich zur Laufzeit der Datenbank Performanceprobleme identifizieren lassen.

Natürlich sind Cloud-SQL-Datenbanken nicht nur mit Hilfe der grafischen Benutzeroberfläche erstellbar. Beliebt ist insbesondere das Anlegen mit der CLI oder Terraform. Ein einfacher Aufruf zum Erstellen einer MySQL-Datenbank sieht wie folgt aus:

Auch die entsprechende Terraform-Ressourcen-Definition ist nicht schwer, wie das folgende Beispiel zeigt:

Für Firmen, die die Vorzüge einer relationalen Datenbank und die Skalierung von NoSQL-Datenbank nutzen wollen, ist Cloud Spanner eine interessante Wahl. Es bietet Kapazitäten in den PByte-Bereich hinein und lässt sich gleichzeitig multiregional, also in verschiedenen Regionen gleichzeitig betreiben. Dies ist insbesondere für Anwendungen interessant, die nur eine sehr geringe oder gar keine Downtime tolerieren. Im Gegensatz zu klassischen relationalen Datenbanken skaliert Spanner nicht vertikal, sondern horizontal. Die Replikation erfolgt dabei automatisch und dabei bleibt die DB zu jedem Zeitpunkt in einem global konsistenten Zustand.

Cloud Spanner unterstützt einen großen Funktionsumfang klassischer Datenbanken. Dazu gehört, dass das System kompatibel zu Standard-SQL mit ANSI 2021 ist. Darüber hinaus gibt es Unterstützung für Transaktionen. Wie andere DBs in der Google-Cloud ist Cloud Spanner in das GCP-Ökosystem eingebunden und bietet die Verschlüsselung mit KMS, Auditlogging und eine Integration in das Identity- und Accessmanagement. Neben typischen Schnittstellen wie zum Beispiel JDBC existieren für den Zugriff Clientbibliotheken in den Programmiersprachen Java, Python und Node.js.

Bei der Migration einer bestehenden Anwendung müssen Sie aber beachten, dass nicht alle Features klassischer relationaler DBs unterstützt werden. Beispielsweise können Sequences für Primärschlüssel keine Verwendung finden. Sequences machen über numerische Werte die Zeilen eindeutig. Da Cloud Spanner die Daten aber aufgrund des Primärschlüssels auf Knoten verteilt und der Primärschlüssel dafür alphanumerisch sein muss, entfallen Sequences daher.

Ein weiterer Wermutstropfen ist die fehlende Unterstützung für Trigger, Stored Procedures und User Defined Functions (UDF). Aus diesem Grund ist Cloud Spanner nicht für jeden Einsatzzweck geeignet. Nichtsdestotrotz gibt es eine Reihe von Kriterien, die den Einsatz von Cloud Spanner interessant machen: Dazu gehören Anwendungen, die für eine einzelne Datenbank zu groß geworden sind oder nur mittels Optimierungsmaßnahmen wie zum Beispiel Datenbank-Sharding überhaupt noch auf klassischen DBs laufen. Benötigen Unternehmen zusätzlich transaktionale Konsistenz oder weltweite Verfügbarkeit, spricht dies ebenfalls für Cloud Spanner.

Im NoSQL-Umfeld dagegen verortet ist Cloud Firestore und fungiert als Dokumentendatenbank. Im Gegensatz zu den bereits beschriebenen DBs arbeitet Fire-store komplett serverless und somit managementfrei. Bei dieser DB zahlen Sie nur den tatsächlichen Verbrauch und müssen sich keine Gedanken um Rightsizing oder nicht ausgelastete Ressourcen machen. Das Preismodell sieht vor, dass Sie einerseits einen Betrag für die gespeicherte Datenmenge in GByte, andererseits für die Anzahl der Lese-, Lösch- und Schreibvorgänge entrichten.

Das Haupteinsatzgebiet von Firestore sieht Google im Bereich mobiler, Web- und IoT-Datenbanken. Besonders interessant dabei ist der Offline-Modus für Smart-phones oder Tablets. Sobald der Nutzer wieder online ist, kann er mit einer integrierten Live-Synchronisation Daten mit dem Firebase-Backend in der Google-Cloud abgleichen. Bei der Arbeit mit mehreren Geräten sind die Echtzeit-Updates interessant, die eine Synchronisierung von Daten über verschiedene verbundene Geräte hinweg ermöglicht. Ein Pluspunkt für Entwickler stellt auch die Tatsache dar, dass Cloud Firestore (eine hoch skalierbare NoSQL-Datenbank für Anwendungen) Transaktionen unterstützt.

Aber es gibt auch einige technische Nachteile: Cloud Firestore ist nicht für Anwendungsfälle ausgelegt, die hohe Schreibperformance erfordern. Auch wenn Sie viel Wert auf Analytics legen, ist Firestore nicht unbedingt die erste Wahl. Hier lohnt es sich, genaueres Augenmerk auf Cloud SQL oder Cloud Big Table zu lenken. Normale Lesevorgänge dagegen funktionieren unkompliziert und schnell und sind über den Caching-Service "Memcached" weiter optimierbar.

Ähnlich wie Cloud Spanner bietet Firestore eine automatische Replikation für mehrere Regionen und garantiert dabei eine strikte Konsistenz der Daten. Die Verfügbarkeit der Daten gibt Google mit 99,999 Pzozent an. Die Datenmenge, die sich in Firestore ablegen lässt, ähnelt im Großen und Ganzen Cloud SQL und bewegt sich im TByte-Bereich. Das Speichern von Daten in Firestore geht schnell von der Hand. Da Sie im Unterschied zu einer relationalen Datenbank kein Schema anlegen müssen, kann die Speicherung unmittelbar beginnen.

Applikationen greifen auf die Datenbank mit Hilfe der Client-API zu. Wie bei den anderen Produkten von Google auch, existieren dabei Clientbibliotheken in einer Vielzahl von Programmiersprachen. Listing 1 zeigt, wie das mit Node.js funktioniert. Das Listing legt einen Key und eine Entität an. Der Key lautet "Task" und die Entität referenziert den Key und beinhaltet ein data-Element mit den Feldern "name", "description" und "done". Anschließend interagiert es mit der Firestore-API und speichert die Entität ab.

Abfragen lassen sich genauso mit der Clientbibliothek implementieren, wie das folgende Beispiel zeigt:

Bigtable ist eine "Fully Managed" NoSQL-Datenbank, die aus dem Big-Data-Umfeld entspringt. Sie erlaubt die Ablage von Daten im PByte-Bereich und den Zugriff auf diese mit geringer Latenz. Die darunterliegende Storage-Engine kümmert sich dabei um die Skalierung, so dass der IT-Verantwotliche kaum Optimierungsaufgaben wahrnehmen muss.

Erreicht wird eine derartige Performance, indem Bigtable intern eine Trennung zwischen Processing und Storage vornimmt. Bild 2 zeigt, wie Clients auf Nodes zugreifen. Ein Bigtable-Node ist dabei für eine Untermenge von Daten verantwortlich. Wenn mehr Daten vorhanden sind oder mehr Leistung erwünscht ist, können Sie die Anzahl der Knoten erhöhen. Als Storage-Typ stehen HDD- oder SSD-Platten bereit. Die HDDs sind prinzipiell deutlich günstiger – aber insbesondere bei Random-Read-Vorgängen mit deutlich größeren Zugriffslatenzen behaftet. Dagegen bieten sie gute Leistung bei Batch-Analytics-Anwendungen wie Machine Learning oder Data Analytics mit viel sequentiellem Lesen. Für den Echtzeitzugriff wie zum Beispiel beim Ad-Serving oder Recommendations-App sind dagegen SSDs zu empfehlen. Der Storage wird nach Datenmenge abgerechnet – Größeneinheit ist hier GByte.

Die Anzahl der Bigtable-Nodes lässt sich entweder manuell einstellen oder mit Auto-Scaling automatisch verwalten. Bei Ersterem fallen keine unvorhergesehenen Kosten an, Sie sollten aber den Auslastungszustand des Bigtable-Clusters im Auge behalten. Beim automatischen Verwalten stellt der Managed Service die Anzahl der Knoten automatisch ein und fügt je nach Auslastung Knoten hinzu beziehungsweise entfernt diese wieder. Falls Sie einen hochverfügbaren Cluster benötigen, ist dies über einen zweiten Cluster und Replikation möglich.

Die wichtigsten Anwendungsfälle für Bigtable sind Streaming und Batch-Vorgänge, aber auch Applikationen, die beim Datenzugriff eine niedrige Latenz benötigen. Der Zugriff auf Bigtable erfolgt in der Regel mit der Apache-HBase-Schnittstelle. Dies vermeidet einen Vendor-Lock-In, da der Zugriff nicht mittels einer proprietären Schnittstelle abgewickelt wird.

Die Speicherung von Daten erfolgt mithilfe von Schlüssel/Wert-Paaren, die in Tabellen abgelegt werden. Jede Zeile beschreibt dabei eine Entität und jede Spalte hat einen individuellen Wert. Spalten, die zusammengehören, lassen sich zu Familien zusammenfassen. Eine Indexierung erfolgt über den Zeilenschlüssel.

BigQuery ist ein vollständig verwaltetes, serverless Data Warehouse. Als solches skaliert es problemlos bis in den PByte-Bereich hinein – ohne operativen Aufwand. Google wirbt damit, dass die Gesamtbetriebskosten im Vergleich zu Mitbewerbern um 26 bis 34 Prozent günstiger sind. Zu den besonderen Features gehört, dass BigQuery seit einiger Zeit mit Machine-Learning-Funktionalität (ML) aufwartet. Insbesondere für Klassifikations- und Regressionsmodelle auf Basis von strukturierten Daten bietet es eine integrierte Plattform. ML-Funktionalitäten wie das Trainieren eines Modells oder das Ausführen von Predictions gelingen mit normaler SQL-Syntax und sind einfach erlernbar.

Typische Einsatzgebiete stellen dabei Empfehlungssysteme oder Regressionsanalysen dar. Mit BigQuery Omni hat sich Google anderen Cloudanbietern geöffnet und erlaubt die Abfrage von Daten, die beispielsweise in AWS oder Azure lagern. Ähnlich wie Microsoft mit seinem PowerBI bietet Google auch eine schnellen In-Memory-Analysedienst an, mit dem Nutzer große Datenmengen mit Antwortzeiten von unter einer Sekunde analysieren. Darüber hinaus fungiert BigQuery auch als System zur Analyse von räumlich-geografischen Informationen.

Das Laden von Daten in BigQuery kann aus unterschiedlichen Quellen erfolgen. Neben der Möglichkeit, lokale Daten zu nutzen, gelingt dies auch über Cloud-Storage-Buckets oder Google-Drive-Daten. Für eine Reihe von Fremdsystemen existieren spezielle Konnektoren, die sich mittels des BigQuery-Data-Services ansprechen lassen. Benötigen Sie eine eigene spezielle Logik beim Transformieren der Eingangsdaten, stehen die Google-Dienste "Data Fusion" und "Dataflow" bereit. Darüber hinaus existiert eine Reihe von weiteren Partnerintegrationen. Die Datenhaltung erfolgt in Tabellen, die sich zu Datasets zusammenfassen und mit entsprechenden Berechtigungen ausstatten lassen. Am einfachsten ist die Arbeit mit BigQuery mittels der Google Cloud Console.

Die Google Cloud Platform bietet IT-Verantwortlichen eine breite Produktpalette für den Betrieb von Datenbanken in der Cloud. Je nach Einsatzszenario hat der IT-Verantwortliche die Wahl, ob geringe Latenz, die Speicherung sehr großer Datenmengen oder auch Machine Learning im Vordergrund steht. Dabei kann er zusaätzlich festlegen, ob der Weg über klassisches SQL gefragt ist oder ob NoSQL seine Dienste zur Verfügung stellen soll.