Google Cloud Spanner verheiratet SQL mit NoSQL

Der neue Datenbankservice bringt die ACID-Eigenschaften relationaler Datenbanken und das von vielen NoSQL-Datenbanken genutzte CAP-Theorem unter einen Hut.

In Pocket speichern vorlesen Druckansicht 17 Kommentare lesen
Google Cloud Spanner verheiratet SQL mit NoSQL
Lesezeit: 2 Min.
Von
  • Alexander Neumann

Googles neuer Cloud-Dienst Cloud Spanner ist ein vollständig vorkonfigurierter Datenbankservice, bei dem die ACID-Eigenschaften (Atomicity, Consistency, Isolation und Durability) herkömmlicher (SQL-)Datenbanken sowie die Performance und Skalierbarkeit von NoSQL-Datenbanken unter einen Hut gebracht wurden. Er basiert auf der bislang nur intern bei Google genutzten Datenbank Spanner, die 2012 erstmals präsentiert wurde und danach grundlegend überarbeitet wurde. Google nutzt Spanner bislang für die Angebote Gmail, Google Photos und AdWords. Nun können also auch Kunden der Google Cloud Spanner für ihre eigenen Anwendungen und Services nutzen.

Cloud Spanner verwendet SQL bei Abfragen oder beim Abrufen von Informationen aus einem System. Hierin verhält sich der Datenbankdienst, wie es viele Datenbankexperten gewohnt sind. Darüber hinaus ist Cloud Spanner dazu entworfen, auch sehr große Datenmengen verarbeiten zu können, woran nicht selten herkömmliche relationale Datenbanken scheitern. Hier kommen für gewöhnlich NoSQL-Datenbanken wie Apache Cassandra ins Spiel, die für horizontale Skalierbarkeit und ein verteiltes Abarbeiten der Datenmengen stehen.

Letztlich komplettiert Google mit dem neuen Dienst das eigene Cloud-Datenbankangebot. Es reiht sich in die bestehenden Services Cloud SQL, das sich an Nutzer von SQL-Datenbanken richtet, dann Cloud Datastore, eine NoSQL-Datenbank, und Cloud Bigtable, eine Datenanalyse-Engine, ein. Zum genauerem Verständnis von Spanner, genauer gesagt zum Zusammenspiel mit CAP-Theorem (Consistency, Availability und Partition Tolerance) und TrueTime API, hat Google ein Whitepaper veröffentlicht, für das Eric Brewer verantwortlich zeichnet, der bei Google Vice President Infrastructure ist und nach dem das CAP-Theorem auch benannt ist. (ane)