Get best of the week

Google Cloud Spanner: gut, schlecht, böse

Hallo Habrowsk. Traditionell teilen wir weiterhin interessantes Material im Vorgriff auf den Start neuer Kurse. Heute haben wir speziell für Sie einen Artikel über Google Cloud Spanner veröffentlicht, der zeitlich auf den Start des AWS for Developers- Kurses abgestimmt ist .



Ursprünglich auf dem Lightspeed HQ-Blog veröffentlicht .

Als Unternehmen, das viele Cloud-basierte POS-Lösungen für Einzelhändler, Gastronomen und Online-Händler auf der ganzen Welt anbietet, verwendet Lightspeed verschiedene Arten von Datenbankplattformen für eine Vielzahl von Transaktions-, Analyse- und Suchfällen. Jede dieser Datenbankplattformen hat ihre eigenen Stärken und Schwächen. Als Google Cloud Spanner auf den Markt brachte, waren vielversprechende Funktionen, die in der Welt der relationalen Datenbanken beispiellos waren, wie praktisch unbegrenzte horizontale Skalierbarkeit und ein 99,999% Service Level Agreement (SLA). - Wir konnten die Gelegenheit nicht verpassen, es in unsere Hände zu bekommen!

Um einen umfassenden Überblick über unsere Erfahrungen mit Cloud Spanner sowie die von uns verwendeten Bewertungskriterien zu geben, werden wir die folgenden Themen behandeln:

  1. Unsere Bewertungskriterien
  2. Cloud Spanner auf den Punkt gebracht
  3. Unsere Bewertung
  4. Unsere Ergebnisse



1. Unsere Bewertungskriterien


Bevor wir uns mit den Funktionen von Cloud Spanner, seinen Ähnlichkeiten und Unterschieden mit anderen Lösungen auf dem Markt befassen, wollen wir zunächst die wichtigsten Benutzerfälle erläutern, die wir bei der Überlegung, wo Cloud Spanner in unserer Infrastruktur bereitgestellt werden soll, berücksichtigt haben:

  • Als Ersatz für die (vorherrschende) traditionelle SQL-Datenbanklösung
  • Wie eine OLTP-Lösung mit OLAP-Unterstützung

Hinweis: Zur Vereinfachung und zum einfachen Vergleich vergleicht dieser Artikel Cloud Spanner mit MySQL GCP Cloud SQL und der Amazon AWS RDS-Lösungsfamilie.

Verwenden von Cloud Spanner als Ersatz für eine herkömmliche SQL-Datenbanklösung


Wenn sich in einer herkömmlichen Datenbankumgebung die Antwortzeit auf eine Datenbankabfrage vordefinierten Anwendungsschwellenwerten nähert oder diese sogar überschreitet (hauptsächlich aufgrund einer Zunahme der Anzahl von Benutzern und / oder Abfragen), gibt es verschiedene Möglichkeiten, die Antwortzeit auf akzeptable Werte zu reduzieren. Die meisten dieser Lösungen umfassen jedoch manuelle Eingriffe.

Der erste Schritt, den Sie ausführen müssen, besteht beispielsweise darin, die verschiedenen Datenbankparameter in Bezug auf die Leistung zu betrachten und sie so zu konfigurieren, dass sie den Anwendungsnutzungsmustern am besten entsprechen. Wenn dies nicht ausreicht, können Sie die Datenbank vertikal oder horizontal skalieren.

Das Skalieren der Anwendung erfordert das Aktualisieren der Serverinstanz, normalerweise durch Hinzufügen von mehr Prozessoren / Kernen, mehr RAM, schnellerem Speicher usw. Das Hinzufügen von mehr Hardwareressourcen führt zu einer Steigerung der Datenbankleistung, gemessen hauptsächlich bei Transaktionen in zweitens und Transaktionsverzögerung für OLTP-Systeme. Relationale Datenbanksysteme (die einen Multithread-Ansatz verwenden) wie MySQL lassen sich gut vertikal skalieren.

