Sieben Cloud Spanner-Mythen

Einführung in Cloud Spanner

Cloud Spanner ist eine unternehmenstaugliche, global verteilte und extern konsistente Datenbank mit unbegrenzter Skalierung und 99,999 % Verfügbarkeit. Sie erfordert keine Wartungsfenster, bietet eine vertraute PostgreSQL-Schnittstelle und verbindet die Vorteile relationaler Datenbanken mit der unübertroffenen Skalierbarkeit und Verfügbarkeit nicht-relationaler Datenbanken.

Spanner bietet Unternehmen, die ihre Software-Ausstattung modernisieren und vereinfachen möchten, neue Möglichkeiten, um ihre Vorstellung und Nutzung von Datenbanken für die Entwicklung neuer Anwendungen und Kundenerlebnisse zu transformieren.

Es ist nicht einfach, die richtige Datenbank für Ihre Workloads auszuwählen. Der Markt bietet unzählige Optionen, die sich in Sachen Onboarding und Betrieb teilweise deutlich unterscheiden. Das Google Cloud-Team möchte Ihnen gerne dabei helfen, sich in diesem großen Angebot zurechtzufinden: In diesem Blogbeitrag möchten wir sieben Missverständnisse aufklären, die im Zusammenhang mit Spanner besonders oft aufkommen, damit Sie eine faktenbasierte Entscheidung treffen können.

Mythos Nr. 1: Der Einsatz von Spanner ist nur bei massiven Workloads sinnvoll

Es ist in der Tat so, dass Spanner für die weltweit verfügbaren Google-Produkte wie YouTube, Drive und Gmail eingesetzt wird und viele groß angelegte Transformationen  – unter anderem bei Uber, Niantic und Sharechat  – möglich gemacht hat. Richtig ist auch, dass Spanner zu Spitzenzeiten mehr als eine Milliarde Abfragen pro Sekunde verarbeitet.

Dennoch schätzen auch viele Kunden mit kleineren Workloads – also weniger Transaktionen und geringerer Speichergröße – die Verfügbarkeit und Skalierbarkeit von Spanner. So laufen beispielsweise auch die kleineren Workloads von Google Password Manager auf Spanner. Kunden wie diese entscheiden sich für Spanner, weil sie sich keine Ausfallzeiten leisten können, beim Betrieb ihrer Anwendungen auf Hochverfügbarkeit angewiesen sind und verlässliche Skalierbarkeit für ihr künftiges Wachstum benötigen.

Unbegrenzte Skalierbarkeit mit höchster Verfügbarkeit ist in vielen Branchen, wie der Gaming Industrie und dem Einzelhandel, entscheidend – wenn etwa ein Spiel nach der Veröffentlichung über Nacht zum Verkaufsschlager wird oder ein Einzelhändler am Black Friday oder Cyber Monday plötzlich einen besonders hohen Ansturm bewältigen muss. 

Ganz gleich, wie groß die Workloads sind: Jedes Unternehmen, das auf dem Weg in die Cloud ist, legt Wert auf Skalierbarkeit und Verfügbarkeit und möchte den Arbeits- und Kostenaufwand für Patches, Upgrades und andere Wartungsarbeiten verringern.

Mythos Nr. 2: Spanner ist zu teuer

Anstatt bei der Beurteilung einer Datenbank nur auf den Listenpreis zu schauen, sollten Sie die Gesamtbetriebskosten und den Gebrauchswert, den sie bietet, mit in Betracht ziehen. Spanner bietet einen erheblichen Mehrwert in entscheidenden Punkten wie Verfügbarkeit, Preis-Leistungs-Verhältnis und verringerte Betriebskosten.

• Verfügbarkeit: Spanner überzeugt mit hoher Verfügbarkeit und Zuverlässigkeit durch synchrone Replikation von Daten. Was die Notfallwiederherstellung betrifft, bietet Spanner 0-RPO und 0-RTO für zonale Ausfälle regionaler Instanzen und regionale Ausfälle überregionaler Instanzen. Das bedeutet weniger Ausfallzeiten und mehr Umsatz.

• Preis-Leistungsverhältnis: Mit Blick auf das Preis-Leistungs-Verhältnis ist Spanner die ideale Lösung für anspruchsvolle und leistungskritische Anwendungen, denn großartige Kundenerlebnisse erfordern konsistent optimale Latenzzeiten.

