Hallo, Habr-Nutzer. Traditionell teilen wir interessantes Material im Vorfeld des Starts neuer Kurse. Heute haben wir speziell für euch einen Artikel über Google Cloud Spanner vorbereitet, der an den Start des Kurses gebunden ist. .
Ursprünglich veröffentlicht auf .
Als Unternehmen, das zahlreiche cloudbasierte POS-Lösungen für Einzelhändler, Gastronomen und Online-Verkäufer weltweit anbietet, nutzt Lightspeed verschiedene Arten von Datenbankplattformen für zahlreiche transaktionale, analytische und Suchanwendungen. Jede dieser Datenbankplattformen hat ihre eigenen Stärken und Schwächen. Daher konnten wir es uns nicht entgehen lassen, Cloud Spanner — mit vielversprechenden Funktionen, die in der Welt der relationalen Datenbanken bisher unbekannt waren, wie nahezu unbegrenzte horizontale Skalierbarkeit und ein SLA von 99,999 % — in die Hände zu bekommen!
Um einen umfassenden Überblick über unsere Erfahrungen mit Cloud Spanner sowie die Bewertungsmaßstäbe, die wir verwendet haben, zu geben, behandeln wir die folgenden Themen:
- Unsere Bewertungskriterien
- Cloud Spanner in Kürze
- Unsere Bewertung
- Unsere Erkenntnisse
1. Unsere Bewertungskriterien
Bevor wir auf die Eigenschaften von Cloud Spanner, ihre Ähnlichkeiten und Unterschiede zu anderen Lösungen auf dem Markt eingehen, lassen Sie uns zunächst über die Hauptanwendungsfälle sprechen, die wir in Betracht gezogen haben, als es darum ging, wo wir Cloud Spanner in unserer Infrastruktur implementieren möchten:
- Als Ersatz für die (dominante) traditionelle SQL-Datenbanklösung
- Als OLTP-Lösung mit OLAP-Unterstützung
Hinweis: Zur Vereinfachung und zum besseren Vergleich vergleicht dieser Artikel Cloud Spanner mit MySQL-Varianten der GCP Cloud SQL und Amazon AWS RDS.
Einsatz von Cloud Spanner als Ersatz für traditionelle SQL-Datenbanklösungen
In einer Umgebung traditioneller Datenbanken, wenn die Reaktionszeit auf Datenbankanfragen nahe an oder sogar über die vorgegebenen Schwellenwerte der Anwendung hinausgeht (hauptsächlich aufgrund einer steigenden Anzahl von Benutzern und/oder Anfragen), gibt es mehrere Möglichkeiten, die Reaktionszeit auf ein acceptables Niveau zu senken. Viele dieser Lösungen erfordern jedoch manuelles Eingreifen.
Zum Beispiel ist der erste Schritt, den man unternehmen sollte, einen Blick auf die verschiedenen Leistungsparameter der Datenbank zu werfen und diese so zu konfigurieren, dass sie optimal zu den Nutzungsmustern der Anwendungen passen. Wenn das nicht ausreicht, kann man vertikale oder horizontale skalierung der Datenbank in Betracht ziehen.
Die vertikale Skalierung einer Anwendung umfasst die Aktualisierung der Serverinstanz, normalerweise durch Hinzufügen von mehr Prozessoren/Kernen, mehr RAM, schnelleren Speicher usw. Das Hinzufügen zusätzlicher Hardware-Ressourcen führt zu einer erhöhten Datenbankleistung, die hauptsächlich in Transaktionen pro Sekunde und Transaktionslatenz für OLTP-Systeme gemessen wird. Relationale Datenbanksysteme (die einen Multithreading-Ansatz verwenden), wie MySQL, skalieren gut vertikal.
Dieser Ansatz hat einige Nachteile, aber der offensichtlichste ist die maximale Servergröße auf dem Markt. Sobald die Grenze der größten Serverinstanz erreicht ist, bleibt nur noch der Weg zur horizontalen Skalierung.
Die horizontale Skalierung ist ein Ansatz, bei dem dem Cluster weitere Server hinzugefügt werden, um idealerweise die Leistung linear mit der Anzahl der hinzugefügten Server zu steigern. Die meisten traditioneller Datenbanksysteme skalieren schlecht horizontal oder gar nicht. Zum Beispiel kann MySQL für Lesevorgänge horizontal skalieren, indem Slave-Reader hinzugefügt werden, aber nicht für Schreibvorgänge.
Cloud Spanner hingegen kann aufgrund seiner Natur horizontal skalieren mit minimalem Eingreifen.
Eine voll funktionsfähige Datenbank als Dienstleistung sollte aus verschiedenen Perspektiven bewertet werden. Als Grundlage haben wir die beliebteste Cloud-Datenbank genommen – für Google, GCP Cloud SQL und für Amazon, AWS RDS. In unserer Bewertung haben wir uns auf folgende Kategorien konzentriert:
- Funktionsvergleich: SQL-Umfang, DDL, DML; Verbindungslibraries/Connectoren, Transaktionsunterstützung usw.
- Entwicklungsunterstützung: Einfachheit der Entwicklung und des Testens.
- Administrationsunterstützung: Verwaltung von Instanzen – beispielsweise Skalierung nach oben/unten und Upgrade von Instanzen; SLA, Backup und Wiederherstellung; Sicherheit/Zugriffskontrolle.
Einsatz von Cloud Spanner als OLTP-Lösung mit OLAP-Unterstützung.
Obwohl Google nicht ausdrücklich behauptet, dass Cloud Spanner für die analytische Verarbeitung konzipiert ist, teilt es einige Attribute mit anderen Mechanismen wie Apache Impala & Kudu und YugaByte, die für OLAP-Workloads gedacht sind.
Selbst wenn die Wahrscheinlichkeit gering wäre, dass Cloud Spanner eine konsistente horizontal skalierbare HTAP (hybride transaktionale/analytische Verarbeitung) mit einem (mehr oder weniger) benutzbaren Funktionssatz für OLAP integriert hat, denken wir, dass dies unsere Aufmerksamkeit verdient.
Vor diesem Hintergrund haben wir die folgenden Kategorien betrachtet:
- Datenladen, Indizes und Unterstützung für Partitionierung.
- Abfrageleistung und DML.
2. Cloud Spanner in Kürze.
Google Spanner ist ein clusterbasiertes relationales Datenbankmanagementsystem (RDBMS), das Google für mehrere eigene Dienste verwendet. Google hat es Anfang 2017 für die Benutzer der Google Cloud Platform öffentlich zugänglich gemacht.
Hier sind einige der Attribute von Cloud Spanner:
- Stark konsistentes skalierbares RDBMS-Cluster: nutzt Hardware-Zeit-Synchronisation, um die Konsistenz von Daten zu gewährleisten.
- Unterstützung für transaktionale Quer-Tabellen-Transaktionen: Transaktionen können mehrere Tabellen umfassen – sie müssen nicht auf eine Tabelle beschränkt sein (im Gegensatz zu Apache HBase oder Apache Kudu).
- Tabellen basierend auf dem Primärschlüssel: Alle Tabellen müssen einen deklarierten Primärschlüssel (PK) haben, der aus mehreren Tabellen-Spalten bestehen kann. Tabellendaten werden in der Reihenfolge des PK gespeichert, was sie sehr effizient und schnell für die Suche nach PK macht. Wie bei anderen PK-basierten Systemen muss die Implementierung mit Bedacht auf vordefinierte Nutzungsszenarien modelliert werden, um .
- Wechselnde Tabellen: Tabellen können physische Abhängigkeiten zueinander haben. Die Zeilen der untergeordneten Tabelle können den Zeilen der übergeordneten Tabelle zugeordnet werden. Dieser Ansatz beschleunigt die Suche nach Beziehungen, die in der Phase der Datenmodellierung definiert werden können, z. B. bei der gemeinsamen Platzierung von Kunden und deren Rechnungen.
- Indizes: Cloud Spanner unterstützt sekundäre Indizes. Ein Index besteht aus indizierten Spalten und allen PK-Spalten. Auf Wunsch kann der Index auch andere nicht indizierte Spalten enthalten. Der Index kann mit der übergeordneten Tabelle gewechselt werden, um Abfragen zu beschleunigen. Auf Indizes gelten verschiedene Einschränkungen, z. B. die maximale Anzahl zusätzlicher Spalten, die im Index gespeichert werden können. Auch Abfragen über Indizes können weniger geradlinig sein als in anderen RDBMS.
Cloud Spanner wählt Indizes nur selten automatisch aus. Insbesondere wählt Cloud Spanner keinen sekundären Index automatisch aus, wenn die Abfrage nach Spalten fragt, die nicht im ».
- Service Level Agreement (SLA): Bereitstellung in einer Region mit SLA von 99,99 %; mehrregionale Bereitstellungen mit 99,999 % SLA. Obwohl das SLA selbst nur ein Vertrag und keine Garantie ist, glaube ich, dass die Mitarbeiter von Google einige präzise Daten haben, um eine solche schwerwiegende Behauptung zu machen. (Zur Information, 99,999 % entspricht 26,3 Sekunden Ausfallzeit pro Monat.)
- Mehr:
Hinweis: Das Apache Tephra-Projekt erweitert die Unterstützung für Transaktionen in Apache HBase (jetzt auch in Apache Phoenix als Beta-Version implementiert).
3. Unsere Einschätzung
Wir haben alle die Aussagen von Google über die Vorteile von Cloud Spanner gelesen – nahezu unbegrenztes horizontales Skalieren bei gleichbleibend hoher Konsistenz und sehr hohem SLA. Obwohl diese Anforderungen in jedem Fall extrem schwer zu erreichen sind, war es nicht unser Ziel, sie zu widerlegen. Lassen Sie uns stattdessen auf andere Dinge konzentrieren, die den meisten Datenbankbenutzern wichtig sind: Klarheit und Benutzerfreundlichkeit.
Wir haben Cloud Spanner als Ersatz für Sharded MySQL bewertet.
Google Cloud SQL und Amazon AWS RDS sind zwei der beliebtesten OLTP-Datenbanken auf dem Cloud-Markt und bieten eine sehr umfangreiche Funktionalität. Um diese Datenbanken jedoch über die Größe eines einzelnen Knotens hinweg zu skalieren, müssen Sie Anwendungen partitionieren. Dieser Ansatz bringt zusätzliche Komplexität sowohl für Anwendungen als auch für die Verwaltung mit sich. Wir haben untersucht, wie Spanner in das Szenario passt, mehrere Segmente in einer Instanz zu vereinen und welche Funktionen (falls vorhanden), möglicherweise geopfert werden müssen.
Unterstützung für SQL, DML und DDL sowie Connector und Bibliotheken?
Zunächst muss beim Einsatz mit einer Datenbank ein Datenmodell erstellt werden. Wenn Sie denken, dass Sie JDBC Spanner an Ihr bevorzugtes SQL-Tool anschließen können, werden Sie feststellen, dass Sie Ihre Daten damit abfragen können, aber es nicht für die Erstellung von Tabellen oder Änderungen (DDL) oder für jegliche Insert-/Update-/Delete-Operationen (DML) nutzen können. Das offizielle JDBC von Google unterstützt weder das eine noch das andere.
„Aktuell unterstützen die Treiber keine DML- oder DDL-Befehle.“
Spanner-Dokumentation
Die Situation mit der GCP-Konsole ist nicht besser – Sie können nur SELECT-Abfragen senden. Glücklicherweise gibt es einen Community-JDBC-Treiber mit Unterstützung für DML und DDL, einschließlich Transaktionen. . Obwohl dieser Treiber äußerst nützlich ist, überrascht das Fehlen eines eigenen JDBC-Treibers von Google. Glücklicherweise bietet Google eine recht umfassende Unterstützung für Client-Bibliotheken (basierend auf gRPC): C#, Go, Java, node.js, PHP, Python und Ruby.
Die nahezu zwingende Nutzung benutzerdefinierter APIs von Cloud Spanner (aufgrund des Fehlens von DDL und DML im JDBC) führt zu einigen Einschränkungen bei den zugehörigen Codebereichen, wie z. B. Verbindungspools oder Datenbankbindung-Frameworks (z. B. Spring MVC). Im Allgemeinen können Sie bei der Verwendung von JDBC freies einen bevorzugten Verbindungspool (z. B. HikariCP, DBCP, C3PO usw.) auswählen, der getestet und gut funktioniert. Bei benutzerdefinierten APIs von Spanner müssen wir uns auf die Frameworks/Pools für Bindungen/Sitzungen verlassen, die wir selbst erstellt haben.
Die auf den Primärschlüssel (PK) ausgerichtete Struktur ermöglicht es Cloud Spanner, beim Zugriff auf Daten über PK sehr schnell zu sein, führt jedoch auch zu einigen Problemen mit Abfragen.
- Sie können den Wert des Primärschlüssels nicht aktualisieren; Sie müssen zunächst den Datensatz mit dem ursprünglichen PK löschen und dann mit dem neuen Wert neu einfügen. (Das ähnelt anderen PK-orientierten Datenbanken/speichersystemen.)
- Alle UPDATE- und DELETE-Anweisungen müssen den PK in WHERE angeben, daher kann es keine leeren DELETE all-Anweisungen geben – es muss immer eine Unterabfrage vorhanden sein, z. B.: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Fehlende Autoinkrement-Option oder etwas Ähnliches, das eine Sequenz für das PK-Feld festlegt. Damit dies funktioniert, muss der entsprechende Wert auf der Anwendungsebene erstellt werden.
Sekundäre Indizes?
Google Cloud Spanner hat eine integrierte Unterstützung für sekundäre Indizes. Das ist eine sehr angenehme Funktion, die nicht immer in anderen Technologien vorhanden ist. Apache Kudu unterstützt derzeit überhaupt keine sekundären Indizes, 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 Tabellen mit unterschiedlicher Zusammensetzung der Primärschlüssel modelliert werden, aber die Atomarität der Operationen, die mit der übergeordneten Tabelle und den zugehörigen Indextabellen ausgeführt werden, muss auf Anwendungsebene gewährleistet werden und ist in der richtigen Implementierung nicht trivial.
Wie im Überblick zu Cloud Spanner erwähnt, können seine Indizes von MySQL-Indizes abweichen. Daher sollte beim Erstellen von Abfragen und der Profilierung besondere Vorsicht geboten sein, um sicherzustellen, dass der richtige Index dort verwendet wird, wo er erforderlich ist.
Sichten?
Ein sehr beliebtes und nützliches Objekt in Datenbanken sind Sichten. Sie können für eine Vielzahl von Anwendungsfällen nützlich sein; zwei meiner Favoriten sind die Ebene der logischen Abstraktion und die Sicherheitsebene. Leider unterstützt Cloud Spanner keine Sichten. Das schränkt uns nur teilweise ein, da es auf Spaltenebene keine Detailgenauigkeit für Zugriffsberechtigungen gibt, wo Sichten eine akzeptable Lösung sein könnten.
In der Cloud Spanner-Dokumentation im Abschnitt, der die Quoten und Beschränkungen detailliert beschreibt (), es gibt insbesondere eine, die für einige Anwendungen problematisch sein kann: Cloud Spanner hat standardmäßig eine Einschränkung von maximal 100 Datenbanken pro Instanz. Offensichtlich kann dies ein ernsthaftes Hindernis für eine Datenbank darstellen, die dafür gedacht ist, auf mehr als 100 Datenbanken zu skalieren. Glücklicherweise haben wir nach einem Gespräch mit unserem technischen Vertreter bei Google herausgefunden, dass dieses Limit praktisch auf jeden Wert über den Google-Support erhöht werden kann.
Unterstützung bei der Entwicklung?
Cloud Spanner bietet recht anständige Unterstützung für Programmiersprachen zur Nutzung seiner API. Offiziell unterstützte Bibliotheken sind für C#, Go, Java, node.js, PHP, Python und Ruby verfügbar. Die Dokumentation ist detailliert, aber wie bei anderen modernen Technologien ist die Community im Vergleich zu den populärsten Datenbanktechnologien recht klein, was die Zeit für die Lösung weniger verbreiteter Anwendungsfälle oder Probleme verlängern kann.
Wie sieht es also mit der Unterstützung für lokale Entwicklungen aus?
Wir haben keinen Weg gefunden, eine Cloud Spanner-Instanz in einer lokalen Umgebung zu erstellen. Das Nächste, was wir erhalten haben, ist ein Docker-Image. , was im Prinzip ähnlich ist, in der Praxis jedoch deutlich abweicht. Zum Beispiel kann CockroachDB PostgreSQL JDBC verwenden. Da die Entwicklungsumgebung so nah wie möglich an der Produktionsumgebung sein sollte, ist Cloud Spanner nicht ideal, da man auf eine vollständige Spanner-Instanz angewiesen ist. Zum Kostenersparen kann man eine Instanz für eine Region wählen.
Unterstützung für die Verwaltung?
Es ist sehr einfach, eine Cloud Spanner-Instanz zu erstellen. Man muss nur zwischen der Erstellung einer multiregionalen oder einer Instanz für eine Region wählen, die Region(en) und die Anzahl der Knoten angeben. In weniger als einer Minute wird die Instanz hochgefahren und ist betriebsbereit.
Einige grundlegende Metriken sind direkt auf der Spanner-Seite in der Google-Konsole verfügbar. Detailliertere Ansichten sind über Stackdriver erhältlich, wo man auch Schwellenwerte für Metriken und Benachrichtigungsrichtlinien festlegen kann.
Zugriff auf Ressourcen?
MySQL bietet umfangreiche und sehr detaillierte Einstellungen für Benutzerberechtigungen und -rollen. Der Zugriff auf eine bestimmte Tabelle oder sogar nur auf einen Teil ihrer Spalten kann leicht eingerichtet werden. Cloud Spanner verwendet das Google Identity & Access Management (IAM) Tool, das es ermöglicht, Richtlinien und Berechtigungen nur auf sehr hohem Niveau festzulegen. Die detaillierteste Variante ist die Datenbankberechtigung, die in den meisten Produktionsfällen nicht anwendbar ist. Diese Einschränkung zwingt Sie dazu, zusätzliche Sicherheitsmaßnahmen in Ihren Code, Ihre Infrastruktur oder beides einzufügen, um die unbefugte Nutzung der Spanner-Ressourcen zu verhindern.
Backups?
Einfach gesagt, Backup-Optionen gibt es in Cloud Spanner nicht. Obwohl die hohen Anforderungen des Google SLAs garantieren können, dass Sie aufgrund von Hardware- oder Datenbankausfällen keine Daten verlieren, sind menschliche Fehler, Anwendungsfehler usw. nicht abgedeckt. Wir alle kennen die Regel: hohe Verfügbarkeit ersetzt keine durchdachte Backup-Strategie. Derzeit besteht der einzige Weg, um Daten zu sichern, darin, sie über eine softwareseitige Streaming-Übertragung aus der Datenbank in eine separate Speichermedium zu übertragen.
Abfrageleistung?
Für das Laden von Daten und das Testen von Abfragen haben wir den Yahoo! Cloud Serving Benchmark verwendet. In der folgenden Tabelle wird die Arbeitslast B YCSB mit einem Leseverhältnis von 95 % und einem Schreibverhältnis von 5 % gezeigt.
* Der Lasttest wurde auf dem Compute Engine (CE) n1-standard-32 (32 vCPU, 120 GB RAM) durchgeführt, und der Testinstanz war niemals der Engpass in den Tests.
** Die maximale Anzahl von Threads in einer YCSB-Instanz beträgt 400. Insgesamt mussten sechs parallele Instanzen von YCSB-Tests gestartet werden, um insgesamt 2400 Threads zu erreichen.
Anhand der Testergebnisse, insbesondere der Kombination von CPU-Last und TPS, sehen wir deutlich, dass Cloud Spanner gut skalierbar ist. Die hohe Last, die durch die große Anzahl an Threads erzeugt wird, wird durch die große Anzahl an Knoten im Cloud Spanner-Cluster ausgeglichen. Obwohl die Latenz ziemlich hoch erscheint, insbesondere bei der Verarbeitung von 2400 Threads, könnte für genauere Zahlen ein erneuter Test mit 6 kleineren Instanzen des Berechnungs-Engines erforderlich sein. Jede Instanz würde einen YCSB-Test im Gegensatz zu einer großen CE-Instanz mit 6 parallelen Tests durchführen. Dadurch wäre es einfacher, die Latenzzeiten von Cloud Spanner und die durch die Netzwerkverbindung zwischen Cloud Spanner und der CE-Instanz, auf der der Test durchgeführt wird, hinzugefügten Latenzzeiten zu unterscheiden.
Wie schlägt sich Cloud Spanner als OLAP?
Partitionierung?
Die Aufteilung von Daten in physisch und/oder logisch unabhängige Segmente, die Partitionen genannt werden, ist ein sehr beliebtes Konzept, das den meisten OLAP-Mechanismen eigen ist. Partitionen können die Abfrageleistung und die Wartbarkeit der Datenbank erheblich verbessern. Eine detailliertere Betrachtung von Partitionen würde in einen separaten Artikel führen, daher wollen wir nur die Bedeutung eines Partitionierungs- und Sub-Partitionierungsschemas erwähnen. Die Möglichkeit, Daten in Partitionen und sogar weiter in Subpartitionen zu unterteilen, ist der Schlüssel zur Leistung analytischer Abfragen.
Cloud Spanner unterstützt Partitionen nicht im klassischen Sinne. Es unterteilt die Daten intern in sogenannte Splits- auf Basis von Primärschlüsselbereichen. Die Teilung erfolgt automatisch, um die Last im Cloud Spanner-Cluster auszugleichen. Eine sehr nützliche Funktion von Cloud Spanner besteht darin, die Grundlast der übergeordneten Tabelle (einer Tabelle, die nicht mit einer anderen abwechselt) zu partitionieren. Spanner erkennt automatisch, ob Splits Daten, die häufiger gelesen werden, als Daten in anderen Splits- enthalten sind, und kann die Entscheidung über eine weitere Aufteilung treffen. Dadurch können mehr Knoten in der Abfrage genutzt werden, was ebenfalls die Durchsatzleistung erhöht.
Daten laden?
Die Cloud Spanner-Methode für große Daten ist die gleiche wie beim normalen Laden. Um die maximale Leistung zu erreichen, sollten Sie einige Empfehlungen befolgen, darunter:
- Sortieren Sie Ihre Daten nach dem Primärschlüssel.
- Teilen Sie sie in 10*Anzahl der Knoten separaten Sektionen.
- Erstellen Sie eine Reihe von Arbeitsaufgaben, die die Daten parallel laden.
Bei einem solchen Datensatz werden alle Knoten von Cloud Spanner genutzt.
Wir haben die Arbeitslast A YCSB verwendet, um einen Datensatz aus 10 Millionen Zeilen zu generieren.
* Der Lasttest wurde auf der Compute Engine n1-standard-32 (32 vCPU, 120 GB RAM) durchgeführt, und die Testinstanz war während der Tests niemals ein Engpass.
** Eine Konfiguration mit 1 Knoten wird für jede Produktionslast nicht empfohlen.
Wie oben erwähnt, verarbeitet Cloud Spanner automatisch die Splits je nach ihrer Last, weshalb sich die Ergebnisse nach mehreren aufeinanderfolgenden Testwiederholungen verbessern. Die hier präsentierten Ergebnisse sind die besten, die wir erzielt haben. Wenn wir auf die oben genannten Zahlen schauen, können wir sehen, wie Cloud Spanner (gut) mit der Anzahl der Knoten im Cluster skalierbar ist. Die herausragenden Zahlen sind extrem niedrige Durchschnittslatenzen, die mit den Ergebnissen gemischter Arbeitslasten (95 % Lesen und 5 % Schreiben) kontrastieren, wie im obigen Abschnitt beschrieben.
Skalierung?
Das Erhöhen und Verringern der Anzahl der Cloud Spanner-Knoten erfolgt mit einem Klick. Wenn Sie Daten schnell laden möchten, können Sie in Erwägung ziehen, die Instanz auf maximal zu erhöhen (in unserem Fall waren es 25 Knoten in der Region US-EAST), und dann die Anzahl der Knoten zu reduzieren, die für Ihre normale Last geeignet sind, nachdem alle Daten in der Datenbank sind, wobei Sie das Limit von 2 TB/Knoten im Auge behalten.
Wir wurden auf dieses Limit aufmerksam gemacht, selbst mit einer viel kleineren Datenbank. Nach mehreren Durchläufen von Lasttests hatte unsere Datenbank eine Größe von etwa 155 GB, und beim Verringern auf eine Instanz mit 1 Knoten erhielten wir den folgenden Fehler:
Wir konnten die Skalierung von 25 auf 2 Instanzen reduzieren, aber wir blieben bei zwei Knoten stecken.
Die Erhöhung und Verringerung der Anzahl der Knoten im Cloud Spanner-Cluster kann über die REST-API automatisiert werden. Dies kann besonders hilfreich sein, um die erhöhte Last auf das System während der stark frequentierten Zeiten zu reduzieren.
Leistung von OLAP-Abfragen?
Ursprünglich hatten wir geplant, einen erheblichen Teil unserer Bewertung von Spanner auf diesen Aspekt zu konzentrieren. Nach mehreren SELECT COUNT war uns sofort klar, dass die Tests kurz ausfallen würden und dass Spanner NICHT als OLAP-Engine geeignet sein würde. Unabhängig von der Knotenanzahl im Cluster dauerte eine einfache Abfrage der Anzahl der Zeilen in einer Tabelle mit 10 Mio. Zeilen zwischen 55 und 60 Sekunden. Darüber hinaus schlug jede Abfrage, die mehr Speicher zur Speicherung von Zwischenergebnissen erforderte, mit einem OOM-Fehler fehl.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M verschiedene Werte) → SpoolingHashAggregateIterator hat während der neuen Zeile den Speicher überschritten.
Einige Zahlen zu TPC-H-Abfragen sind im Artikel von Todd Lipkon zu finden, , 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 vorstellbar, dass es eine einfache Lösung für bestehende OLTP-Anforderungen bieten kann, insbesondere wenn Ihre Bedürfnisse darüber hinausgehen. Es wäre erforderlich, erheblich Zeit in den Aufbau einer Lösung zu investieren, die die Schwächen von Cloud Spanner berücksichtigt.
Als wir mit der Bewertung von Cloud Spanner begannen, erwarteten wir, dass die Verwaltungsfunktionen auf dem Niveau oder zumindest nicht weit entfernt von anderen Google SQL-Lösungen sein würden. Doch wir waren überrascht über das vollständige Fehlen von Backups und die sehr eingeschränkte Zugriffskontrolle auf Ressourcen. Ganz zu schweigen von dem Fehlen von Sichten, dem Fehlen einer lokalen Entwicklungsumgebung, nicht unterstützten Sequenzen, JDBC ohne Unterstützung für DML und DDL usw.
Wo soll man also hin, wenn man eine transaktionale Datenbank skalieren muss? Anscheinend gibt es derzeit auf dem Markt keine universelle Lösung, die für alle Anwendungsfälle geeignet ist. Es gibt zahlreiche Lösungen mit geschlossenen und offenen Quellcodes (von denen einige in diesem Artikel erwähnt werden), jede mit ihren eigenen Stärken und Schwächen, aber keine bietet ein SaaS mit einer SLA von 99,999 % und einem hohen Maß an Konsistenz. Wenn ein hohes SLA-Niveau Ihr Hauptziel ist und Sie nicht geneigt sind, eine eigene Lösung für mehrere Cloud-Umgebungen zu entwickeln, könnte Cloud Spanner die Lösung sein, nach der Sie suchen. Aber Sie sollten sich über alle seine Einschränkungen im Klaren sein.
Fairerweise sollte man erwähnen, dass Cloud Spanner erst im Frühjahr 2017 für die Allgemeinheit freigegeben wurde, daher ist es vernünftig zu erwarten, dass einige seiner aktuellen Mängel letztendlich behoben werden (hoffentlich), und wenn das geschieht, könnte es das Spiel ändern. Schließlich ist Cloud Spanner nicht nur ein Nebenprojekt von Google. Google verwendet es als Basis für andere Google-Produkte. Und als Google kürzlich Megastore in Google Cloud Storage durch Cloud Spanner ersetzt hat, ermöglichte dies Google Cloud Storage, eine strikt konsistente Liste von Objekten weltweit bereitzustellen (was nach wie vor nicht für ).
Die Hoffnung ist also noch da… wir hoffen.
Das war's. Wie der Autor des Artikels hoffen auch wir weiter, was denken Sie darüber? Schreiben Sie Ihre Meinung in die Kommentare.
Alle Interessierten laden wir ein, an unserem teilzunehmen, in dem wir ausführlich über den Kurs von OTUS berichten werden.
Quelle: habr.com