Dieser Ansatz hat mehrere Nachteile, aber der offensichtlichste ist die maximale Servergröße auf dem Markt. Sobald das Limit der größten Serverinstanz erreicht ist, gibt es nur noch einen Weg: die horizontale Skalierung.

Die horizontale Skalierung ist ein Ansatz, bei dem dem Cluster mehr Server hinzugefügt werden, um die Leistung durch Hinzufügen der Anzahl der Server idealerweise linear zu steigern. Die meisten herkömmlichen Datenbanksysteme lassen sich horizontal oder überhaupt nicht gut skalieren. Beispielsweise kann MySQL für Lesevorgänge durch Hinzufügen von Slave-Lesegeräten horizontal skaliert werden, für Schreibvorgänge jedoch nicht horizontal.

Auf der anderen Seite kann Cloud Spanner aufgrund seiner Beschaffenheit mit minimalen Störungen problemlos horizontal skaliert werden.

Voll ausgestattetes DBMS als Servicemuss aus verschiedenen Blickwinkeln ausgewertet werden. Als Basis haben wir das beliebteste DBMS in der Cloud verwendet - für Google, GCP Cloud SQL und für Amazon, AWS RDS. Bei unserer Bewertung haben wir uns auf folgende Kategorien konzentriert:

  • Feature-Mapping: SQL-Umfang, DDL, DML; Verbindungsbibliotheken / Konnektoren, Transaktionsunterstützung usw.
  • Entwicklungsunterstützung: einfache Entwicklung und Prüfung.
  • Administrationsunterstützung: Verwaltung von Instanzen - zum Beispiel Skalieren / Verkleinern und Aktualisieren von Instanzen; SLA, Backup und Restore; Sicherheit / Zugangskontrolle.

Verwenden von Cloud Spanner als OLTP mit OLAP-Unterstützung


Obwohl Google nicht ausdrücklich behauptet, dass Cloud Spanner für die analytische Verarbeitung vorgesehen ist, teilt es einige Attribute mit anderen Mechanismen wie Apache Impala & Kudu und YugaByte, die für OLAP-Workloads entwickelt wurden.

Selbst wenn es nur eine geringe Chance gab, dass Cloud Spanner eine konsistente horizontal skalierbare HTAP-Engine (Hybrid Transactional / Analytical Processing) mit einem (mehr oder weniger) verwendbaren Satz von OLAP-Funktionen enthält, sind wir der Meinung, dass dies unsere Aufmerksamkeit verdient.

Vor diesem Hintergrund haben wir folgende Kategorien untersucht:

  • Unterstützung für das Laden von Daten, Indizes und Partitionierung
  • Abfrageleistung und DML

2. Cloud Spanner auf den Punkt gebracht


Google Spanner ist ein Cluster Relational Database Management System (RDBMS), das Google für mehrere seiner eigenen Dienste verwendet. Google hat es Anfang 2017 für Nutzer der Google Cloud Platform öffentlich zugänglich gemacht.

Hier sind einige der Attribute von Cloud Spanner:

  • Hochkonsistenter skalierbarer RDBMS-Cluster: Verwendet die Hardware-Zeitsynchronisation, um die Datenkonsistenz sicherzustellen.
  • Tabellenübergreifende Transaktionsunterstützung: Transaktionen können mehrere Tabellen umfassen - nicht unbedingt auf eine Tabelle beschränkt (im Gegensatz zu Apache HBase oder Apache Kudu).
  • : (), . , . , .
  • : . . , , , -.
  • : Cloud Spanner . . . . , , , . , .

«Cloud Spanner . , Cloud Spanner , - , ».


: Apache Tephra Apache HBase ( Apache Phoenix -).

3.