• Verringerte Betriebskosten: Bei Spanner profitieren Kunden von Upgrades und Schemaänderungen ohne Ausfallzeiten und ohne Wartungsfenster. Dank automatischer Fragmentierung ist, anders als bei herkömmlichen Datenbanken, keine aufwändige Skalierung nötig. Das bedeutet weniger Verwaltungsaufwand und damit mehr Zeit für Innovationen.

• Sicherheit & Compliance: Spanner verschlüsselt Daten bereits standardmäßig bei der Übertragung über seine Client-Bibliotheken und bei der Speicherung mit von Google verwalteten Schlüsseln. CMEK-Unterstützung für Spanner sorgt dafür, dass Sie jetzt die volle Kontrolle über die Schlüssel haben. Zudem bietet Spanner Unterstützung für VPC Service Controls und kann dank Compliance-Zertifizierungen und der nötigen Genehmigungen für Workloads verwendet werden, die ISO 27001, 27017, 27018, PCI DSS, SOC1|2|3, HIPAA und FedRAMP erfordern.

Bei Spanner haben Sie die Gewissheit, dass die Sicherheit, Verfügbarkeit und Zuverlässigkeit Ihrer Daten nicht beeinträchtigt werden.

Profi-Tipp: Nutzen Sie den Auto-Scaler, um Ihre Spanner-Instanzen richtig zu dimensionieren, und TTL, um die Speicherdatenmenge zu reduzieren.

Mythos Nr. 3: Sie müssen Skalierung, Konsistenz und Latenzzeit gegeneinander abwägen

Tatsächlich lässt sich Spanner je nach Anwendungsfall und Konfiguration der Instanz so nutzen, dass Sie keine Kompromisse bezüglich Konsistenz, Latenz und Skalierung schließen müssen.

Um Datenkonsistenz zu gewährleisten, verwendet Spanner ein synchrones, Paxos-basiertes Replikationsschema, bei dem die Replikate jede Schreibanforderung bestätigen. Ein Schreibvorgang wird nur dann ausgeführt, wenn die Mehrzahl der Replikate (z. B. 2 von 3) als sogenanntes Quorum zustimmen. Bei regionalen Instanzen befinden sich die Replikate in der Region. Deshalb sind die Schreibvorgänge schneller als bei überregionalen Instanzen, deren Replikate auf mehrere Regionen verteilt sind. Im letzteren Fall kann die mehrheitliche Genehmigung von Schreibvorgängen mehr Zeit in Anspruch nehmen und die Latenz geringfügig erhöhen. Dennoch werden auch Spanner-Multiregionen geografisch sorgfältig konfiguriert, so dass die Replikate stets schnell genug kommunizieren können und die Schreiblatenzen annehmbar bleiben.

Lesevorgänge werden als Strong Read (standardmäßig) oder als Stale Read ausgeführt. Ein Strong Read ist ein Lesevorgang, bei dem garantiert alle bis zum aktuellen Zeitpunkt übertragenen Daten erfasst werden. Ein Stale Read hingegen erfasst den Datenstand eines länger zurückliegenden Zeitpunkts. Bei einem Strong Read garantiert das Replikat, das die Daten bereitstellt, dass alle bis zum Beginn des Lesevorgangs übertragenen Daten angezeigt werden. Hierfür muss sich dieses Replikat unter Umständen beim Leader-Replikat rückversichern, dass es über die neuesten Daten verfügt. Im Falle einer überregionalen Instanz, bei der die Daten nicht von einem Leader-Replikat bereitgestellt werden, kann die Leselatenz deshalb etwas höher ausfallen als bei der Bereitstellung aus einer Leader-Region. Ein Stale Read liefert Daten, die zu einem Zeitpunkt in der Vergangenheit übertragen wurden, und kann daher mit sehr geringer Latenz vom nächstgelegenen Replikat bereitgestellt werden, das über den Datenbestand zum angeforderten Zeitpunkt verfügt. Für latenzkritische Anwendungen können Stale Reads mit einem empfohlenen Stale-Read-Wert von 15 Sekunden sinnvoll sein.

Mythos Nr. 4: Spanner spricht kein PostgreSQL

Tatsächlich ist Spanner sehr flexibel und kann nicht nur in einem SQL-Dialekt, der auf dem ANSI 2011-Standard basiert, sondern auch über eine für Leistung und Komfort optimierte REST oder gRPC API-Schnittstelle mit der Datenbank kommunizieren. Darüber hinaus haben wir kürzlich eine PostgreSQL-Schnittstelle für Entwicklungsteams eingeführt, die lieber auf der ihnen vertrauten Oberfläche der weit verbreiteten Umgebung arbeiten. Die PostgreSQL-Schnittstelle stellt ein umfangreiches Subset des PostgreSQL Open Source SQL-Dialekts mit der gängigen Abfragesyntax sowie wichtigen Funktionen und Operatoren bereit. Sie unterstützt alle grundlegenden Open Source PostgreSQL-Datentypen, DDL-Syntax und Informationsschema-Ansichten. So können Sie die mächtige relationale Semantik von Spanner auch in Ihrer vertrauten PostgreSQL-Umgebung nutzen.

