Hallo, Chabrowiten. Traditionell teilen wir am Vorabend neuer Kurse weiterhin interessantes Material. Heute haben wir speziell für Sie einen Artikel über Google Cloud Spanner übersetzt, der zeitlich mit dem Start des Kurses zusammenfällt .
Ursprünglich veröffentlicht in .
Als Unternehmen, das eine Vielzahl cloudbasierter POS-Lösungen für Einzelhändler, Gastronomen und Online-Händler auf der ganzen Welt anbietet, nutzt Lightspeed verschiedene Arten von Datenbankplattformen für eine Vielzahl von Transaktions-, Analyse- und Suchanwendungsfällen. Jede dieser Datenbankplattformen hat ihre eigenen Stärken und Schwächen. Als Google Cloud Spanner auf den Markt brachte, vielversprechende Funktionen, die es in der Welt relationaler Datenbanken nicht gab, wie praktisch unbegrenzte horizontale Skalierbarkeit und ein Service Level Agreement (SLA) von 99,999 %. , Wir konnten uns die Gelegenheit nicht entgehen lassen, sie in unseren Händen zu halten!
Um einen umfassenden Überblick über unsere Erfahrungen mit Cloud Spanner sowie die von uns verwendeten Bewertungskriterien zu geben, werden wir die folgenden Themen behandeln:
- Unsere Bewertungskriterien
- Cloud Spanner auf den Punkt gebracht
- Unsere Einschätzung
- Unsere Ergebnisse
1. Unsere Bewertungskriterien
Bevor wir uns mit den Besonderheiten von Cloud Spanner sowie seinen Ähnlichkeiten und Unterschieden zu anderen Lösungen auf dem Markt befassen, sprechen wir zunächst über die wichtigsten Anwendungsfälle, die wir im Sinn hatten, als wir überlegten, wo wir Cloud Spanner in unserer Infrastruktur einsetzen sollten:
- Als Ersatz für die (vorherrschende) traditionelle SQL-Datenbanklösung
- Als OLTP-Lösung mit OLAP-Unterstützung
Hinweis: Um den Vergleich zu erleichtern, vergleicht dieser Artikel Cloud Spanner mit den MySQL-Varianten der GCP Cloud SQL- und Amazon AWS RDS-Lösungsfamilien.
Verwendung von Cloud Spanner als Ersatz für eine herkömmliche SQL-Datenbanklösung
In der Umwelt traditionell Wenn sich bei Datenbanken die Antwortzeit für eine Datenbankabfrage vordefinierten Anwendungsschwellenwerten nähert oder diese sogar überschreitet (hauptsächlich aufgrund einer Zunahme der Anzahl von Benutzern und/oder Anfragen), gibt es mehrere Möglichkeiten, die Antwortzeit auf ein akzeptables Maß zu reduzieren. Die meisten dieser Lösungen erfordern jedoch manuelle Eingriffe.
Der erste Schritt besteht beispielsweise darin, sich die verschiedenen leistungsbezogenen Datenbankeinstellungen anzusehen und sie so abzustimmen, dass sie den Mustern der Anwendungsnutzungsszenarien am besten entsprechen. Wenn dies nicht ausreicht, können Sie die Datenbank vertikal oder horizontal skalieren.
Das Hochskalieren einer Anwendung erfordert die Aktualisierung der Serverinstanz, typischerweise durch das Hinzufügen von mehr Prozessoren/Kernen, mehr RAM, schnellerem Speicher usw. Das Hinzufügen von mehr Hardwareressourcen führt zu einer höheren Datenbankleistung, die hauptsächlich in Transaktionen pro Sekunde gemessen wird, und einer Transaktionslatenz für OLTP-Systeme. Relationale Datenbanksysteme (die einen Multithread-Ansatz verwenden) wie MySQL lassen sich gut vertikal skalieren.
Dieser Ansatz weist mehrere Nachteile auf, der offensichtlichste ist jedoch die maximale Servergröße auf dem Markt. Sobald die maximale Serverinstanzgrenze erreicht ist, gibt es nur noch einen Weg: Skalieren.
Scale-out ist ein Ansatz, bei dem einem Cluster weitere Server hinzugefügt werden, um die Leistung idealerweise linear zu steigern, wenn mehr Server hinzugefügt werden. Mehrheitlich traditionell Datenbanksysteme skalieren nicht gut oder überhaupt nicht. Beispielsweise kann MySQL durch Hinzufügen von Slave-Lesegeräten für Lesevorgänge skaliert werden, für Schreibvorgänge ist jedoch keine Skalierung möglich.
Andererseits kann Cloud Spanner aufgrund seiner Beschaffenheit mit minimalem Eingriff problemlos horizontal skaliert werden.
Voll ausgestattet DBMS als Service müssen aus unterschiedlichen Perspektiven beurteilt werden. Als Grundlage haben wir das beliebteste DBMS in der Cloud genommen – für Google GCP Cloud SQL und für Amazon AWS RDS. Bei unserer Bewertung haben wir uns auf folgende Kategorien konzentriert:
- Funktionszuordnung: SQL-Erweiterung, DDL, DML; Verbindungsbibliotheken/Konnektoren, Transaktionsunterstützung usw.
- Entwicklungsunterstützung: Einfache Entwicklung und Tests.
- Verwaltungsunterstützung: Instanzverwaltung, z. B. Hochskalieren/Herunterskalieren und Aktualisieren von Instanzen; SLA, Backup und Wiederherstellung; Sicherheit/Zugangskontrolle.
Verwendung von Cloud Spanner als OLAP-fähige OLTP-Lösung
Obwohl Google nicht ausdrücklich angibt, dass Cloud Spanner für Analysen gedacht ist, teilt es einige Attribute mit anderen Engines wie Apache Impala & Kudu und YugaByte, die für OLAP-Workloads konzipiert sind.
Selbst wenn die Wahrscheinlichkeit gering wäre, dass Cloud Spanner eine konsistente Scale-out-HTAP-Engine (Hybrid Transactional/Analytic Processing) mit einem (mehr oder weniger) nutzbaren OLAP-Funktionsumfang enthält, denken wir, dass dies unsere Aufmerksamkeit verdienen würde.
Vor diesem Hintergrund haben wir uns die folgenden Kategorien angesehen:
- Unterstützung für das Laden von Daten, Indizes und Partitionierung
- Abfrageleistung und DML
2. Cloud Spanner in Kürze
Google Spanner ist ein geclustertes relationales Datenbankverwaltungssystem (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 Cloud Spanner-Attribute:
- Hochkonsistenter, skalierbarer RDBMS-Cluster: Verwendet Hardware-Zeitsynchronisierung, um die Datenkonsistenz sicherzustellen.
- Unterstützung tabellenübergreifender Transaktionen: Transaktionen können sich über mehrere Tabellen erstrecken – nicht unbedingt auf eine einzelne Tabelle beschränkt (im Gegensatz zu Apache HBase oder Apache Kudu).
- Primärschlüsselbasierte Tabellen: Alle Tabellen müssen über einen deklarierten Primärschlüssel (PC) verfügen, der aus mehreren Tabellenspalten bestehen kann. Tabellendaten werden in PC-Reihenfolge gespeichert, was die PC-Suche sehr effizient und schnell macht. Wie bei anderen PC-basierten Systemen muss die Implementierung anhand vorgefertigter Anwendungsfälle modelliert werden, um dies zu erreichen .
- Gestreifte Tabellen: Tabellen können physische Abhängigkeiten voneinander haben. Die Zeilen der untergeordneten Tabelle können mit den Zeilen der übergeordneten Tabelle abgeglichen werden. Dieser Ansatz beschleunigt die Suche nach Beziehungen, die bereits in der Datenmodellierungsphase ermittelt werden können, beispielsweise bei der Zusammenführung von Kunden und deren Rechnungen.
- Indizes: Cloud Spanner unterstützt sekundäre Indizes. Ein Index besteht aus indizierten Spalten und allen PC-Spalten. Optional kann der Index auch andere nicht indizierte Spalten enthalten. Der Index kann mit der übergeordneten Tabelle verschachtelt werden, um Abfragen zu beschleunigen. Für Indizes gelten verschiedene Einschränkungen, beispielsweise die maximale Anzahl zusätzlicher Spalten, die in einem Index gespeichert werden können. Außerdem sind Abfragen über Indizes möglicherweise nicht so einfach wie in anderen RDBMS.
„Cloud Spanner wählt nur in seltenen Fällen automatisch einen Index aus. Insbesondere wählt Cloud Spanner nicht automatisch einen sekundären Index aus, wenn die Abfrage Spalten anfordert, die nicht in gespeichert sind ".
- Service Level Agreement (SLA): Bereitstellung in einer einzelnen Region mit 99,99 % SLA; Bereitstellungen in mehreren Regionen mit 99,999 % SLA. Auch wenn es sich bei dem SLA selbst nur um eine Vereinbarung und nicht um eine Garantie jeglicher Art handelt, glaube ich, dass die Google-Leute über einige handfeste Daten verfügen, die eine so starke Aussage belegen. (Als Referenz: 99,999 % bedeutet 26,3 Sekunden Dienstausfallzeit pro Monat.)
- Mehr:
Hinweis: Das Apache Tephra-Projekt erweitert Apache HBase um erweiterte Transaktionsunterstützung (jetzt auch in Apache Phoenix als Beta implementiert).
3. Unsere Einschätzung
Wir alle haben also die Aussagen von Google über die Vorteile von Cloud Spanner gelesen – praktisch unbegrenzte horizontale Skalierung bei gleichzeitig hoher Konsistenz und einem sehr hohen SLA. Obwohl diese Behauptungen ohnehin äußerst schwer zu erreichen sind, bestand unser Ziel nicht darin, sie 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, zwei der beliebtesten OLTP-Datenbanken im 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 Anwendungsaufteilung durchführen. Dieser Ansatz führt zu zusätzlicher Komplexität sowohl bei den Anwendungen als auch bei der Verwaltung. Wir haben untersucht, wie Spanner in das Szenario der Kombination mehrerer Shards in einer Instanz passt und welche Funktionen (falls vorhanden) möglicherweise geopfert werden müssen.
Unterstützung für SQL, DML und DDL sowie den Connector und die Bibliotheken?
Wenn Sie mit einer Datenbank beginnen, müssen Sie zunächst ein Datenmodell erstellen. Wenn Sie glauben, dass Sie 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 es nicht zum Erstellen einer Tabelle oder zum Aktualisieren (DDL) oder zum Einfügen/Aktualisieren/Löschen verwenden Operationen (DML). Googles offizielles JDBC unterstützt beides nicht.
„Treiber unterstützen derzeit keine DML- oder DDL-Anweisungen.“
Spanner-Dokumentation
Mit der GCP-Konsole ist die Situation nicht besser – Sie können nur SELECT-Anfragen senden. Glücklicherweise gibt es von der Community einen JDBC-Treiber mit DML- und DDL-Unterstützung, einschließlich Transaktionen . Obwohl dieser Treiber äußerst nützlich ist, ist das Fehlen von Googles eigenem JDBC-Treiber ü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 nahezu obligatorische Verwendung der benutzerdefinierten APIs von Cloud Spanner (aufgrund des Fehlens von DDL und DML in JDBC) führt zu einigen Einschränkungen für verwandte Codebereiche wie Verbindungspooling oder Datenbankbindungs-Frameworks (wie Spring MVC). Im Allgemeinen können Sie bei der Verwendung von JDBC Ihren bevorzugten Verbindungspool (z. B. HikariCP, DBCP, C3PO usw.) frei wählen, der getestet wurde und gut funktioniert. Bei benutzerdefinierten Spanner-APIs müssen wir uns auf Frameworks/Binding/Session-Pools verlassen, die wir selbst erstellt haben.
Das am Primärschlüssel (PC) orientierte Design ermöglicht Cloud Spanner einen sehr schnellen Zugriff auf Daten über den PC, führt jedoch auch zu einigen Abfrageproblemen.
- Sie können den Wert eines Primärschlüssels nicht aktualisieren; Sie müssen zunächst den ursprünglichen PC-Eintrag löschen und ihn mit dem neuen Wert erneut einfügen. (Dies ähnelt anderen PC-orientierten Datenbank-/Speicher-Engines.)
- Alle UPDATE- und DELETE-Anweisungen müssen den PC im WHERE angeben, daher dürfen keine leeren DELETE-All-Anweisungen vorhanden sein – es muss immer eine Unterabfrage vorhanden sein, zum Beispiel: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Fehlen einer Auto-Inkrement-Option oder etwas Ähnlichem, das die Reihenfolge für das PC-Feld festlegt. Damit dies funktioniert, muss der entsprechende Wert auf der Anwendungsseite erstellt werden.
Sekundärindizes?
Google Cloud Spanner bietet integrierte Unterstützung für Sekundärindizes. Dies ist eine sehr nette 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 diese aber über Apache Phoenix hinzufügen.
Indizes in Kudu und HBase können als separate Tabelle mit unterschiedlicher Zusammensetzung von Primärschlüsseln modelliert werden, aber die Atomizität der an der übergeordneten Tabelle und zugehörigen Indextabellen durchgeführten Operationen muss auf Anwendungsebene durchgeführt werden und ist nicht einfach korrekt zu implementieren.
Wie im Cloud Spanner-Testbericht erwähnt, können sich seine Indizes von den MySQL-Indizes unterscheiden. Daher muss bei der Abfrageerstellung und Profilerstellung besondere Sorgfalt darauf verwendet werden, sicherzustellen, dass der richtige Index dort verwendet wird, wo er benötigt wird.
Darstellung?
Ein sehr beliebtes und nützliches Objekt in einer Datenbank sind Ansichten. Sie können für eine Vielzahl von Anwendungsfällen nützlich sein; Meine beiden Favoriten sind die logische Abstraktionsschicht und die Sicherheitsschicht. Leider unterstützt Cloud Spanner KEINE Ansichten. Dies schränkt uns jedoch nur teilweise ein, da es keine Granularität auf Spaltenebene für Zugriffsberechtigungen gibt, bei denen Ansichten eine akzeptable Lösung sein können.
In der Cloud Spanner-Dokumentation finden Sie einen Abschnitt mit detaillierten Kontingenten und Grenzwerten (), gibt es insbesondere eines, das für einige Anwendungen problematisch sein kann: Cloud Spanner verfügt standardmäßig über maximal 100 Datenbanken pro Instanz. Offensichtlich kann dies eine große Hürde für eine Datenbank darstellen, die für die Skalierung auf über 100 Datenbanken ausgelegt ist. Glücklicherweise haben wir nach einem Gespräch mit unserem technischen Vertreter von Google herausgefunden, dass dieses Limit über den Google-Support auf fast jeden Wert erhöht werden kann.
Entwicklungsunterstützung?
Cloud Spanner bietet ziemlich gute Programmiersprachenunterstützung für die Arbeit mit seiner API. Die offiziell unterstützten Bibliotheken liegen im Bereich C#, Go, Java, node.js, PHP, Python und Ruby. Die Dokumentation ist ziemlich detailliert, aber wie bei anderen Spitzentechnologien ist die Community im Vergleich zu den meisten gängigen Datenbanktechnologien recht klein, was dazu führen kann, dass mehr Zeit für weniger häufige Anwendungsfälle oder Probleme aufgewendet wird.
Wie sieht es also mit der lokalen Entwicklungsunterstützung aus?
Wir haben keine Möglichkeit gefunden, eine Cloud Spanner-Instanz vor Ort zu erstellen. Das nächste, was wir gefunden haben, ist ein Docker-Image Das ist im Prinzip ähnlich, in der Praxis jedoch sehr unterschiedlich. CockroachDB kann beispielsweise PostgreSQL JDBC verwenden. Da die Entwicklungsumgebung so nah wie möglich an der Produktionsumgebung liegen sollte, ist Cloud Spanner nicht ideal, da Sie auf eine vollständige Spanner-Instanz angewiesen sind. Um Kosten zu sparen, können Sie eine einzelne Regionsinstanz auswählen.
Administrative Unterstützung?
Das Erstellen einer Cloud Spanner-Instanz ist sehr einfach. Sie müssen lediglich zwischen der Erstellung einer Instanz mit mehreren Regionen oder einer Instanz mit einer einzelnen Region wählen und die Region(en) sowie die Anzahl der Knoten angeben. In weniger als einer Minute ist die Instanz betriebsbereit.
Mehrere grundlegende Metriken sind direkt auf der Spanner-Seite in der Google Console verfügbar. Detailliertere Ansichten sind über Stackdriver verfügbar, wo Sie auch Metrikschwellenwerte und Benachrichtigungsrichtlinien festlegen können.
Zugang zu Ressourcen?
MySQL bietet umfangreiche und sehr detaillierte Benutzerberechtigungs-/Rolleneinstellungen. Sie können den Zugriff auf eine bestimmte Tabelle oder auch nur auf eine Teilmenge ihrer Spalten ganz einfach anpassen. Cloud Spanner verwendet das Google Identity & Access Management (IAM)-Tool, mit dem Sie Richtlinien und Berechtigungen nur auf sehr hohem Niveau festlegen können. Die detaillierteste Option ist die Berechtigung auf Datenbankebene, die in den meisten Produktionsfällen nicht passt. Diese Einschränkung zwingt Sie dazu, Ihrem Code, Ihrer Infrastruktur oder beidem zusätzliche Sicherheitsmaßnahmen hinzuzufügen, um die unbefugte Nutzung von Spanner-Ressourcen zu verhindern.
Backups?
Vereinfacht ausgedrückt gibt es in Cloud Spanner keine Backups. Die hohen SLA-Anforderungen von Google können zwar sicherstellen, dass Sie keine Daten aufgrund von Hardware- oder Datenbankfehlern, menschlichem Versagen, Anwendungsfehlern usw. verlieren. Wir alle kennen die Regel: Hochverfügbarkeit ist kein Ersatz für eine intelligente Backup-Strategie. Derzeit besteht die einzige Möglichkeit zum Sichern von Daten darin, sie programmgesteuert aus der Datenbank in eine separate Speicherumgebung zu streamen.
Abfrageleistung?
Wir haben Yahoo! verwendet, um Daten zu laden und Anfragen zu testen. Cloud-Serving-Benchmark. Die folgende Tabelle zeigt die B-YCSB-Arbeitslast mit einem Verhältnis von 95 % Lesen zu 5 % Schreiben.
* Der Lasttest wurde auf der n1-standard-32 Compute Engine (CE) (32 vCPUs, 120 GB Speicher) ausgeführt und die Testinstanz stellte in den Tests nie den Engpass dar.
** Die maximale Anzahl von Threads in einer YCSB-Instanz beträgt 400. Insgesamt mussten sechs parallele Instanzen von YCSB-Tests ausgeführt werden, um insgesamt 2400 Threads zu erhalten.
Wenn wir uns die Benchmark-Ergebnisse ansehen, insbesondere die Kombination aus CPU-Last und TPS, können wir deutlich erkennen, dass Cloud Spanner recht gut skaliert. Die große Last, die durch eine große Anzahl von Threads entsteht, wird durch eine große Anzahl von Knoten im Cloud Spanner-Cluster ausgeglichen. Obwohl die Latenz recht hoch erscheint, insbesondere bei der Ausführung mit 2400 Threads, kann es erforderlich sein, den Test mit sechs kleineren Instanzen der Rechenmaschine erneut durchzuführen, um genauere Zahlen zu erhalten. Jede Instanz führt einen YCSB-Test anstelle einer großen CE-Instanz mit 6 parallelen Tests aus. Dies erleichtert die Unterscheidung zwischen Verzögerungen bei Cloud Spanner-Anfragen und Verzögerungen, die durch die Netzwerkverbindung zwischen Cloud Spanner und der CE-Instanz, auf der der Test ausgeführt wird, entstehen.
Wie funktioniert Cloud Spanner als OLAP?
Partitionierung?
Das Aufteilen von Daten in physisch und/oder logisch unabhängige Segmente, sogenannte Partitionen, ist ein sehr beliebtes Konzept, das in den meisten OLAP-Engines zu finden ist. Partitionen können die Abfrageleistung und die Wartbarkeit der Datenbank erheblich verbessern. Eine weitere Auseinandersetzung mit der Partitionierung wäre ein separater Artikel. Lassen Sie uns daher nur die Bedeutung eines Partitionierungsschemas und einer Unterpartitionierung erwähnen. Die Fähigkeit, Daten in Partitionen und noch weiter in Unterpartitionen aufzuteilen, ist der Schlüssel zur Leistung analytischer Abfragen.
Cloud Spanner unterstützt keine Partitionen per se. Es trennt Daten intern in sogenannte gespalten-s basierend auf Primärschlüsselbereichen. Die Partitionierung erfolgt automatisch, um die Last auf dem Cloud Spanner-Cluster auszugleichen. Eine sehr praktische Funktion von Cloud Spanner ist die Aufteilung der Grundlast einer übergeordneten Tabelle (einer Tabelle, die nicht mit einer anderen verschachtelt ist). Spanner erkennt automatisch, ob es enthält gespalten Daten, die häufiger gelesen werden als Daten in anderen gespalten-ah, und kann sich für eine weitere Trennung entscheiden. Somit können mehr Knoten an einer Anfrage beteiligt sein, was auch den Durchsatz effektiv erhöht.
Daten werden geladen?
Die Cloud Spanner-Methode für Massendaten ist dieselbe wie für einen regulären Upload. Für maximale Leistung müssen Sie einige Richtlinien befolgen, darunter:
- Sortieren Sie Ihre Daten nach Primärschlüssel.
- Teilen Sie sie durch 10*Anzahl der Knoten einzelne Abschnitte.
- Erstellen Sie eine Reihe von Worker-Aufgaben, die Daten parallel laden.
Dieser Datenladevorgang nutzt alle Cloud Spanner-Knoten.
Wir haben die A YCSB-Workload verwendet, um einen 10-Millionen-Zeilen-Datensatz zu generieren.
* Der Auslastungstest wurde auf der Rechen-Engine n1-standard-32 (32 vCPUs, 120 GB Speicher) ausgeführt und die Testinstanz stellte in den Tests nie den Engpass dar.
** Ein 1-Knoten-Setup wird für Produktions-Workloads nicht empfohlen.
Wie oben erwähnt, verarbeitet Cloud Spanner Teilungen automatisch abhängig von ihrer Auslastung, sodass sich die Ergebnisse nach mehreren aufeinanderfolgenden Testiterationen verbessern. Die hier präsentierten Ergebnisse sind die besten, die wir erhalten haben. Wenn wir uns die Zahlen oben ansehen, können wir sehen, wie Cloud Spanner (gut) skaliert, wenn die Anzahl der Knoten im Cluster steigt. Die herausragenden Zahlen sind die extrem niedrige durchschnittliche Latenz, die im Gegensatz zu den Ergebnissen gemischter Arbeitslasten (95 % Lesen und 5 % Schreiben) steht, wie im obigen Abschnitt beschrieben.
Skalierung?
Das Erhöhen und Verringern der Anzahl der Cloud Spanner-Knoten ist eine Ein-Klick-Aufgabe. Wenn Sie Daten schnell laden möchten, sollten Sie erwägen, die Instanz auf das Maximum zu steigern (in unserem Fall waren es 25 Knoten in der Region US-OST) und dann nach allen Daten die Anzahl der Knoten zu reduzieren, die für Ihre normale Last geeignet sind in der Datenbank unter Berücksichtigung des Limits von 2 TB/Knoten.
Wir wurden auch bei einer viel kleineren Datenbank an diese Grenze erinnert. Nach mehreren Auslastungstestläufen war unsere Datenbank etwa 155 GB groß und beim Herunterskalieren auf eine 1-Knoten-Instanz erhielten wir die folgende Fehlermeldung:
Wir konnten von 25 auf 2 Instanzen herunterskalieren, aber wir stecken auf zwei Knoten fest.
Das Erhöhen und Verringern der Anzahl der 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 reduzieren.
OLAP-Abfrageleistung?
Ursprünglich hatten wir geplant, der Bewertung von Spanner in diesem Bereich viel Zeit zu widmen. Nach ein paar SELECT COUNTs wurde uns sofort klar, dass der Test kurz sein würde und dass Spanner KEINE geeignete Engine für OLAP sein würde. Unabhängig von der Anzahl der Knoten im Cluster dauerte die einfache Auswahl der Anzahl der Zeilen in einer 10-M-Zeilentabelle 55 bis 60 Sekunden. Außerdem schlug jede Abfrage, die mehr Speicher zum Speichern von Zwischenergebnissen erforderte, mit einem OOM-Fehler fehl.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Einige Zahlen für TPC-H-Abfragen finden Sie im Artikel von Todd Lipcon , Folien 42 und 43. Diese Zahlen stimmen (leider) mit unseren eigenen Ergebnissen überein.
4. Unsere Erkenntnisse
Angesichts des aktuellen Stands der Funktionen von Cloud Spanner ist es schwer, es als einfachen Ersatz für eine bestehende OLTP-Lösung zu betrachten, insbesondere wenn Ihre Anforderungen darüber hinausgehen. Es würde viel Zeit in Anspruch nehmen, eine Lösung zu entwickeln, die die Mängel von Cloud Spanner umgeht.
Als wir mit der Evaluierung von Cloud Spanner begannen, gingen wir davon aus, dass seine Verwaltungsfunktionen mit anderen Google SQL-Lösungen vergleichbar oder zumindest nicht weit davon entfernt sein würden. Wir waren jedoch überrascht über das völlige Fehlen von Backups und die sehr eingeschränkte Zugriffskontrolle auf Ressourcen. Ganz zu schweigen von fehlenden Ansichten, keiner lokalen Entwicklungsumgebung, nicht unterstützten Sequenzen, JDBC ohne DML- und DDL-Unterstützung und so weiter.
Wohin kann sich also jemand wenden, der eine Transaktionsdatenbank skalieren muss? Es scheint noch keine einheitliche Lösung auf dem Markt zu geben, 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), jede mit ihren eigenen Stärken und Schwächen, aber keine von ihnen bietet SaaS mit einem SLA von 99,999 % und einem hohen Maß an Konsistenz. Wenn ein hohes SLA Ihr primäres Ziel ist und Sie nicht geneigt sind, eine eigene Lösung für mehrere Clouds zu entwickeln, könnte Cloud Spanner die Lösung sein, nach der Sie suchen. Sie sollten sich jedoch aller Einschränkungen bewusst sein.
Fairerweise muss man sagen, dass Cloud Spanner erst im Frühjahr 2017 für die Öffentlichkeit freigegeben wurde, daher ist davon auszugehen, dass einige seiner aktuellen Mängel (hoffentlich) irgendwann behoben werden, und wenn dies der Fall ist, könnte es bahnbrechend sein. Schließlich ist Cloud Spanner nicht nur ein Nebenprojekt von Google. Google nutzt es als Grundlage für andere Google-Produkte. Und als Google kürzlich Megastore in Google Cloud Storage durch Cloud Spanner ersetzte, ermöglichte es Google Cloud Storage, eine hohe Konsistenz für Objektlisten auf globaler Ebene zu erreichen (was immer noch nicht der Fall ist). ).
Es gibt also noch Hoffnung... wir hoffen.
Das ist alles. Wie der Autor des Artikels hoffen auch wir weiterhin, aber was denken Sie darüber? Schreiben Sie in die Kommentare
Wir laden alle ein, uns zu besuchen in dem wir Sie ausführlich über den Kurs informieren von OTUS.
Source: habr.com