Daher lesen wir alle die Aussagen von Google zu den Vorteilen von Cloud Spanner - praktisch unbegrenzte horizontale Skalierung bei gleichzeitig hoher Konsistenz und sehr hohem SLA. Obwohl diese Anforderungen jedenfalls äußerst schwer zu erreichen sind, war es unser Ziel, sie nicht zu widerlegen. Konzentrieren wir uns stattdessen auf andere Dinge, die den meisten Datenbankbenutzern wichtig sind: Parität und Benutzerfreundlichkeit.

Wir haben Cloud Spanner als Ersatz für Sharded MySQL bewertet


Google Cloud SQL und Amazon AWS RDS, die beiden beliebtesten OLTP-DBMS auf dem Cloud-Markt, verfügen über einen sehr großen Funktionsumfang. Um diese Datenbanken jedoch über die Größe eines einzelnen Knotens hinaus zu skalieren, müssen Sie eine Anwendungspartitionierung durchführen. Dieser Ansatz schafft zusätzliche Komplexität sowohl für Anwendungen als auch für die Verwaltung. Wir haben uns angesehen, wie Spanner in das Szenario der Kombination mehrerer Segmente zu einer Instanz passt und welche Funktionen (falls vorhanden) möglicherweise geopfert werden müssen.

Unterstützung für SQL, DML und DDL sowie Connector und Bibliotheken?


Wenn Sie mit einer Datenbank beginnen, müssen Sie zunächst ein Datenmodell erstellen. Wenn Sie der Meinung sind, dass Sie den JDBC-Spanner mit Ihrem bevorzugten SQL-Tool verbinden können, werden Sie feststellen, dass Sie Ihre Daten damit abfragen können, aber Sie können damit keine Tabelle oder Änderung (DDL) oder andere Einfüge- / Aktualisierungs- / Löschvorgänge (DDL) erstellen. DML). Googles offizielles JDBC unterstützt dies ebenfalls nicht.
"Die Treiber unterstützen derzeit weder DML noch DDL."
Schraubenschlüssel-Dokumentation

Mit der GCP-Konsole ist die Situation nicht besser - Sie können nur SELECT-Abfragen senden. Glücklicherweise gibt es einen JDBC-Treiber mit DML- und DDL-Unterstützung aus der Community, einschließlich der Transaktionen github.com/olavloite/spanner-jdbc . Obwohl dieser Treiber äußerst nützlich ist, ist das Fehlen des Google-eigenen JDBC-Treibers überraschend. Glücklicherweise bietet Google eine ziemlich breite Unterstützung für Client-Bibliotheken (basierend auf gRPC): C #, Go, Java, node.js, PHP, Python und Ruby.

Die fast obligatorische Verwendung von Cloud Spanner-Benutzeroberflächen (aufgrund des Fehlens von DDL und DML in JDBC) führt zu einigen Einschränkungen für verwandte Codebereiche, wie z. B. Verbindungspools oder Datenbankbindungsframeworks (z. B. Spring MVC). Wenn Sie JDBC verwenden, können Sie normalerweise Ihren bevorzugten Verbindungspool (z. B. HikariCP, DBCP, C3PO usw.) frei auswählen, der getestet wurde und gut funktioniert. Bei benutzerdefinierten Spanner-APIs müssen wir uns auf die Frameworks / Bindungspools / Sitzungen verlassen, die wir selbst erstellt haben.

Das Design des Primärschlüssels (PC) ermöglicht es Cloud Spanner, beim Zugriff auf Daten über einen PC sehr schnell zu sein, führt jedoch auch zu einigen Abfrageproblemen.

  • ; . ( / .)
  • UPDATE DELETE WHERE, , DELETE all — , : UPDATE xxx WHERE id IN (SELECT id FROM table1)
  • - , . , .

?


Google Cloud Spanner bietet integrierte Unterstützung für Sekundärindizes. Dies ist eine sehr schöne Funktion, die in anderen Technologien nicht immer vorhanden ist. Apache Kudu unterstützt derzeit überhaupt keine Sekundärindizes, und Apache HBase unterstützt Indizes nicht direkt, kann sie jedoch über Apache Phoenix hinzufügen.