Weitere Informationen zu unserer PostgreSQL-Schnittstelle finden Sie hier.

Mythos Nr. 5: Beobachtbarkeitsdaten können nur in der Spanner Console abgerufen werden

Die Client-Bibliotheken von Spanner unterstützen OpenCensus Tracing und Metriken, die Einblick in die Client-Interna bieten und die Fehlersuche in der Produktion erleichtern. Client-seitige Traces und Metriken enthalten sitzungs- und transaktionsbezogene Informationen.

Außerdem unterstützt Spanner den OpenTelemetery-Empfänger, sodass Sie Metriken aus Cloud Spanner-Systemtabellen mühelos verarbeiten, visualisieren und in das Application Monitoring (APM)-Tool exportieren können. Das kann entweder eine Open-Source-Kombination aus einer Zeitreihen-Datenbank und einem Grafana-Dashboard oder aber ein kommerzielles Angebot wie Splunk, Datadog, Dynatrace, NewRelic oder AppDynamics sein. Zudem haben wir Grafana-Referenzdashboards veröffentlicht, sodass Sie die häufigsten Anfragen von Nutzerinnen und Nutzern wie „Warum ist meine Tail-Latenz so hoch?“ oder „Warum sehe ich trotz unveränderter Workload eine CPU-Spitze?“ sofort bearbeiten können. Dieser Docker-Dienst ist ein Beispiel dafür, wie der Cloud Spanner-Empfänger mit dem Prometheus-Exporter und Grafana-Dashboards zusammenarbeiten kann.

Wir setzen auch weiterhin auf offene Standards und die Integration mit unserem Partnernetzwerk. Außerdem entwickeln wir die von Google Console bereitgestellte Beobachtbarkeit weiter, um Kunden unabhängig von ihrem Standort das bestmögliche Erlebnis zu bieten.

Mythos Nr. 6: Spanner eignet sich nur für globale Workloads, die Kopien in mehreren Regionen voraussetzen

Tatsächlich bietet Spanner neben einer Reihe von überregionalen Instanzkonfigurationen in jeder GCP-Region auch eine regionale Konfiguration. Jeder regionale Knoten wird in drei Zonen innerhalb der Region repliziert, ein überregionaler Knoten mindestens fünfmal in verschiedenen Regionen. Eine regionale Konfiguration bietet eine Four-Nines-Verfügbarkeit und Schutz vor zonalen Ausfällen.

Eine überregionale Instanzkonfiguration ist in der Regel angezeigt, wenn Ihre Anwendung Workloads an mehreren geografischen Standorten umfasst oder Ihr Unternehmen eine Verfügbarkeit von 99,999 % und Schutz vor regionalen Ausfällen benötigt. Mehr dazu erfahren Sie hier.

Mythos Nr. 7: Spanner-Schemaänderungen erfordern teure Sperren

Die Wahrheit ist, dass Spanner auf Tabellenebene überhaupt keine Sperren hat. Seine Architektur ermöglicht Spanner, mehrere gleichzeitige Schema- und Datenversionen zu erkennen und zu verwalten. Das erlaubt qualifizierte Ad-hoc- und Online-Schemaänderungen ganz ohne Ausfallzeiten, zusätzliche Tools, Migrationspipelines oder komplexe Rollback-/Backup-Pläne. Nach dem Start einer Schemaaktualisierung können Sie ohne Unterbrechung weiter in der Datenbank schreiben und lesen, während Spanner das Update-Backfill verarbeitet – ganz gleich, ob Ihre Tabelle zehn Zeilen oder zehn Milliarden Datensätze umfasst.

Dieser Mechanismus kann auch für die Wiederherstellung zu einem bestimmten Zeitpunkt und für Snapshot-Abfragen verwendet werden, um sowohl das Schema als auch den Zustand der Daten mit einer bestimmten Abfragebedingung und einem bis zu sieben Tage zurückliegenden Zeitstempel zu regenerieren.

Nun kennen Sie die Wahrheit über Cloud Spanner und können direkt einsteigen – besuchen Sie unsere Website.