Indizes in Kudu und HBase können als separate Tabelle mit unterschiedlicher Zusammensetzung der Primärschlüssel modelliert werden. Die Atomizität der Operationen, die für die übergeordnete Tabelle und die zugehörigen Indextabellen ausgeführt werden, muss jedoch auf Anwendungsebene ausgeführt werden und ist für die korrekte Implementierung nicht trivial.

Wie im Cloud Spanner-Test erwähnt, können die Indizes von den MySQL-Indizes abweichen. Daher sollte beim Erstellen von Abfragen und Profilen besonders darauf geachtet werden, dass der richtige Index dort verwendet wird, wo er benötigt wird.

Darstellung?


Ein sehr beliebtes und nützliches Objekt in der Datenbank sind Ansichten. Sie können für eine große Anzahl von Benutzerfällen nützlich sein. Meine beiden Favoriten sind die Ebene der logischen Abstraktion und die Sicherheitsstufe. Leider unterstützt Cloud Spanner KEINE Einsendungen. Dies schränkt uns jedoch nur teilweise ein, da für Zugriffsberechtigungen auf Spaltenebene keine Granularität besteht, bei der Darstellungen eine akzeptable Lösung sein können.

Die Cloud Spanner-Dokumentation enthält einen Abschnitt mit Einzelheiten zu Kontingenten und Einschränkungen ( Schraubenschlüssel / Kontingente)) gibt es insbesondere eine, die für einige Anwendungen problematisch sein kann: Der sofort einsatzbereite Cloud Spanner ist auf maximal 100 Datenbanken pro Instanz begrenzt. Offensichtlich kann dies ein ernstes Hindernis für eine Datenbank sein, die auf mehr als 100 Datenbanken skaliert werden kann. Glücklicherweise haben wir nach einem Gespräch mit unserem technischen Vertreter von Google herausgefunden, dass dieses Limit durch den Google-Support auf nahezu jeden Wert erhöht werden kann.

Entwicklungsunterstützung?


Cloud Spanner bietet ziemlich gute Unterstützung für Programmiersprachen, um mit seiner API zu arbeiten. Offiziell unterstützte Bibliotheken befinden sich in den Bereichen C #, Go, Java, node.js, PHP, Python und Ruby. Die Dokumentation ist recht detailliert, aber wie bei anderen fortschrittlichen Technologien ist die Community im Vergleich zu den gängigsten Datenbanktechnologien recht klein, was zu einem längeren Zeitaufwand für die Lösung weniger häufiger Anwendungsfälle oder Probleme führen kann.

Was ist also mit lokaler Entwicklungsunterstützung?


Wir haben keine Möglichkeit gefunden, eine Cloud Spanner-Instanz in der lokalen Umgebung zu erstellen. Das nächstgelegene ist das CockroachDB Docker-Image , das im Prinzip ähnlich ist, in der Praxis jedoch sehr unterschiedlich. Beispielsweise kann CockroachDB PostgreSQL JDBC verwenden. Da die Entwicklungsumgebung so nah wie möglich an der Arbeitsumgebung sein sollte, ist Cloud Spanner nicht ideal, da Sie sich auf eine vollständige Spanner-Instanz verlassen müssen. Um Kosten zu sparen, können Sie eine Instanz für eine Region auswählen.

Administrative Unterstützung?


Das Erstellen einer Cloud Spanner-Instanz ist einfach. Sie müssen nur wählen, ob Sie eine multiregionale oder eine Instanz für eine Region erstellen, die Region (en) und die Anzahl der Knoten angeben möchten. In weniger als einer Minute ist die Instanz betriebsbereit.

Einige grundlegende Metriken sind direkt auf der Spanner-Seite in der Google-Konsole verfügbar. Detailliertere Ansichten sind über Stackdriver verfügbar. Dort können Sie auch Schwellenwertmetriken und Warnungsrichtlinien festlegen.

Zugang zu Ressourcen?


MySQL bietet umfangreiche und sehr detaillierte Benutzerberechtigungs- / Rolleneinstellungen. Sie können den Zugriff auf eine bestimmte Tabelle oder sogar nur eine Teilmenge ihrer Spalten einfach konfigurieren. Cloud Spanner verwendet das IAM-Tool (Google Identity & Access Management), mit dem Sie Richtlinien und Berechtigungen nur auf einer sehr hohen Ebene festlegen können. Die detaillierteste Option ist eine Auflösung auf Datenbankebene, die nicht in die meisten Produktionsfälle passt. Diese Einschränkung zwingt Sie dazu, Ihrem Code, Ihrer Infrastruktur oder beiden zusätzlichen Sicherheitsmaßnahmen hinzuzufügen, um die unbefugte Verwendung von Spanner-Ressourcen zu verhindern.

Backups?


In einfachen Worten, es gibt keine Backups in Cloud Spanner. Obwohl die hohen Anforderungen des Google SLA garantieren können, dass Sie keine Daten aufgrund von Hardware- oder Datenbankfehlern, menschlichen Fehlern, Anwendungsfehlern usw. verlieren. Wir alle kennen die Regel: Hochverfügbarkeit ersetzt keine vernünftige Sicherungsstrategie. Derzeit besteht die einzige Möglichkeit zum Sichern von Daten darin, sie programmgesteuert von der Datenbank in eine separate Speicherumgebung zu streamen.

Leistung abfragen?


Wir haben Yahoo! verwendet, um Daten herunterzuladen und Abfragen zu testen. Cloud Serving Benchmark. Die folgende Tabelle zeigt die YCSB B-Arbeitslast mit einer Lesequote von 95% und einer Schreibquote von 5%.



* Der Auslastungstest wurde mit der Computer-Engine n1-Standard-32 (CE) (32 vCPU, 120 GB Speicher) durchgeführt, und die Testinstanz war in den Tests niemals ein Engpass.
** Die maximale Anzahl von Threads in einer Instanz von YCSB beträgt 400. Insgesamt mussten sechs parallele Instanzen von YCSB-Tests ausgeführt werden, um insgesamt 2400 Threads zu erhalten.

Wenn wir uns die Testergebnisse ansehen, insbesondere die Kombination aus Prozessorlast und TPS, sehen wir deutlich, dass Cloud Spanner recht gut skaliert. Die große Last, die durch eine große Anzahl von Threads erzeugt wird, wird durch die große Anzahl von Knoten im Cloud Spanner-Cluster kompensiert. Obwohl die Verzögerung ziemlich hoch erscheint, insbesondere wenn mit 2400 Threads gearbeitet wird, kann ein erneuter Test mit 6 kleineren Instanzen der Rechenmaschine erforderlich sein, um genauere Zahlen zu erhalten. Jede Instanz führt einen YCSB-Test anstelle einer großen CE-Instanz mit 6 parallelen Tests aus. Somit ist es einfacher, zwischen Cloud Spanner-Anforderungsverzögerungen und Verzögerungen zu unterscheiden, die durch die Netzwerkverbindung zwischen Cloud Spanner und der CE-Instanz, auf der der Test ausgeführt wird, hinzugefügt werden.

Wie geht Cloud Spanner mit OLAP um?


Partitionierung?


Das Aufteilen von Daten in physisch und / oder logisch unabhängige Segmente, sogenannte Partitionen, ist ein sehr beliebtes Konzept, das den meisten OLAP-Mechanismen eigen ist. Partitionen können die Abfrageleistung und die Datenbankunterstützung erheblich verbessern. Eine weitere Vertiefung der Partition wird in einem oder mehreren separaten Artikeln behandelt. Lassen Sie uns daher nur die Bedeutung eines Partitionierungsschemas und einer Unterpartitionierung erwähnen. Die Möglichkeit, Daten in Partitionen und noch weiter in Unterpartitionen zu partitionieren, ist der Schlüssel für die Leistung von analytischen Abfragen.

Cloud Spanner unterstützt keine Partitionen an sich. Es teilt Daten intern in sogenannte Split aufs basierend auf Primärschlüsselbereichen. Die Trennung wird automatisch durchgeführt, um die Last im Cloud Spanner-Cluster auszugleichen. Eine sehr praktische Funktion von Cloud Spanner ist das Aufteilen der Grundlast der übergeordneten Tabelle (eine Tabelle, die sich nicht mit einer anderen abwechselt). Spanner ermittelt automatisch, ob Split Daten enthält , die häufiger gelesen werden als Daten in anderen Splits , und kann über eine weitere Trennung entscheiden. Somit können mehr Knoten an der Anforderung beteiligt sein, was auch den Durchsatz effektiv erhöht.

Lade Daten?


Die Cloud-Spanner-Methode für Massendaten ist dieselbe wie für reguläre Downloads. Um maximale Leistung zu erzielen, müssen Sie einige Empfehlungen befolgen, darunter:

  • Sortieren Sie Ihre Daten nach Primärschlüssel.
  • Teilen Sie sie durch 10 * die Anzahl der Knoten einzelner Abschnitte.
  • Erstellen Sie eine Reihe von Arbeitsaufgaben, die Daten parallel laden.

Bei diesem Datendownload werden alle Cloud Spanner-Knoten verwendet.

Wir haben die A YCSB-Workload verwendet, um einen Datensatz mit 10 Millionen Zeilen zu generieren.



* Der Auslastungstest wurde mit der Computer-Engine n1-Standard-32 (32 vCPU, 120 GB Speicher) durchgeführt, und die Testinstanz war in den Tests nie ein Engpass.
** Eine 1-Knoten-Konfiguration wird für keine Produktionslast empfohlen.

Wie oben erwähnt, verarbeitet Cloud Spanner Splits abhängig von ihrer Auslastung automatisch, sodass sich die Ergebnisse nach mehreren aufeinanderfolgenden Wiederholungen des Tests verbessern. Die hier vorgestellten Ergebnisse sind die besten Ergebnisse, die wir erhalten haben. Anhand der obigen Zahlen können wir sehen, wie Cloud Spanner (gut) mit zunehmender Anzahl von Knoten im Cluster skaliert. Die Zahlen, die auffallen, sind extrem niedrige durchschnittliche Verzögerungen, die im Gegensatz zu den Ergebnissen gemischter Arbeitsbelastungen stehen (95% beim Lesen und 5% beim Schreiben), wie im obigen Abschnitt beschrieben.

Skalieren?


Das Erhöhen und Verringern der Anzahl der Cloud Spanner-Knoten ist eine Ein-Klick-Aufgabe. Wenn Sie Daten schnell laden möchten, können Sie die Instanz auf das Maximum erhöhen (in unserem Fall waren es 25 Knoten in der Region US-EAST) und dann die Anzahl der Knoten reduzieren, die für Ihr reguläres Laden nach allen Daten in der Datenbank geeignet sind unter Berücksichtigung der Begrenzung auf 2 TB / Knoten.

Wir wurden auch bei einer viel kleineren Datenbank an diese Grenze erinnert. Nach mehreren Auslastungstests hatte unsere Datenbank eine Größe von ca. 155 GB. Bei einer Reduzierung auf eine Instanz von 1 Knoten wurde der folgende Fehler angezeigt:



Wir konnten die Skalierung von 25 auf 2 Instanzen reduzieren, blieben jedoch auf zwei Knoten hängen.

Das Erhöhen und Verringern der Anzahl von Knoten in einem Cloud Spanner-Cluster kann mithilfe der REST-API automatisiert werden. Dies kann besonders nützlich sein, um die erhöhte Belastung des Systems während der Stoßzeiten zu verringern.

OLAP-Abfrageleistung?


Zunächst wollten wir für diesen Teil viel Zeit für die Bewertung von Spanner aufwenden. Nach mehreren SELECT COUNTs wurde uns sofort klar, dass die Tests kurz sein würden und dass Spanner KEINE OLAP-Engine sein würde. Unabhängig von der Anzahl der Knoten im Cluster dauerte eine einfache Auswahl der Anzahl der Zeilen in einer Tabelle mit 10 Millionen Zeilen 55 bis 60 Sekunden. Darüber hinaus schlug jede Anforderung, die mehr Speicher zum Speichern von Zwischenergebnissen benötigte, mit einem OOM-Fehler fehl.

SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.

Einige Nummern für TPC-H-Anfragen finden Sie in Todd Lipcons Artikel Nosql-kudu-spanner-slide.html , Folien 42 und 43. Diese Nummern stimmen (leider) mit unseren eigenen Ergebnissen überein.



4. Unsere Ergebnisse


Angesichts des aktuellen Stands der Cloud Spanner-Funktionen ist es schwer vorstellbar, dass es sich um einen einfachen Ersatz für eine vorhandene OLTP-Lösung handelt, insbesondere wenn Ihre Anforderungen größer werden. Es müsste viel Zeit aufgewendet werden, um eine Lösung zu entwickeln, die die Fehler von Cloud Spanner berücksichtigt.

Als wir mit der Evaluierung von Cloud Spanner begannen, erwarteten wir, dass die Verwaltungsfunktionen mindestens so weit von anderen Google SQL-Lösungen entfernt sind. Wir waren jedoch überrascht über das völlige Fehlen von Backups und die sehr eingeschränkte Kontrolle des Zugriffs auf Ressourcen. Ganz zu schweigen vom Mangel an Ansichten, dem Fehlen einer lokalen Entwicklungsumgebung, nicht unterstützten Sequenzen, JDBC ohne DML- und DDL-Unterstützung und so weiter.

Wohin geht also derjenige, der die Transaktionsdatenbank skalieren muss? Es scheint, dass es keine einzige Lösung auf dem Markt gibt, die für alle Anwendungsfälle geeignet ist. Es gibt viele Closed- und Open-Source-Lösungen (von denen einige in diesem Artikel erwähnt werden), von denen jede ihre eigenen Stärken und Schwächen hat, aber keine von ihnen bietet SaaS mit einem SLA von 99,999% und einem hohen Grad an Konsistenz. Wenn ein hoher SLA Ihr primäres Ziel ist und Sie nicht dazu neigen, Ihre eigene Lösung für mehrere Cloud-Umgebungen zu erstellen, ist Cloud Spanner möglicherweise die Lösung, nach der Sie suchen. Sie müssen sich jedoch aller Einschränkungen bewusst sein.

Fairerweise sollte beachtet werden, dass Cloud Spanner nicht erst im Frühjahr 2017 für die Öffentlichkeit freigegeben wurde. Es ist daher zu erwarten, dass einige seiner aktuellen Mängel irgendwann verschwinden (ich hoffe), und wenn dies geschieht, kann dies das Spiel verändern. Schließlich ist Cloud Spanner nicht nur ein Drittanbieterprojekt für Google. Google verwendet es als Grundlage für andere Google-Produkte. Als Google kürzlich Megastore in Google Cloud Storage durch Cloud Spanner ersetzte, konnte Google Cloud Storage für Objektlisten weltweit streng konsistent sein (was für Amazon S3 immer noch nicht gilt ).

Es gibt also noch Hoffnung ... wir hoffen.

Das ist alles. Wie der Autor des Artikels hoffen auch wir weiterhin, aber was denkst du darüber? Schreiben Sie in die Kommentare.

Jeder ist eingeladen, unser kostenloses Webinar zu besuchen , in dessen Rahmen wir ausführlich über den OTUS AWS for Developers- Kurs sprechen werden .

More articles:


All Articles